Build
Run a plan-then-execute loop against SPEC.md tasks with §V invariants and automatic backprop when verification fails.
Overview
build is an agent skill for the Build phase that plan-then-executes SPEC.md §T tasks in order and invokes backprop when verification fails.
Install
npx skills add https://github.com/juliusbrussee/cavekit --skill buildWhat is this skill?
- Loads SPEC.md and FORMAT.md; defers to the spec skill if SPEC.md is missing
- Supports §T.n, --next (lowest open task), and --all for ordered §T execution
- Plan step cites §V invariants and §I interfaces before any code edits
- Flips §T status `.` → `~` → `x` on pass; runs named verification (test, build, lint)
- On verification failure, auto-invokes backprop before retry to add §V invariants
- Single-thread native plan→execute loop with no sub-agents
- Failed verification auto-invokes backprop before retry
Adoption & trust: 1.6k installs on skills.sh; 999 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have an approved SPEC.md with §T tasks but your agent keeps implementing without invariant checks or a disciplined retry when tests fail.
Who is it for?
Solo builders using Cavekit-style SPEC.md with §T, §V, and §I who want one native agent thread to implement and verify task by task.
Skip if: Greenfield work with no SPEC.md yet, or teams that want parallel sub-agents instead of a single-thread plan→execute loop.
When should I use this skill?
User asks to build, implement, execute the spec, build §T.n, build --next, implement next task, or run the build; expects SPEC.md to exist.
What do I get? / Deliverables
Chosen §T rows move from open to done with verified code, and failed checks feed backprop so §V invariants can block recurrence before the next attempt.
- Code and tests aligned to the approved plan
- Updated §T status cells in SPEC.md
- Backprop-driven §V updates when verification fails
Recommended Skills
Journey fit
Canonical shelf is Build because the skill only runs when you are implementing rows from §T after a spec exists. agent-tooling fits spec-driven native agent execution (single-thread, no swarm) rather than a one-off integration script.
How it compares
Use instead of free-form “just implement it” chat when your source of truth is SPEC.md task rows and status cells.
Common Questions / FAQ
Who is build for?
Indie developers and small teams running Cavekit spec workflows who want Claude as main implementer with explicit §T tracking and verification gates.
When should I use build?
In Build when SPEC.md exists and you want to tackle §T.n, --next, or all open tasks after plan approval; skip when you still need to author the spec (use the spec skill first).
Is build safe to install?
It edits code and runs shell verification commands on your repo; review the Security Audits panel on this page and confirm auto-invoked backprop matches your workflow.
SKILL.md
READMESKILL.md - Build
# build — implement spec Single-thread native plan→execute. You are main Claude. No swarm. ## LOAD 1. Read `SPEC.md`. If missing → tell user to invoke the spec skill first. Stop. 2. Read `FORMAT.md` once if not loaded. 3. Parse invocation args: - `§T.n` → that task only - `--next` → lowest-numbered row with status `.` or `~` - `--all` or empty → every `.` row in §T order ## PLAN Native plan mode. For chosen task(s): 1. Cite every §V invariant that applies. Plan must respect all. 2. Cite every §I interface touched. Plan must preserve shape. 3. List files to create / edit. 4. List tests to add or update (one per invariant touched). 5. Name verification command (test, build, lint). Show plan. Wait for user OK unless auto mode. ## EXECUTE Per task in order: 1. Flip §T.n status cell `.` → `~`. Just write to SPEC.md. 2. Edit code per plan. 3. Run verification command. 4. **Pass** → flip `~` → `x`. Next task. 5. **Fail** → invoke backprop skill. Do NOT retry blindly. ## FAIL → BACKPROP On test/build failure: 1. Read failure output. 2. Ask: is failure (a) my code bug, (b) spec wrong, or (c) unspecified edge case? 3. If (a) → fix code, re-run. No spec change. 4. If (b) or (c) → invoke spec skill with `bug: <cause>` first, let it update §V and §B, then resume build against updated spec. Rule: never silently fix root-cause without considering backprop. §B is the memory that stops recurrence. ## WRITE POLICY - Only flip §T status. No other SPEC.md edits from build. - Other spec edits → invoke spec skill. - Commit after each §T completes. Message: `T<n>: <goal line>` + §V cites. ## VERIFICATION Task `x` only if: - Verification command exits 0. - New test(s) added per plan. - No §V invariant regressed (run full test suite at end). ## NON-GOALS - No sub-agents. No parallel workers. Main thread only. - No progress dashboards. `cat SPEC.md | grep §T` is the dashboard. - No speculative work beyond chosen task scope.