the delivery workflow your coding agent has to follow
A kit is a workflow your agent has to follow, packaged so you can install it instead of writing it yourself. Builder Kit is the one for shipping code.
Point your agent at a ticket. Before it writes a line it has to pull the work, ask its questions, and produce a plan. Before it can call the job done, something has to critique it and something has to prove it — a test run, a browser check, a CI rerun, or a gap written down with your name on it. What it can't prove, it hands back to you.
$ npx @kontourai/flow-agents init --runtime claude-code --activate-kit builder --yes
Installed Claude Code bundle into …/your-repo
Flow Agents install summary:
✓ Runtime: claude-code
✓ Destination: …/your-repo
✓ Telemetry sink: local-files
- Console: local-only
$ flow-agents workflow doctor
Flow Agents CLI: 5.3.0
Installed hooks/writer: 5.3.0
Builder Kit schema: installed=1.0 resolved=1.0
Flow: builder.build@1.3
Artifact schema: state=none trust=none
Real output from v6.0.0. The absolute install path is shortened to …/your-repo and the trailing “Next steps” lines are trimmed; nothing else is changed. state=none trust=none is correct on a fresh install — no run has happened yet.
A run in progress
Every Builder run keeps its state in your repo, so you can ask it where it is from any terminal — days later, from a different machine, after the chat window is gone.
When it can't advance, it doesn't quietly declare victory. It names the step it stopped at and the next thing that has to happen, and it stays there until someone does it.
$ flow-agents workflow status \
--session-dir .kontourai/flow-agents/kontourai-flow-agents-944
builder.build@1.3 kontourai-flow-agents-944
Status: paused
Step: execute
Next: Canonical Flow run is paused. The current assignment actor may resume it with a reason.
Verbatim output from a real paused run, with the command wrapped onto two lines at the shell continuation. Those four lines come from the run's own record on disk — not from anything the agent said in chat.
What “done” leaves behind
“I've implemented the search filters and everything is working.”
The reasoning behind that lives in a context window that gets compacted. To check the claim you re-read the diff and take its word for the rest. Six weeks later there is nothing to open.
$ ls -1 .kontourai/flow-agents/kontourai-kontourai-io-206/
acceptance.json
command-log.jsonl
handoff.json
kontourai-kontourai-io-206--deliver.md
learning.json
state.json
trust.bundle
trust.checkpoint.attestation.json
trust.checkpoint.intoto.json
trust.checkpoint.json
Verbatim listing from this site's own repo — the session that shipped kontourai.io#206. Plain files, committed alongside the change. No login, no dashboard, no scrollback to lose.
state.jsonacceptance.jsonhandoff.jsontrust.bundlecommand-log.jsonllearning.jsonThree flows
In: "we should let people filter search results." Out: a scoped ticket with acceptance criteria, the things it deliberately will not do, and the questions nobody had asked yet.
The agent pulls the ticket, probes the repo, writes a plan, implements it, gets critiqued, then has to prove it. Missing proof stops the run instead of ending it.
PR opened, CI rerun reconciled against the diff that actually landed, merge-or-hold called out loud, and the corrections written down so the next run starts sharper.
What keeps it honest
Shaping, probing and planning are separate steps from implementation, and the planning steps are not allowed to write code. The agent arrives at the keyboard with a route instead of a prompt.
Review runs ahead of verification, so an architecture miss routes back to the step that caused it rather than getting absorbed into a summary and forgotten.
Test runs, browser checks, source inspection, CI state and known gaps land as files in your repo. If the evidence is missing, the run refuses or escalates to you — it never quietly proceeds.
What it does not catch: a passing test run recorded before a later edit, a test whose scope was quietly narrowed, or a test edited until it passed. Those stay a reviewer's job — what the kit contributes is that the reviewer has the plan, the commands and the diff in front of them.
What it handles that a prompt doesn't
Opening the PR, reconciling CI against the diff that actually landed, calling merge or hold, and writing down the corrections is one flow — builder.publish-learn — not an afterthought bolted onto the end of a build.
Steps carry routing hints for how much model the work needs, and a failed gate can escalate to a stronger one instead of retrying the same one harder.
The session state lives in your repo, not the chat, so a job started in Claude Code can be picked up in Codex with the same plan, evidence and next action. How hard the gate can push depends on the tool you're in.
A delivery too big for one sitting gets explicit continuation bounds, so the next session resumes with the scope, the evidence so far, and the next action intact instead of starting over from the ticket.
First run
Install it, then say to your agent: “Use deliver for issue #412” — your issue number. It picks the work up, asks you what it needs, and starts leaving files behind.
The honest cost: the first job is slower. You wait for a plan before you see code, you wait for a critique before the verify pass, and your repo gains a directory of evidence you didn't ask for. If a gate blocks and you disagree with it, you can accept the gap — it stays in the record with your name on it rather than disappearing.
Builder brings Knowledge Kit with it — the learning step uses it to file what the reviewers corrected. Two kit directories land in your repo, not one.
$ npx @kontourai/flow-agents init \
--runtime claude-code \
--activate-kit builder --yes
runtimes: claude-code · codex · kiro · opencode · pi