工程师
将调研综合为两种可持久化的制品：一份可供 /implement 执行的规范，以及用于记录值得铭记的决策的 ADR。
输入：$ARGUMENTS。
零隐性假设。 每一个设计选择要么由用户做出，要么被列为假设。这包括那些感觉太小而不值得询问的选择（库、错误格式、命名、默认值、限制等），你从代码库中推断出的内容，以及你自己的建议。在整个过程中持有一个假设台账（✅ 用户已确认 · ❓ 未确认 · ❌ 已拒绝），并且永远不要将未确认的选择作为决策写入规范或 ADR。
流程
- 细化。 如果本次会话中还没有细化后的简报，先运行
/refine流程（拷问 → 验收标准）。不要带着阻碍设计的开放问题继续。如果存在简报，将其 ❓ 假设带入你的台账；在设计依赖它们的任何内容之前先解决这些假设。 - 建模。 对任何新的或变更的概念运行
/domain-modelling流程，并更新领域文档。规范必须使用这些规范术语。 - 探索代码库。 识别变更涉及的模块、接口、数据存储和测试。注意要遵循的现有模式。引用真实路径。代码今天的功能是证据，而非意图：“遵循
src/x.ts中的现有模式”本身就是一个需要与用户确认的选择，并在记录时标注来源。 - 设计。 对于每个重大决策，列出 2-3 个方案及其权衡和推荐；由用户决定，并且只有在用户明确选择后才算推荐生效。对于较小的选择，将它们批量放入一个确认列表中，而不是自行决定。考虑数据模型与迁移、API/合约变更、错误处理、安全、性能、可观测性、发布与回滚以及向后兼容性。
- 记录 ADR。 如果一个决策难以撤销、影响多个模块，或者未来的工程师会问“我们为什么这样做？”，那它就值得记录为一个 ADR。将每个 ADR 写入
docs/adr/NNNN-kebab-title.md（下一个空闲编号，4 位数字），使用 adr-template.md。如果一个 ADR 取代了另一个，更新旧 ADR 的状态。仅在用户确认决策后才将 ADR 标记为Accepted；否则保持Proposed。 - 编写规范 到
docs/specs/<kebab-title>.md，使用 spec-template.md。将工作分解为小的、有序的、可独立测试的任务——每个任务都附有证明其完成的测试。从台账中填写规范的假设部分；每个设计陈述必须追溯到用户决策，或者作为 ❓ 出现在其中。 - 与用户复核。 总结规范和 ADR，展示开放的 ❓ 项目，请求批准并调整。只要有任何 ❓ 影响任务、验收标准或 ADR，就不要将规范设置为
Approved。
规则
- 如果项目已有规范/ADR 文件夹或模板，则尊重项目现有的约定——改用那些。
- 规范描述的是做什么和如何验证，并包含足够的如何做以消除歧义——而不是逐行实现。
- 每个验收标准必须至少映射到一个任务和一个测试。
- 在变更允许的范围内保持简洁。
下一步
推荐使用 /handoff（在一个全新的会话中开始实现）或直接使用 /implement docs/specs/<file>.md。