align

Align

将一个需求转化为规格说明、获批的接口和锁定的失败测试，让构建阶段不再有待决定事项。

源自 Shape Up 的塑形（在下注前确定投入、禁止事项和兔子洞）以及 Liu 等人 2026 年的研究（经过评审的计划有帮助；糟糕的计划比没有计划更糟）。

每个问题都遵循 grilling。每个术语和 ADR 都遵循 domain-modeling。事实来自子 Agent，而非用户；每个数字都遵循 references/spec.md 中的 Numbers 规则。切勿打开 .env、.mcp.json 或其他包含凭据的配置文件，连为了查找连接信息也不行。每条回复都遵循 EXAMPLES.md。

步骤

1. 分级。 根据 references/tiers.md 为需求定级，并确认。
   • 一句话差异：说明这一点，每行分别指出差异和任何风险，然后停止。不要提出任何建议：不提别名、垫片或后续事项。
   • 模糊不清：将每个未知事项分别发送到 /spike、/research 或 /prototype，每次只问一个问题。将每个答案记入 Decisions，然后重新定级。
   • 属于已砍掉的父项的子项：阅读父规格说明，然后跳到步骤 3。
2. 红队评审。 按照 references/red-team.md 向新的子 Agent 说明情况。展示评审结论——继续、缩小范围或不予推进——由用户决定。
3. 规格说明。 持续提问，直到填完 references/spec.md 的模板：如果一个会话能完成，就写子规格说明；否则写父规格说明。每个已确定的问题都以带日期的 Q → A 形式记录在 Decisions 中。
4. 领域。 每个新术语和每个 ADR 都需单独征得同意。
5. 接口（仅子项）。使用 codebase-design 提出签名：每次提出一个接口，包含代码、一个调用方和错误类型。获同意后，将其提交为可编译但会抛出异常的存根：feat: stub <capability> interface。
6. 测试（仅子项）。运行 /tester 并展示其报告，逐字呈现其中的 Typecheck: 和 Gaps: 行。即使接下来逐个询问，仍须在同一条消息中向用户展示所有缺口。任何缺口都会阻止锁定：接口缺口转到步骤 5，规格说明缺口转到步骤 3；绿色测试、过时锁定或类型检查缺口则交由用户处理：对于绿色测试，询问是否保留该测试，以及测试应如何表述；对于过时锁定，先让用户自行移除（! git rm <file>），再重新锁定该行；对于无法运行的类型检查，通常需要安装依赖并重新运行 /tester。若用户同意且没有缺口，则提交 test: lock <capability> tests。
7. 收尾。 按照 references/spec.md 中的 Numbers 规则检查每个数字，然后将规格说明写入工单正文；若有分支，则推送该分支；发布会话评论并设置标签。

结束状态	标签	下一步
已锁定测试的子项	ready-to-build	/build <ref>
父规格说明	ready-to-cut	/cut <ref>
尚待外部同意	ready-to-propose	/propose <ref>
仍有问题未解决	needs-alignment，并注明问题	按其路径处理，然后运行 /align <ref>
不予推进	wontfix	说明原因，然后停止

存放位置

• 规格说明：写在工单正文中；父规格说明写在父工单上，子规格说明写在自己的工单上。它会替换正文原有内容。正文中不写状态；状态由标签表示。
• 代码（仅子项）：存根和锁定测试放在 feat/<capability> 上，并创建关联工单的拉取请求草稿。跨多个仓库的子项，须按照 references/spec.md 的要求，在标题行列出每个仓库的分支和合并顺序。父项没有分支。
• 会话评论：每个会话一条，只记录进展。

每个会话只处理一个子项；下一个子项从头开始。因锁定测试失败而停止的构建须返回此处：先修改规格说明，再由用户移除过时测试，然后仅针对已更改的行执行步骤 6。