Build

by juliusbrussee7421e87d5b51No license1.1K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 7 weeks ago

Plan-then-execute implementation against SPEC.md. Native single-thread loop, no sub-agents. On test or build failure, auto-invokes the backprop skill before retrying — a failed verification always considers whether a new §V invariant would prevent recurrence. Triggers when the user asks to build, implement, execute the spec, or tackle a specific §T task (`build §T.3`, `build --next`, `implement next task`, `run the build`). Expects SPEC.md to exist; if not, defers to the spec skill.

AI-generated overview

Implements tasks from a SPEC.md file in a single-threaded plan-then-execute loop, with verification and backprop on failure.

What it does
Reads SPEC.md, parses an invocation argument to select one task, the next open task, or all open tasks, and plans each one against cited invariants and interfaces. It edits code, runs a named verification command, and flips task status cells in SPEC.md from open to in-progress to done. On test or build failure it invokes a backprop skill instead of retrying blindly, and it commits after each completed task.
When to use it
Use when the user asks to build, implement, or execute a spec, or to tackle a specific task such as 'build §T.3', 'build --next', or 'implement next task'. It expects SPEC.md to already exist and defers to a spec skill when it does not.
Requirements
Requires a SPEC.md file in the working directory, optionally a FORMAT.md, and a project verification command such as a test, build, or lint command. It also expects the backprop and spec skills to be available for failure handling. It ships no scripts; it is instructions only.

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 ~
    • --all or 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 §T is the dashboard.
  • No speculative work beyond chosen task scope.

Source and attribution

Source:juliusbrussee/cavekitinskills/buildat commit7421e87

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal