spec

spec — 规格修改器

如果尚未加载，请阅读仓库根目录中的 FORMAT.md。此处所有写入均适用 Caveman 技能。

分派

检查用户请求和项目状态：

1. 仓库根目录没有 SPEC.md，且参数描述了一个想法 → NEW
2. 没有 SPEC.md，且参数中包含 from-code → DISTILL
3. 存在 SPEC.md，且参数以 bug: 开头 → BACKPROP
4. 存在 SPEC.md，且参数以 amend 开头 → AMEND
5. 存在 SPEC.md，且没有参数 → 询问用户选择哪种模式

输入 — spec 是唯一的修改器

其他动词会生成材料；spec 负责写入。将它们的交接块纳入相应章节，展示差异，并在用户确认后写入：

• grill → 精炼后的 §G + §C
• research → §R 行（若缺少 §R 章节则添加）
• review → 起草的 §V 条目 + 风险判定
• deepen → §I/§V/§T 修订

⊥ 不要改写交接内容未指明的章节。章节所有权分区（见 FORMAT.md）。

NEW — 想法 → 规格

输入：用户的想法。如果想法不够明确，优先先运行 grill。

步骤：

1. 提取目标（1 行，Caveman 风格）。→ §G。
2. 列出用户明示或暗示的约束。→ §C。
3. 列出用户提到的外部接口。→ §I。
4. 仅当运行了 research 时才添加 §R；否则省略该章节（保持适当规模）。
5. 提出初始不变量。→ §V（编号为 V1…）。
6. 将目标拆分为有序任务。→ §T 管道表，所有状态均为 .，ID 为 T1…。
7. 添加 §B 章节，只含表头行（id|date|cause|fix）。

写入 SPEC.md。向用户展示完整文件。询问：“spec 可以吗？如果影响范围大，请运行 /review；否则运行 /build。”

DISTILL — 代码 → 规格

检查仓库。生成 §G（从 README/package.json/主入口推断）、§C（从技术栈推断）、§I（枚举公共 API/CLI/配置）、§V（从测试和断言推导）、§T（每个已知 TODO 或缺失测试对应一个任务）、§B（留空）。

全文使用 Caveman 风格。对不确定的条目在文本中标记 ?，供用户确认。

BACKPROP — 错误 → §B + §V

输入：bug: <description>。

步骤：

1. 解析错误描述。
2. 查找根因（阅读相关代码）。
3. 判断：新增不变量是否能防止问题再次发生？如果可以 → 起草 V<next>。
4. 追加 §B 行：B<next>|<date>|<cause>|V<N>。
5. 将新不变量追加到 §V。
6. 如果修复也会改变行为 → 添加或更新 §T 行。
7. 展示差异。仅在用户确认后应用。

规则：每个错误都必须有一条 §B 记录。不变量可选，但建议添加。

AMEND — 定向编辑

输入：amend §V.3 或 amend §T 等。

读取该章节。展示当前内容。询问用户要做哪些更改。写入后展示差异。

绝不悄悄改写用户未指定的章节。

输出规则

• 按照 FORMAT.md 使用 Caveman 格式。
• 原样保留标识符、路径和代码。
• 编号必须单调递增——绝不重复使用 §V.N 或 §B.N。
• §T 行的 cites 列！列出 §V/§I 依赖项：T5|.|impl auth mw|V2,I.api。

非目标

• 不使用子 Agent。由主线程写入。
• 不创建仪表板、日志或 SPEC.md 之外的状态文件。
• 规格完成后不自动构建。由用户明确调用 build。