This is the third article in the arc on building one new feature end to end. The first two took a blank screen to high fidelity mockups, then turned the picked mockup into real components. This one is delivery: an agent takes those components and the project that came out of the design step, and implements the feature in the app.
Delivery is where I type the least and decide the most. The pipeline stopped for decisions before it wrote a line of the feature. One of them I could not make, so I asked for a small piece of research and defaulted to what it recommended.
The components were not shippable yet
The step that generated the components in Ladle, a component workbench where components render in isolation, outside the running app, does not run a code health check when it finishes. The code it produced had circular dependencies in it, and the PR was gated. I could not open it without reviewing the code first.
Nothing was wrong with the design. The problem was structural, in the code carrying it, and the step that wrote that code does not look for it.
I fixed it with /lean, the speed lane I use for small changes. It is a coding skill, and a skill is a named instruction file the agent loads on demand. /lean works inline rather than running a full set of phases, and I use it for bugs and things of that size. If it decides the change is too large to deliver inside one context window, it escalates into the build process instead.
Handing the project over
For delivery I have a separate skill, /build. It takes the components, opens the Linear project, and implements the end to end solution in the app. Linear is where the project, its brief, and its tickets live.
So I called /build with a link to that project. The UX agent created it at the end of the previous step, and wrote a brief into it as well. I could have left the prompt at the link. Because of the brief I added one line: please review the brief before proceeding.
It went into planning. It reviewed the information in the Linear ticket correctly, and the code as well. Then it came back with a draft plan and a question.
The question I could answer
It asked whether it should deliver everything from the get-go, including the edge function that runs the server side of the feature, or phase it, which is the more cautious approach. That one I answered. Everything in one go. A little riskier, but it should be okay in this case.
The question I could not answer
Then it asked an architecture question, and I honestly did not know how to answer it. That happens.
What I did was ask for a light market research pass on that one question, so I could make an informed decision. A research sub-agent went off with the exact question the orchestrator had raised. The orchestrator is the /build session that runs the phases. The sub-agent came back with a single answer, carrying a recommendation on either option.
The recommendation came back quite strong, and the orchestrator recognised it as the decision to follow. Planning continued.
This comes up sometimes. The question gets scoped down to the single decision, and one sub-agent answers that alone. I default to its recommendation and planning moves on.
The review I insisted on
The plan came back decomposed into two phases, plus a deferred mobile ticket.
Then the orchestrator wanted to skip the independent plan review. That is allowed. I put the skip in the skill myself, to make normal work faster, and normally I let it take it. Not this time. I wanted to know the plan had no bugs or issues in it and had been thought through, so I asked for at least one review before implementation started.
Funnily enough, it changed its mind and ran the review with three agents. So I probably needed a review. It found a blocker, which is quite serious, and a few suggestions to improve the plan. It made some edits on the Linear output, then dispatched the plan.
What the plan looks like when it is done
Every issue carries its phase, its blockers, and its priority. In the detail there are also comments the agents added while reviewing. So a new session can follow through all of them autonomously, without any of the feedback from this session, which is great.
Implementation
With the plan reviewed, the orchestrator started phase A. Every phase runs the same way. It implements, then a QA companion verifies the code. The companion is a paired ticket holding the checks that phase has to pass. Then a code health pass runs, and only after that does the code get pushed to GitHub.
I had started that morning, and a two or three hour break fell in the middle of the day. At the point of recording I expected three or four hours all in, and the feature fully delivered by the end of the day.
How to run this with your own agent
- Health check the code before you plan against it. A step that generates components from a design does not necessarily check its own structural health, so run your check on that step’s output, not only on the diff you are about to merge.
- Point the planning agent at the ticket and at the brief, and tell it to review the brief before planning. A plan checked only against the code in the repo will build what is already there rather than what the feature is meant to do.
- Answer the questions it raises before implementation starts. Every phase after that is built on the answer.
- When you cannot answer one, cut it down to the single decision, dispatch a short research pass on that question alone, ask for one recommendation, and default to it.
- Do not let the pipeline skip the independent plan review on work that matters. Allow the skip for speed, then override it when the plan is load bearing.
- Require phases, and require each phase to carry its own verification and a code health pass. Nothing gets pushed until both are done.
- Write the plan so a fresh session can execute it cold: phase, blockers, priority, and the review comments on the ticket itself.
The next article covers shipping it.
