The seven steps describe what the pipeline does. These principles describe why it's shaped the way it is. They're the cross-cutting decisions — the ones that don't belong to any single step because they govern all of them.
There is no Plan step
The most conspicuous thing about this pipeline is a step that isn't there. Between specifying work and building it, most processes insert a planning document. This one doesn't. The tickets are the plan.
A plan doc and a set of tickets describe the same work twice, and two descriptions of the same thing drift apart the instant either is touched. Tickets already carry everything a plan needs: they can be claimed, ordered, and linked by dependency, and they live where the work actually happens. The one case a plan genuinely bought — work too large to see the whole shape at once — is handled instead by a mapping on-ramp that runs before the pipeline, resolves the open decisions, and then merges back in at the spec. Ticket count alone never triggers it; only unresolved decisions do.
One step, one skill
Each step is owned by exactly one skill — not a preferred one, the only one. This is stricter than it sounds, and the strictness is the point. "Prefer this skill" leaves an agent free to judge, and enough of those small judgments is how a codebase ends up with three competing testing conventions and four things that all claim to review code. An exclusive mapping removes the judgment: for a given step there is one right tool, and the alternatives are simply off the pipeline. General-purpose utilities — merge-conflict resolvers, build fixers — stay available; they just can't stand in for a step.
The one-session test
At the end of the grill comes a single question that decides what happens next: could we write the spec and its tickets right now, in this window? If yes, the effort stays on the pipeline and flows straight through. If no — if open decisions survive the grill and each needs its own session to resolve — the effort first gets mapped, decision by decision, until the way is clear.
Crucially, the trigger is fog, not size. A large but well-understood effort just produces more tickets, and the ticket-cutting step handles that fine. What forces a mapping detour is not knowing, never having a lot to do.
The reuse ladder
Technology choices are made in the grill, before anything is specified, and they're governed by a ladder climbed from the top: an existing pattern already in the codebase, then a battle-tested library or component registry, then a proven external implementation worth porting, and only at the very bottom, brand-new code. Each step down the ladder has to be argued — "nothing above this rung fits, and here's why" — never simply assumed. Adopting beats building; building is the last resort, not the first instinct.
Refactor at review, not per cycle
Test-first development traditionally cleans up after every red-green cycle. This pipeline defers that cleanup to a single consolidated pass at the end of each ticket. On work moving at agent speed, refactoring after every cycle mostly polishes code that the next slice rewrites anyway. One deliberate pass, with the finished shape of the whole ticket visible, refactors better and wastes less.
Humans stay in the loop — deliberately
The pipeline is built to run largely on its own, which makes the places it insists on a human worth naming. Three steps are human-in-the-loop: the grill (the human holds the context that isn't written down yet), the prototype (only a person can react to how something feels), and the review (merging is publication, and the agent never merges its own work). Review in particular happens in a scheduled window rather than on demand — batching it keeps human attention a deliberate expense instead of a constant interruption, which is why pull-request sizes are set on purpose earlier in the flow.
Context is precious — hand it off, don't lose it
Two rules protect the thing the pipeline actually runs on: understanding. The early steps — grill, any research or prototype detours, and the spec — happen in one unbroken window, because a grill that's been summarized and replayed to a fresh session has already lost the nuance the spec exists to capture. And when work genuinely has to continue in a later session, it ends with a compact handoff — references rather than duplicated detail — written somewhere durable that the next session will actually read. A memory layer that evaporates on restart isn't a memory layer.