Coding agents can already do meaningful repository work. The interesting engineering problem is increasingly how much autonomy we can give them while keeping scope, verification and delivery under deterministic control.
I built RepoMethod to keep that method in Git instead of inside one model-specific prompt. This post walks through the real ChatGPT demo and the repository-level delivery contract behind it.
Which repository state is the agent actually working from? Which files is it allowed to touch? What counts as finished? What happens when the normal tests are green but the requested change violates the agreed scope?
I built RepoMethod around one idea:
The agent can change, but the engineering method should stay in the repository.
I tested that with ChatGPT against a deliberately ordinary Fastify TypeScript service. The feature was simple: GET /tasks already supported pagination, while GET /items did not. ChatGPT had to bring /items in line with the existing pattern.
The interesting part was not the implementation. It was getting ChatGPT, GitHub, a local execution environment and a repository-owned delivery contract to work together for real.
RepoMethod: https://github.com/frederik-schmittel/repomethod
Demo repository: https://github.com/frederik-schmittel/repomethod-demo
My first attempt failed for an environment reason.
ChatGPT could access the connected GitHub repository, but the sandbox could not rely on a normal git clone. Direct GitHub network access failed, so the agent could modify repository content remotely but could not execute the full local RepoMethod workflow.
It correctly refused to fake success:
DELIVERY: blocked — Classic workflow state, handoff, agent-gate and deliver.sh could not be executed in the available runtime.
That failure exposed the right mental model:
GitHub connector
authoritative remote state
↓
local working copy
disposable execution environment
↓
RepoMethod
repository-owned engineering contract
↓
verified result
↓
GitHub publication
The transport between GitHub and the local workspace may change as ChatGPT evolves. The invariant is what matters: RepoMethod must execute against a real local Git working state that corresponds to a known remote revision.
The successful run made that execution boundary explicit instead of assuming a normal clone would exist.
This is the reusable pattern:
Work on the connected GitHub repository `OWNER/REPO`.
Use the connected GitHub repository as the authoritative source for the current repository state.
Do not depend on `git clone` or direct GitHub network access working in the sandbox. Establish a local working copy from the current `main` state using the connected repository as the source of truth.
If that local workspace is not already a Git working tree, initialize Git and record the materialized `main` snapshot as the clean baseline before feature work. The repository method must operate against a real local Git working tree.
Read `AGENTS.md` and the installed RepoMethod instructions first. Follow the repository-owned method as authoritative.
Use RepoMethod Classic.
Implement FEATURE, using EXISTING_REFERENCE as the reference implementation.
Before writing implementation code:
- inspect the existing reference behavior and relevant tests
- create the RepoMethod feature spec
- initialize and follow the Classic workflow
Keep the change minimal.
Run the repository-defined verification and complete RepoMethod delivery.
Do not invent a substitute workflow or fabricate a delivery verdict.
Create a task branch from current `main`.
Only after successful RepoMethod delivery, commit and publish the verified feature state.
Do not create a pull request or merge anything.
Report the branch, remote commit SHA, verification result and final `DELIVERY:` verdict.
For the demo, the concrete values were:
repository: frederik-schmittel/repomethod-demo
feature: GET /items pagination
reference: GET /tasks
feature slug: items-pagination
branch: task/items-pagination
That prompt does not tell ChatGPT how to implement pagination. The repository already contains that knowledge. The extra detail is about execution integrity: source state, local baseline, real RepoMethod execution and publication only after verification.
RepoMethod had already been installed and committed as part of the repository baseline.
The repository verification command was:
npm run lint
npm run typecheck
npm test
npm run build
That lived in:
.repomethod/verify-command
ChatGPT then read the repository instructions, inspected the existing /tasks route and tests, created specs/items-pagination.md, initialized RepoMethod Classic and implemented the smallest matching change in /items.
The implementation itself was intentionally boring. It reused the existing pagination helpers instead of inventing a second pagination design.
The first RepoMethod verification did not pass immediately.
The TypeScript implementation was fine, but the generated evidence report was not explicitly bound to the feature spec. RepoMethod rejected it as stale evidence and used the Classic retry path.
After that evidence binding was corrected, the retry verification passed.
This matters because RepoMethod was checking more than whether the application compiled. It was checking whether the repository's evidence, scope and acceptance contract were internally consistent.
The repository checks passed:
Test Files 4 passed (4)
Tests 21 passed (21)
Then RepoMethod checked the delivery contract:
OK: 2 files in scope
OK: 5/5 acceptance criteria confirmed (5 strict)
OK: 2/2 evidence files present
OK: report names items-pagination.md
[agent-gate] all gates passed
exit_code=0
The final delivery verdict was:
DELIVERY: done — gate green, workflow completed, completion node succeeded, scope clean, fresh handoff, plan artifacts committed, no open blocker
The verified feature was then published to:
task/items-pagination
Published branch head:
6b780da58592e4152eba3f9d3116ee375023532a
No pull request was created and nothing was merged.
The important boundary is simple:
ChatGPT writes the implementation. The repository owns the delivery contract.
After the valid feature was published, I deliberately asked ChatGPT for one additional change.
The feature spec and scope had to remain unchanged. ChatGPT was told to add a short pagination note to README.md, then rerun the same RepoMethod workflow without quietly expanding the scope.
The ordinary engineering checks still passed:
Test Files 4 passed (4)
Tests 21 passed (21)
[verify] npm run build
> tsc -p tsconfig.json
But the repository-owned feature contract said README.md was out of scope.
RepoMethod returned:
VIOLATION: README.md
exit_code=1
Final verdict:
DELIVERY: blocked — VIOLATION: README.md
The blocked change was not committed and was not pushed. The remote branch stayed on the last accepted commit.
That was the strongest part of the experiment.
The application was still correct. The tests were still green. But the requested change violated the committed engineering contract, so delivery stopped.
Green tests were necessary, but they were not sufficient evidence that an autonomous coding agent had respected the task.
repomethod doctor
repomethod install
.repomethod/verify-command.
DELIVERY: done
The useful distinction is:
repository tests green
≠
automatically acceptable delivery
The exact ChatGPT mechanics used in this run are environment-specific. In this session, direct clone and push were unavailable, so the agent had to use the connected GitHub tooling to establish and publish the working state through a fallback path.
A future ChatGPT version may make that much simpler.
The method should not depend on that transport detail.
The stable requirements are:
done or blocked;
That is why I prefer keeping the engineering method in the repository rather than in a model-specific prompt.
The agent ecosystem will keep changing. The repository is the durable boundary.
RepoMethod
https://github.com/frederik-schmittel/repomethod
Demo repository
Successful demo branch
https://github.com/frederik-schmittel/repomethod-demo/tree/task/items-pagination
Video