Working method · agent-assisted engineering
Five moves that take a fuzzy idea to reviewed, committed code — and the context discipline that is the actual reason it holds together.
The thinking is compressed, not discarded. Every arrow in this flow is a lossy compression, on purpose.
Grilling output is dense enough that the spec never needs the transcript. The spec is dense enough that the tickets never need the spec’s argument. Each ticket is dense enough that implementing it needs nothing else at all — which is precisely why the context window can be thrown away between them.
One unbroken context windowno /clear · no /compact
/clear
Fresh windowticket 1
Fresh windowticket 2
Fresh windowticket n
Held together: the grilling, the spec and the tickets are one continuous act of thinking. Burned per ticket: implementation context is disposable because the ticket already carries everything.
/grill-with-docs
Round after round of questions aimed at the frontier of what is still undecided. The division of labour is strict: gathering facts is the agent’s job, making decisions is mine. It is stateful — it writes CONTEXT.md as a working glossary of the domain language, and records the hard-to-reverse calls as ADRs.
Out: a sharpened idea, a shared vocabulary, a paper trail.
/to-spec
The grilling thread is long and argumentative; the spec is short and decided. This move only earns its place on a multi-session build — if the work fits in one window, skip straight to implementing it in the same context.
Out: a spec that stands without the conversation behind it.
/to-tickets
Each ticket is a vertical slice that goes end to end — not a horizontal layer that can’t be demonstrated on its own. Each declares what blocks it, so the set is a dependency graph rather than a list. On a local tracker that’s one file per ticket under .scratch/<feature>/issues/, worked blockers-first; on a real tracker the edges become native blocking links, so anything unblocked is grabbable.
Out: a DAG of self-contained slices.
/implement
It doesn’t write the feature and then test it. It drives red–green internally, one slice of behaviour at a time, so every line that exists is there because a failing test asked for it.
Out: a working slice and the tests that pinned it down.
/code-review
The diff is reviewed twice at once by separate sub-agents. Standards asks whether it follows this repo’s documented conventions. Spec asks whether it does what the originating ticket actually asked for. They are different failure modes and they need different readers — clean code that solves the wrong problem passes the first and fails the second.
Out: two findings lists, side by side. Then commit.
Grill, spec and tickets stay in one unbroken window — no compacting, no clearing until the tickets exist — because all three have to build on the same thinking. After that, every /implement starts empty. The previous ticket’s context is not worth carrying, and carrying it is how a session quietly degrades.
Roughly 150k tokens is the window inside which a frontier model still reasons sharply. If a session approaches it before the tickets are written, the answer isn’t to push on degraded — it’s to /compact at the nearest phase boundary and carry on from there.
| Prompt → big diff → hope | This flow |
|---|---|
| Decisions get made inside the code, late and expensively | Decisions are front-loaded into cheap text |
| One long session, degrading as it goes | Bounded windows, each well inside the smart zone |
| Review at the end, against nothing in particular | Review per slice, against standards and the ticket |
| Vocabulary drifts between you and the agent | CONTEXT.md is the agreed glossary from round one |
| Rework when the built thing isn't the meant thing | The soft spots were found during the interview |
The skills this flow is built from are Matt Pocock’s, published at aihero.dev. The method here is how I run them.
Off the main flow and merging into it: /triage for incoming issues, /diagnosing-bugs for the hard ones, /wayfinder for efforts too foggy to hold in a single session.