用途：创建技术设计文档，说明要构建什么及其结构，而非逐步执行方式。核心原则是架构优先于实现：若更换框架或库后仍成立则纳入（API 契约、数据模式、组件图、技术选型及理由、事件/日志模式、集成边界）；若不再成立则排除（CLI 命令、代码片段、框架语法、文件路径、工具配置）。
用法：先检查 .specs/[feature-slug]/ 下的上游产物，CONTEXT.md 和 PRODUCT-REQUIREMENTS.md 存在时作为事实来源，避免重复提问。随后通过 AskUserQuestion 逐步收集上下文与必填信息，确认归属人、问题及量化影响、至少各 3 项范围内外条目、高层方案、至少 3 项风险及缓解。按项目类型确定安全、监控等关键章节，并按规模提供可选章节。最终生成 .specs/[feature-slug]/TECHNICAL-DESIGN.md，使用给定模板并进行校验，输出摘要列出已含与缺失章节。
适用与限制：适合需要沟通架构决策与权衡的团队。必填章节包括头部元数据、上下文、问题与动机、范围、技术方案、关键决策与权衡、风险；支付、认证、PII 或外部集成项目需安全章节，生产系统需监控章节。资料未提供具体价格、平台支持范围或独立运行依赖等信息。