用途
该技能的目标是产出生产级的技术设计文档（Technical Design Document，TDD）及其配套的架构决策记录（Architecture Decision Records，ADR，采用 MADR 格式），内容详尽到足以指导真实实现，并且可追溯，以便未来的维护者理解其依据。它明确说明这不是轻量草稿生成器。
主要能力
- 生成 TECH-DESIGN.md 技术设计文档。
- 生成 adrs/0001-{slug}.md、adrs/0002-{slug}.md 等 ADR 文件，每个决策一个文件，按记录顺序连续编号。
- 为 PRD 中的关键流程推导比 PRD 自身更细粒度的验收标准。
- 支持绿地（从零开始）和棕地（已有代码库）两类项目。
- 对棕地项目中已由现有代码确定的决策，写入 Estado: Aceptado (heredado) 的 ADR，并跳过该领域的访谈。
使用方式
该技能是对话式的，不是一次性生成。它要求绝不一次性生成完整 TDD，而是逐个引导用户完成每个架构决策：呈现真实备选方案与权衡，询问用户选择哪一个（或是否有不同想法），然后才写入反映用户实际决策的 ADR。技能说明指出，由代理独自决定、没有用户输入的 ADR 属于该技能的失败。
输入要求：
- PRD.md：必需。包含问题、用户、范围、产品级验收标准。如果缺失，应停止并索要，不得编造 PRD 内容，因为只有架构决策属于该技能。
- Design.md：可选但建议提供。如果存在，作为数据模型决策的主要输入；界面隐含的具体数据（折扣字段、状态徽章、过滤器）常能揭示 PRD 单独无法体现的模型需求。如果缺失，继续推进并在 TECH-DESIGN.md 中注明没有可用的 Design.md，不因此阻塞。
步骤 0 — 项目类型：首先询问用户这是绿地（从零开始）还是棕地（已有代码库）。绿地直接进入工作流；棕地则索要现有仓库/组件路径及现有文档（README、CLAUDE.md、先前的 ADR 或技术设计文档），在做出任何决策前阅读它们。现有选择不是空白状态：如果某决策领域已由现有代码确定（例如技术栈已是 Node.js 和 Postgres），则写入 Estado: Aceptado (heredado) 的 ADR，将现有选择记录为 Decision，并跳过该领域的访谈——除非用户明确希望重新考虑，此时按正常新决策处理，但在 Consequences 中注明它改变了既有选择。绝不提出与现有仓库已有做法静默矛盾的架构决策。如果 PRD 的新需求与现有架构冲突，应明确向用户暴露冲突，而不是单方面解决。
工作流：
- 读取 PRD.md（必需）、Design.md（如存在），以及棕地项目在步骤 0 中识别的现有仓库和文档。
- 从 assets/decision-areas.md 确定适用于本项目的决策领域（组件/仓库、数据模型、API 契约、每个组件的技术栈、状态管理、韧性/错误处理，以及 PRD 强制要求但不在该列表中的任何内容）。对棕地项目，标记哪些领域已按步骤 0 确定。
- 对每个新决策领域（未被继承选择确定的），一次一个：a. 陈述背景：为什么需要该决策，引用 PRD/Design.md 的隐含内容。b. 呈现 2-3 个真实备选方案及具体权衡（不是虚假选择——每个选项必须对本项目真正可行）。c. 询问用户选择哪一个，或是否有不同选项。等待回答后再继续。d. 立即使用 assets/adr-template.md 写入 ADR：将所选选项作为 Decision，其他作为 Alternatives considered（附未选原因），Consequences 至少包含所做选择的一个真实权衡，而不仅是好处。
- 所有决策记录后，为 PRD 中的每个关键流程推导验收标准，粒度比 PRD 自身标准更细。如果任何标准需要判断，在最终确定前与用户确认。
- 从 assets/tech-design-template.md 组装 TECH-DESIGN.md，按编号引用每个 ADR，包括继承的 ADR。
- 写入磁盘：项目根目录的 TECH-DESIGN.md；adrs/0001-{slug}.md、adrs/0002-{slug}.md 等，每个决策（新的或继承的）一个文件，按记录顺序连续编号。
适用场景
适用于需要生成生产级技术设计文档和架构决策记录的项目，尤其是希望逐个决策与用户确认、保留决策依据和权衡的场景。支持绿地项目和棕地项目。
限制
- 需要 PRD.md 作为必需输入；缺失时应停止并索要，不得编造 PRD 内容。
- 该技能只负责架构决策，不负责 PRD 内容。
- 不得一次性生成完整 TDD。
- 不得提出与现有仓库已有做法静默矛盾的架构决策。
- 质量门要求：每个 ADR 必须有 Context、Decision、Consequences（至少一个真实成本或权衡），新决策至少有一个被拒绝的 Alternative；继承 ADR（Aceptado (heredado)）豁免备选方案要求。
- 不得与 PRD 的“No alcance”部分或现有棕地代码库矛盾，除非先向用户暴露冲突。
- Design.md 中每个隐含数据的 UI 元素（当可用时）必须有对应的数据模型决策。
- 验收标准必须可验证，不能是模糊形容词。
- TECH-DESIGN.md 中每个新决策必须实际由用户回答，不能因跳过问题而由代理独自填写。
参考资料
- assets/decision-areas.md — 要走过哪些决策，以及何时添加未列出的决策。
- assets/adr-template.md — 每个 ADR 的 MADR-lite 格式，包括继承决策状态。
- assets/tech-design-template.md — 组装并引用 ADR 的 TDD 文档。