The guided build workflow: spec, plan, build, test, review

We have all seen what happens when you let an AI write code with no plan. It works for an afternoon. Then the second feature fights the first, the third rewrites both, and someone spends a week cleaning up by hand. Speed without structure is just faster debt.

Today the JackHamr orchestrator runs a proper delivery pipeline, and it asks you before it commits to anything expensive.

How a feature moves through it

You describe what you want in plain English. Then:

• A spec builder writes the product spec and mockups. You approve it or send it back with notes.
• A planner reads the approved spec and produces an implementation plan with the architecture decisions spelled out. You approve that too.
• Developer agents build it, one task at a time, on the agent's machine.
• QA agents test each change in a clean environment.
• Code reviewer and product reviewer agents check the result before it ever reaches you.

Two approval gates, placed where they save the most rework: after the spec and after the plan. Get those right and the build rarely goes sideways.

Working with an existing codebase

Before anyone touches a real repository, a codebase mapper reads it and writes a guide: the structure, the conventions, the modules that matter. Every downstream agent reads that guide first, so new code looks like it belongs in the repo instead of looking like it was pasted in from somewhere else.

Visible, all the way through

Decision gates render as cards in the chat with buttons. Review packets show the spec and test plan with clickable file paths. Long-running commands stream their output live inside the tool card, so a twelve-minute test run is something you can watch rather than wait for. Pipeline runs are tracked as first-class objects with a work queue and a plan panel.

You make the calls that need taste. The agents carry the rest.

This is the workflow the whole platform is built around. It is also just the first one: within weeks you could define your own.