Fiuto: planning and building a feature with the build agent

Context

The components exist in Ladle, with a brief and a Linear project ready for the build agent; this is the first part of the arc where production code is written. What runs on the server and when it ships, how the work splits into phases, whether the plan is reviewed before anyone builds from it, and what each phase has to pass before it merges are still open. The /build family runs that sequence from the Linear project; this part follows which of those decisions came back to me during the run, and where I overrode the pipeline’s own choice to move faster.

The planning decisions

Five things had to be settled before the first phase could start.

1. Whether the code carrying the design was fit to build on. The translated components rendered in Ladle, but their code had circular dependencies and the pull request was blocked, so the render alone did not prove they could enter the codebase.
2. The architecture: whether the edge function that runs the server side behaviour is delivered with everything else at once, or held back for a later, more cautious phase.
3. The shape of the plan: phases that can be implemented and checked on their own, with what does not fit deferred to its own ticket instead of being squeezed into a phase.
4. Whether the plan is reviewed before implementation, since an error in the plan is repeated in every ticket built from it.
5. What each phase passes before it is pushed: a verification of the code it produced and a check of its structure.

Those roles usually belong to an architect, a lead, a reviewer and whoever runs QA. Here they are stages in one pipeline, and the ones the agent cannot settle from the brief come back to me as questions.

01The pipeline

Planning and implementation in the /build family

The /build skill is a separate family from the /ux one of the previous three articles. It takes the Linear project the UX agent created, with its brief, and runs each stage in a fresh agent, reading the state of the project in Linear to decide what comes next. Bounded fixes do not go through it: /lean works inline in one session and escalates to /build only when the change is too large for one context window.

Three decisions come back to me: the answer to any question planning hands back, whether the plan is reviewed before implementation, and whether the plan in Linear is one I want built.

02The session

What is in this video

What the build agent was handed contained a brief, a Linear project and a set of translated components that rendered well in Ladle. It did not contain code fit to build on: the translator runs no code health check, and the code it generated had circular dependencies. The pull request was blocked, so before anything could be built I fixed the code with /lean, in one session and without the planning process.

At 2:49 I invoke /build with a link to the Linear project the /ux agent created. The link alone would do, but since that agent also wrote a brief I add one instruction: review it before proceeding. Planning reads the Linear material and the code and returns a draft plan with a question.

The question, at 3:46, is whether to deliver everything at once, including the edge function that runs the server side behaviour, or to phase it. My instinct is the single delivery, a little riskier but acceptable here. It is an architecture question, though, and I cannot answer it with confidence, so I ask for a light market research pass on that one decision. A Sonnet agent researches it and returns one recommendation, the orchestrator adopts it, and planning continues.

The plan comes back as two phases plus a deferred ticket for the two-line hybrid for mobile. The orchestrator then wants to skip the independent plan review, which the skill allows to save time, and at 5:19 I ask for at least one review before implementation. It comes back having reviewed the plan with three agents: they find one serious blocker and a few suggestions, and the plan is edited in Linear before anything is built. Each issue carries its phase, blockers and priority, and the agents’ comments, so a new session can follow the tickets through without the feedback that produced them.

9 min Watch on Loom

Implementation starts on phase A at 6:19. I do not show every phase: each one gets a QA companion that verifies the code and a code health pass before the code is pushed to GitHub. I had started that morning, with a break of two or three hours, and at the time of recording I expected three to four hours of work in total and the feature delivered by the end of the day.

The three to four hours are a forecast made on camera; the measured delivery timing belongs to the next part, so this article stops at the forecast. The forecast also did not cover what the run had already got wrong. The research answered an architecture question after planning had started. Every phase carried a QA companion. The translated components reached a pull request with no check of their structure. The plan review is no longer optional on high-blast work: a high-blast brief and plan each receive one independent review, and low-blast work records the skip. A new feature now gets a focused research pass before planning, direct competitors first, then other sectors with the same job. A QA companion is added only where a mistake is expensive, with verification the default.

Conclusion

The edge function question came back before any code was written, and that is the pipeline working as intended: the agent met an architecture decision it could not settle from the brief and stopped to ask. Research scoped to that one decision answered it faster than I could alone. The plan review I had to ask for found a blocker that would have been repeated in every ticket built from the plan, on a feature with backend risk, and a high-blast plan now gets that review by default. Two things let planning start at all in a repository with a project tracker: a brief with no open product decisions, and a project the planning agent can read from a fresh session. The review makes the resulting plan safe to build from.