Build
- 2.5k installs
- 1.1k repo stars
- Updated June 18, 2026
- juliusbrussee/cavekit
cavekit build executes SPEC.md section T tasks with invariant citations, verification contracts, and backprop on failures.
About
The cavekit build skill implements SPEC.md tasks in a single-thread plan-then-execute loop without sub-agents. LOAD reads SPEC.md or stops to invoke the spec skill, loads FORMAT.md once, honors section R external facts, and parses section T.n, --next, or --all open rows. High blast-radius auth or payments work may require review; trivial reversible tasks skip ceremony. PLAN cites section V invariants and section I interfaces, lists files, names exact verification tests per invariant, and names the oracle command before approval unless auto mode. EXECUTE flips section T status dot to tilde, edits code, runs verification, marks x on pass, or invokes backprop on failure without blind retries. Spec wrong or unspecified edges route through the spec skill with bug cause. WRITE POLICY allows only section T status flips; other spec edits use the spec skill. Commits after each task use T n goal plus invariant cites. Verification requires oracle exit zero, named tests passing, and a full suite at end.
- Single-thread plan-then-execute; no sub-agents or parallel workers.
- LOAD requires SPEC.md; parses section T.n, --next, or --all open tasks.
- PLAN names exact verification tests per section V invariant touched.
- On failure invoke backprop before retry; spec bugs go through spec skill.
- Only flip section T status cells; commit after each task with T n message.
Build by the numbers
- 2,504 all-time installs (skills.sh)
- +81 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #212 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
build capabilities & compatibility
- Capabilities
- spec.md task selection via section t.n or next · invariant and interface citation in plans · backprop routing for spec versus code failures · oracle gated completion and per task commits
- Use cases
- planning · testing · orchestration
What build says it does
On test or build failure, auto-invokes the backprop skill before retrying
npx skills add https://github.com/juliusbrussee/cavekit --skill buildAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 2.5k |
|---|---|
| repo stars | ★ 1.1k |
| Security audit | 3 / 3 scanners passed |
| Last updated | June 18, 2026 |
| Repository | juliusbrussee/cavekit ↗ |
How do I implement the next SPEC.md task with named tests and spec-safe failure handling?
Plan and execute SPEC.md tasks with verification contracts, status flips, and backprop on spec or edge-case failures.
Who is it for?
Spec-driven projects using Cavekit SPEC.md with section V invariants and section T task tables.
Skip if: Skip when SPEC.md is missing; invoke the spec skill to create one first.
When should I use this skill?
User says build section T.3, build --next, implement next task, or run the build against SPEC.md.
What you get
Completed section T rows marked x with passing oracle commands and commits per task.
- Implemented code per §T task
- Updated §T status cells
- Per-task git commits
By the numbers
- Uses a 3-state §T status workflow: open (.), in-progress (~), and complete (x)
- Defers to backprop and spec skills instead of silently editing invariants on failure
- Triggers on explicit commands including build §T.n, build --next, and build --all
Files
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. Read §R if present — external facts the build must honor, ⊥ re-derive or contradict. 4. Parse invocation args:
§T.n→ that task only--next→ lowest-numbered row with status.or~--allor empty → every.row in §T order
High blast radius (shared module, auth, data, money, public §I)? Run /review first. Trivial & reversible? Skip planning ceremony, just do step EXECUTE.
PLAN
Native plan mode — you delegate to it, you do not reinvent task breakdown. 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. Verification contract — name the EXACT test(s) / acceptance criteria that prove each §V touched. Which test, not "add tests". "Do TDD" alone backfires; the spec says what to check. Each §V touched → a named test that fails first. 5. Name verification command (test, build, lint) — this is the external oracle. Green = done; ⊥ "looks done".
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 (the oracle) exits 0.
- Every §V touched has its named test from the verification contract, and it passes.
- 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 §Tis the dashboard. - No speculative work beyond chosen task scope.
Related skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kHow it compares
Use build to execute approved SPEC.md tasks with verification; use the Cavekit spec skill first when requirements or invariants still need authoring.
FAQ
What happens on test or build failure?
Invoke backprop; fix code bugs directly or route spec gaps through the spec skill with bug cause.
Can build edit SPEC.md beyond task status?
No. Only flip section T status cells; other edits go through the spec skill.
When is planning required?
For chosen tasks cite invariants, interfaces, files, and exact verification tests unless the task is trivial and reversible.
Is Build safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.