Spec驱动编程

要解决什么问题

很多团队在「写规格」和「写代码」之间缺一层硬约束：Spec 里全是 TODO 和占位符照样进开发；范围在迭代里悄悄变大，却从没有「本次明确不做」的章节；规格批准后，编码代理只能从自然语言里猜输入字段和验收方式。SkillHub 上的 spec-coding 已有「模板即契约 + 状态机」思路，但缺少 Non-Goals 护栏、可执行的 DoD 闸门，以及和落地编码之间的结构化闭环。

Spec Coding Plus 是在不改动本机 ~/.workbuddy/skills/spec-coding 的前提下，用 fork 技能补齐上述缺口：模板、状态流转、scripts/check_spec.py 与保存即校验机制绑在一起，让「不过闸门不交付」成为默认纪律。

技能如何工作

规格类型与模板：按场景选 feature-spec.md、api-spec.md、component-spec.md；数据管道、算法、Infra 等第四类用 generic-spec.md；小改动用内置 tier: lite 的 minimal-spec.md，硬闸门从八道减为 G1/G2/G7/G8。

状态机：draft → review → approved → in-progress → done。新项目生成规格时，头部须含状态、创建日期、负责人；不得从 draft 直接跳到 approved，必须经过 review。

DoD 闸门：交付开发前运行 python scripts/check_spec.py {spec}.md。full 档下 G1–G8 任一 FAIL（含缺 Non-Goals、输入输出表占位、验收清单空壳等）则退出码 1，禁止交付。v1.3.5 起不只验「章节存在」，还验占位符与实质内容下限。lite 档下 G3–G6 降为建议项（ADV），不阻塞交付。

下游契约：approved 后的整份 Spec 即编码代理的输入契约；frontmatter 中的 agent_contract 提供 inputs[] 与 acceptance[]（可执行命令 + 期望），便于 parse 而非从 prose 推断。验收阶段对照同一份 Spec 的验收 Checklist 逐项核对至 done。

保存即校验：含 spec_type frontmatter 的 .md 可被 watch_gate.py 监视或经 hook_gate.py 挂到 on-save；默认 warn-only 不阻断保存，--strict 时 FAIL 才 exit 1。

适用边界与注意

• 本技能是 spec-coding 的 fork；上游更新由 SkillHub 覆盖原包，合并上游修复需手动迁入 fork，勿整包覆盖以免丢失 Non-Goals、闸门与 agent_contract 等改动。
• 逆向生成规格默认 review，结构类闸门须过，「待确认」项不计 FAIL，但验收清单应列待补项。
• agent_contract 与 lite 档部分闸门为建议项，不替代 full 档下对边界与 Non-Goals 的严肃写作习惯。