Prepare, Doing, Review, Deliver, Verify and Close can look like ceremony. They exist because I kept hitting very normal software-engineering problems once agents started doing more work.
The first version was much simpler
My early workflow was basically: give an agent a task, let it work, inspect the result.
That is still the right workflow for plenty of tiny changes. But once I started giving agents larger tasks and running several in parallel, the failure modes became familiar.
The request was ambiguous. The agent made an assumption I didn't notice. It changed more than expected. Tests passed but didn't prove the thing I cared about. Or I reviewed a large diff without understanding why half of it existed.
Prepare exists because implementation is too late to discover the task
Before a non-trivial Card changes code, I want an agent to investigate the request and the codebase.
It should work out scope, likely files, dependencies, whether the work can live in an isolated worktree, how the project is run and tested, how delivery works and how we will verify the result.
This is deliberately more than 'make me a plan'. A plan that only lists files to edit is not enough. I want the Card to describe the behavior that should be different afterwards and the check that proves it.
I want to decide what done means before the implementation agent starts optimizing for done.
Doing should be boring
Once the Card is prepared, a fresh agent can pick it up and work through it.
For code changes, Grid normally gives it an isolated Git worktree. That gives parallel work a very useful physical boundary. One agent can make a mess in its worktree without changing the checkout another agent is using.
Doing is where most tool calls happen, but it isn't where I want most human decisions to happen. If Prepare did its job, implementation should mostly be execution against an understood task.
Review exists because I am still responsible
This is probably the part I care about most.
My code gets reviewed by peers. I am responsible for what I submit. So I need more than a green test result and a diff.
I want the review state to explain what changed, why, assumptions, deviations, important files and anything that deserves my attention. If the application can be run locally, I want to look at the result too.
Review isn't there to rubber-stamp the agent. It is there to make it practical for me to challenge the work.
Deliver and Verify are separate on purpose
Getting code out of an isolated worktree and proving it works are different jobs.
I like that separation because 'the agent ran tests while implementing' and 'we verified the delivered result' are not necessarily the same statement.
Close is where useful knowledge survives
After the work is done, the Card can leave behind useful project knowledge: how to run something, a testing trick, an architectural decision, a weird codebase fact.
Over time that means new Cards start with more project-specific context and spend less time rediscovering the same things.
This should not happen to every task
I learned this the annoying way. If a two-line change goes through every possible stage with expensive models, Grid is slower than opening a Claude shell and doing it directly.
So difficulty can change the process. Easy work can skip unnecessary stages. Hard work can get stronger planning, more checks and an adversarial reviewer.
The workflow is an opinion, not a law
I like Prepare -> Doing -> Review -> Deliver -> Verify -> Close because it currently works well for me.
I don't think everybody should be forced into it.
The prompts are editable. The plugin architecture exists partly so more of these decisions can move out of core. If another engineer has a better review step or a better way to prepare work, I want that to be something Grid can learn from rather than something the core fights.
Comments