该技能用于在实现之前撰写技术设计文档，产出面向人与智能体均可用的决策记录。文档有三重用途：作为思考工具，迫使作者先规划再编码；作为评审物，在实现前发现设计缺陷；作为决策记录（ADR），保留决定内容与原因。
适用时机：当符合以下三项及以上时建议撰写——对正确设计存疑、设计模糊或有争议、存在多个各有取舍的可行方案、涉及安全隐私可观测性等横切关注点、需要留下架构决策记录、知识需在团队共享。反之，方案无歧义无取舍、快速原型比前期分析更有价值、改动小到代码评审即可覆盖时，不必撰写。
创建流程分八步：理解问题（明确什么坏了、谁受影响、根因）、调研现状（架构与数据流、现有局限、当初为何这样建，需对照源码核实）、定义目标与非目标、生成多个选项并列出优缺点、用对比表比较并做出决定（是“我们决定 X，因为 Y”，而非“建议”）、评估横切关注点（安全、隐私、可观测性、性能、向后兼容）、验证完整性（完成稿应零未决问题）、按模板撰写并存到 design-docs/。必填章节为问题陈述、目标、决策、横切关注点。
文件约定：位置为项目内 design-docs/，命名为 NN-short-description.md，实现完成后移入 design-docs/completed/；被替代的旧文档需标注指向新文档的链接。更新既有文档时应追加“Update (YYYY-MM-DD)”章节说明变更与原因，并修订受影响章节，不静默编辑。规模上小型文档 1–3 页，完整文档 5–15 页，超过则拆分子问题。
评审时需逐条检查违规项并明确报告：命名、问题陈述是否含根因与影响、目标与非目标是否明确、是否探索了至少两个选项、决策与建议是否混淆、是否存在开放问题、横切关注点、是否混入实现细节、细节充分性、模板必填章节。反模式包括写成实现手册、只分析不承诺、带 TBD 就标记完成。用户批准后运行质量清单，通过后引导进入技术设计阶段。资料未提供安装命令、平台支持与收费信息。