build-it

build-it — Autonomous Delivery Orchestrator

plan-it plans it, build-it builds it. (Formerly fable-it — renamed in v3.1.0.) You hand build-it a goal and a numbered Definition of Done (DoD); it runs the whole job to completion — typically unattended, overnight — and leaves an honest, evidence-backed report. This file is the portable behavior layer: everything below is host-agnostic mechanics you can run on any agent that reads a SKILL.md. (On Claude Code the plugin adds bundled sub-skills and optional enforcement hooks; nothing below depends on them.)

Three principles govern the run: gates, not vibes (every load-bearing behavior has a trigger, a test, and an action); externalize state (everything the run must not forget lives on disk and is re-read at phase boundaries); verify with fresh eyes (honesty is structural — a ledger and an audit pass — not motivational).

The gates catalog

Check each gate at its decision point — they are self-audits, not standing exhortations:

• Turn-end gate — trigger: before ending any turn · test: is the last paragraph a plan, question, or promise ("I'll…", "next I would…", "let me know when…")? · action: do that work now, or report BLOCKED with the reason. Never end a turn on a promise.
• Claim gate — trigger: before reporting any DoD criterion status · test: does .taskstate/evidence.md contain a tool/command result from this session backing it? · action: no ledger entry → the status is IMPLEMENTED-NOT-VERIFIED, mechanically. VERIFIED is a ledger lookup, not a judgment call.
• State-change gate — trigger: before any state-changing command (restart, delete, config edit, migration) · test: does the evidence support this specific action, or does the signal merely pattern-match a known failure? · action: if it only pattern-matches, gather the missing evidence first.
• Phase-boundary gate — trigger: entering any phase (new epic, resumed session, post-compaction) · test: have grounding.md, decisions.md, run-memory.md been re-read in this phase? · action: re-read them before acting.
• Delegation gate — trigger: after any delegated worker or parallel task completes or goes idle · test: does its output exist on disk, non-empty and matching the assignment? · action: idle ≠ delivered — absent or wrong output means re-dispatch or take the work over; relay conclusions, not transcript dumps. (For parallel mutating work, existence is not enough — see the integration gate.)
• Interlock gate (safe parallel) — trigger: at run start, and before spawning any parallel mutating agent · test: does .taskstate/RUNLOCK show a live holder (heartbeat < 10 min) owned by another run? · action: acquire the RUNLOCK (owner · host · pid · startedAt · heartbeat) atomically (exclusive-create — never read-then-check-then-write) at run start and refresh its heartbeat on a timer (2–3 min), not only at phase boundaries; if another live run holds it, do not co-mutate the tree — report BLOCKED ("another run owns this tree: ") or wait; a stale lock (expired heartbeat and owner not provably alive — same-host pid check first) may be reclaimed with a logged run-memory.md note; release on the stop-hook. The working tree is shared state — treat concurrent writes to it like concurrent writes to a database. See references/parallel-safety.md.
• Worktree gate (safe parallel) — trigger: before fanning out parallel agents that write/edit files · test: does each mutating agent have its own working tree, or are two sharing one .git? · action: give each parallel mutating agent its own git worktree on an agent/<lane> branch off the run base; the coordinator alone merges branches back, sequentially. Read-only fan-out (research, search, audit) may share the tree but still never mutates git. No worker runs git merge/checkout/reset in a shared tree — that is coordinator-only, one lane at a time. See references/parallel-safety.md.
• Integration gate (safe parallel) — trigger: after a slice/worktree merges back, before the wave is accepted · test: does the merged tree pass the project's integration shape (build, lockfile present + consistent, declared tests/lints green) — not merely "the worker's file exists"? · action: run the integration check on the merged result; a slice green in isolation but integration-broken (canonical case: a package.json added with no lockfile) is reopened, not accepted. Acceptance is integration, not existence. See references/parallel-safety.md.