用途：将 PRD（或尚未成形的想法）转化为一份设计文档，写法参照 Go 官方设计提案风格——语言平实、示例具体，并重点说明为何选此方案而非其他方案。它与实现级 SPEC 不同：设计文档是决策产物，用于在写代码前让团队就同一套事实与取舍达成一致；需要字段、接口等实现契约时应改用 prd-to-spec（或先 to-design 再 prd-to-spec）。
主要能力：定位输入（文件路径、GitHub Issue、直接粘贴或口头描述想法）；可选扫描代码库，寻找既有模式、先例、兼容约束与真实痛点代码；识别真正的设计分叉并提最多 3-5 个澄清问题；按固定骨架生成文档，含标题（一句话结论）、作者、更新时间、讨论入口、Status，以及 Abstract、Background、Design、Rationale、Compatibility、Implementation、Appendix 等章节。文风要求：决策用“我们”，行为用代码作主语，说理用“你”，避免无主语被动腔；短句拍板、长句论证；段落结论先行；小标题写成完整论点句；克制诚实，不隐藏代价。
使用方式：依次完成定位输入、可选上下文分析、暴露关键决策、生成文档、评审迭代、保存（如 tasks/design-[feature-name].md）。输出前会提示重点检查 Rationale、Compatibility、Background 与文风。
适用场景：已有 PRD 需在实现前决定怎么做；方案存在真实取舍需要记录与讨论；变更有风险、破坏性或难以回退；多人需先对齐方向；需要长期留存“为何选 X 而弃 Y”的记录，即使提案被否。
限制：输入单薄时需更多澄清；无真实痛点代码可用构造示例并注明；非破坏性变更时兼容性简要说明即可；方案过大需拆成多篇并互相链接；不提供具体实现代码契约，也不替代 SPEC；质量依赖是否列出被放弃的备选方案及如实披露代价。