Spec First：把「先写规格」做成 9 个技能，一个 spec 一条分支、一次提交

它把哪些步骤固定下来

官网给出的主流程有四个技能。create-spec 只写目标、步骤、带文件和行号的事实、以及什么叫完成，不写代码；review-spec 先让脚本核对每条引用能否解析，再让一个没有对话上下文的新评审者挑错；apply-spec 按项目自己的规则写契约、代码、接线和测试；deliver-spec 让改动过一次提交门禁，推送并开 PR。每个阶段都会留下文件，下一次接着读。

评审发生在写代码之前

review-spec 的输出不是「看起来不错」，而是三种处置：BUILD（可以开工）、CUTS（砍掉某些步骤或补完成标准）、REFUSE（这份 spec 不成立）。官网举的例子是，一个 spec 想同时加 GitHub 和 Jira 两个工单来源，评审发现现有配置放不下第二种认证方式，于是把 Jira 拆成独立 spec；另一个 spec 漏了 GitHub 每页只返回 30 条的分页问题，被要求补一条完成标准。这些错误如果在实现后才发现，返工成本会高得多。

并行与恢复

每个 spec 一条分支和一个 worktree，spec id 由时间生成，两个 agent 并行也不会撞号。状态写在 context.yaml 里，机器重启或会话被清空后可以接着做。更大的改动用 deliver-series：它先检查一组 spec 之间的依赖，把不共享文件的 spec 分到同一组并行构建，合并后再统一验证、开一个 PR。

适合谁

最适合的是「需求能写清楚、但实现会牵动多个文件」的中型改动，以及需要多人或多个 agent 并行的仓库。它假设你有可运行的测试和提交门禁；没有这两样，apply-spec 的「完成」就只是模型自己说完成。反过来，一行修复、文案调整这类小活，走完整套流程并不划算。

先别急着全量切换

官网的案例和数字来自项目方自己的演示，目前没有看到独立的对照评测。接入前建议先在一个仓库里跑两周，重点看三个指标：评审阶段被砍掉的需求比例、实现阶段返工次数、每个 spec 从创建到合并的耗时。如果只有流程变长、返工没降，说明问题不在「缺规格」，而在需求本身没人拍板。

规格的价值不在于写得多完整，而在于它让「不做」和「晚点做」有了一个可以评审的入口。