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 从公开仓库中收录这些内容。

举报或申请下架