Agent development flow¶
Once the director has made a decision and tasks are in TASKS.md, the work runs through a short, repeating sequence: build, prove, commit. How do I get things built? walks through one run of it.
Build¶
The orchestrator picks the next ready task from TASKS.md, high-severity bugs first, and hands it to a builder in a fresh, empty context.
- The builder reads the files named in the task's
Touchesfield, the rows of the architecture table the task involves, and the design sections it names. - The task's size picks the model that builds it. See Task and model sizing.
- A design question the task does not settle stops the build: the builder reports it as blocked, with options, and the director decides. See Design calls.
- The builder returns a structured report of about 20 lines. The orchestrator keeps the report, not the code, so ten tasks cost about as much context as one.
- A research item (
R<n>) goes to a researcher the same way, in a fresh, empty context. Its size picks the researcher's model, as a task's size picks the builder's. When it informs an open question, finishing it makes that question ready for a design call; the question stays open until the director decides. See /research.
Prove¶
One check defines done. See The check.
Large changes, and medium ones that cross a risky boundary, also get an independent review before the commit. See Reviews. A research item skips both, since it changes no code.
Commit¶
One task, one commit, with the task's records in the same commit. A research item's note is committed with its records in the same way. A commit needs the director's approval, which a run the director asks for gives in advance (see /next-task); an approval prompt from the assistant counts. The git pre-commit hook runs the check before any commit that touches code, so a failing task cannot land.
After the commit, the records hold everything about the task. The next task can start after /clear, or in a new session, without losing anything. See Records in files.
After the loop¶
The director checks the running product, not just the tests. Each framework has a human round for that, which turns findings into bugs and design proposals that feed back into the design-calls step.
| Framework | Human rounds |
|---|---|
| Godot-Director | /playtest for how the game feels; /function-check for whether each built rule works |
| App-Director | /acceptance for whether each built behaviour works in the running app |
| SaaSAllTheThings | /acceptance for whether each built behaviour works; /feedback for customer and pilot sessions |