用途：通过交互式发现流程编写技术设计文档（TDD），记录架构决策、实现计划与风险评估。TDD 关注“如何构建”，区别于 PRD（定义做什么与为什么）、RFC（提议与决策重大变更）、ADR（记录已定架构决策）。
核心原则：架构优先于实现。判断标准是“换框架后是否仍成立”，成立则纳入（API 契约、数据模式、组件图、技术选型理由、回滚策略、日志/事件模式），不成立则排除（CLI 命令、代码片段、框架语法、文件路径、工具配置）。
文档结构：必备章节包括头部元数据、上下文、问题陈述与动机、范围（V1 至少各 3 项纳入与排除）、技术方案（架构图、组件、数据流、API 契约、数据库变更）、风险（至少 3 条，含影响、概率、缓解）、实现计划（垂直切片、曳光弹策略）。按项目类型确定关键章节：安全（支付/认证/PII）、测试策略（所有项目建议）、监控、回滚计划（生产系统）。按项目规模建议可选章节。
实现计划：每阶段为贯穿各层的垂直切片，交付可部署增量；第一阶段为曳光弹，最简单端到端流程验证架构；测试嵌入每阶段，不设独立测试阶段。
流程：先收集项目名称、规模、类型与问题陈述，再补齐必备信息，确定关键章节，提供建议章节，最后生成文档并对照校验清单，输出摘要。文件写入 .specs/[feature-slug]/TDD.md，slug 由功能名转为小写连字符。
限制：具体支持的项目类型、命令与平台集成方式资料未提供。