关于 build
build 是按 SPEC.md 中定义的任务实施更改的技能，采用先规划再执行的流程。它面向 Claude，跟踪任务状态、维护已声明的不变量和接口，并用指定测试与命令验证更改。
主要功能
- 01从 SPEC.md 读取任务和约束
- 02规划并引用不变量与接口
- 03执行期间跟踪任务状态
- 04运行指定测试和验证命令
- 05将失败反馈至 spec 流程
适用场景
- 01实施下一个待处理的规范任务
- 02执行指定任务或全部规范任务
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/build确认已加载。
详细介绍
build — 实施规范
单线程原生计划→执行。你是主 Claude。不要使用 swarm。
LOAD
- 阅读
SPEC.md。如果文件缺失 → 告诉用户先调用 spec skill。停止。 - 如果尚未加载，则阅读一次
FORMAT.md。 - 如果存在，则阅读 §R — 构建必须遵守的外部事实，⊥ 重新推导或与之矛盾。
- 解析调用参数：
§T.n→ 仅执行该任务--next→ 状态为.或~的编号最低的行--all或为空 → 按 §T 顺序执行每一行.
影响范围大（共享模块、身份验证、数据、资金、公开的 §I）？先运行 /review。琐碎且可逆？跳过规划流程，直接执行 EXECUTE 步骤。
PLAN
原生计划模式 — 由它来拆解任务，不要自行重新拆解。针对选定的任务：
- 引用所有适用的 §V 不变量。计划必须全部遵守。
- 引用涉及的每个 §I 接口。计划必须保留其形态。
- 列出要创建／编辑的文件。
- 验证约定 — 指明能证明每个涉及的 §V 的确切测试／验收标准。要指出具体测试，而不是“添加测试”。仅说“执行 TDD”会适得其反；规范明确指出了要检查的内容。每个涉及的 §V 都要有一个先失败的具名测试。
- 指定验证命令（测试、构建、lint）— 这是外部判定标准。通过 = 完成；⊥ “看起来完成了”。
展示计划。除非处于自动模式，否则等待用户确认。
EXECUTE
按顺序逐个执行任务：
- 将 §T.n 状态单元格
.改为~。只修改 SPEC.md。 - 按计划编辑代码。
- 运行验证命令。
- 通过 → 将
~改为x。继续下一个任务。 - 失败 → 调用 backprop skill。不要盲目重试。
FAIL → BACKPROP
测试／构建失败时：
- 阅读失败输出。
- 询问：失败是（a）我的代码有 bug，（b）规范有误，还是（c）未指定的边界情况？
- 如果是（a）→ 修复代码并重新运行。不要修改规范。
- 如果是（b）或（c）→ 先使用
bug: <cause>调用 spec skill，让它更新 §V 和 §B，然后针对更新后的规范继续构建。
规则：考虑 backprop 前，绝不能默默修复根因。§B 是防止问题复发的记忆。
WRITE POLICY
- 只修改 §T 状态。构建过程中不得对 SPEC.md 做其他修改。
- 其他规范修改 → 调用 spec skill。
- 每完成一个 §T 后提交。提交信息：
T<n>: <goal line>+ §V 引用。
VERIFICATION
任务只有在以下条件全部满足时才标记为 x：
- 验证命令（判定标准）以 0 退出。
- 每个涉及的 §V 都有验证约定中指定的具名测试，且测试通过。
- 没有任何 §V 不变量退化（最后运行完整测试套件）。
NON-GOALS
- 不使用子 Agent。不使用并行工作进程。仅限主线程。
- 不使用进度仪表板。
cat SPEC.md | grep §T就是仪表板。 - 不做超出所选任务范围的推测性工作。
评论
支持 Markdown