build

Build is a plan-then-execute implementation skill that works against a SPEC.md file in a single-threaded, native loop with no sub-agents. It triggers when the user asks to build, implement, execute the spec, or tackle a specific task (for example `build §T.3`, `build --next`, or `implement next task`). It expects SPEC.md to exist; if it does not, the skill defers to the spec skill. A distinguishing behavior is that on test or build failure it auto-invokes the backprop skill before retrying, so a failed verification always considers whether a new invariant would prevent recurrence.

The LOAD phase reads SPEC.md (stopping if missing), reads FORMAT.md once, reads section R for external facts the build must honor, and parses invocation arguments to select tasks: a specific §T.n row, the lowest-numbered row with status `.` or `~` for `--next`, or every `.` row in order for `--all` or an empty argument. For high blast radius work touching shared modules, auth, data, money, or public interfaces, it runs /review first; trivial reversible changes skip the planning ceremony. In the PLAN phase it cites every applicable invariant from section V, cites every interface from section I that is touched, lists files to create or edit, and defines a verification contract naming the exact tests that prove each touched invariant along with the verification command that acts as the external oracle.

The EXECUTE phase processes tasks in order: it flips the §T.n status cell from `.` to `~`, edits code per plan, runs the verification command, and on pass flips `~` to `x`. On failure it invokes the backprop skill rather than retrying blindly, asking whether the failure is a code bug (fix and re-run), a wrong spec, or an unspecified edge case (invoke the spec skill to update sections V and B, then resume against the updated spec). Its write policy restricts build to flipping §T status only, routing all other spec edits through the spec skill, and committing after each task with a message naming the task and its invariant citations. A task is marked done only when the verification command exits zero, every touched invariant has its named passing test, and no invariant regressed when the full suite runs at the end. Non-goals include sub-agents, parallel workers, progress dashboards, and speculative work beyond the chosen task.