Build

作者 juliusbrussee7421e87d5b51無授權條款1.1K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫7 週前更新

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 產生的概覽

以單執行緒先規劃後執行的方式實作 SPEC.md 中的任務,包含驗證與失敗時的 backprop 處理。

功能
讀取 SPEC.md,解析呼叫參數以選擇單一任務、下一個未完成任務或全部未完成任務,並針對所引用的不變量與介面為每個任務擬定計畫。它會修改程式碼、執行指定的驗證指令,並將 SPEC.md 中的任務狀態儲存格從待辦改為進行中再改為完成。測試或建置失敗時,它會呼叫 backprop 技能而不是盲目重試,並在每個任務完成後提交。
適用情境
當使用者要求建置、實作或執行規格,或處理特定任務(例如「build §T.3」「build --next」「implement next task」)時使用。它要求 SPEC.md 已存在;若不存在則交由 spec 技能處理。
執行需求
需要工作目錄中存在 SPEC.md,可選需要 FORMAT.md,以及專案的驗證指令(例如測試、建置或 lint 指令)。還需要 backprop 與 spec 技能可用於失敗處理。它不附帶指令碼,僅為指示。

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.

來源與署名

來源:juliusbrussee/cavekit位於skills/build提交7421e87

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架