用途：spec-interview 用于将草稿规格（spec）与设计文档（design doc）通过深度、追问式访谈完善为完整技术文档。它在头脑风暴产出设计文档后自动运行（用户可跳过），也可在用户说"help me refine this plan/spec"或"ask me about the project"时手动触发，或当草稿规格、plan.md 缺少关键细节时运行。
主要能力：先读取目标文档并识别信息缺口，覆盖技术实现（数据结构、算法选择、依赖、接口设计）、边界情况（空值、并发、超时、极端数据量）、风险（安全、性能瓶颈、兼容性、维护成本）、权衡（复杂度与灵活性、性能与可读性）、架构决策（模块边界、依赖方向、扩展点）、验收与测试（验收标准、测试策略、覆盖期望）、可运维性（可观测性、日志、迁移/回滚策略）七个维度；然后通过 AskUserQuestion 工具进行深度提问，每轮 1-2 个相关问题，对模糊回答持续追问，并主动提出用户可能未考虑的场景。
使用方式：流程为读取目标文档→识别缺口→用 AskUserQuestion 深度提问→迭代→更新文档。若未指定目标文档或文件缺失、为空，应先询问要完善哪份文档，而不是对着空内容访谈。缺口若能由已有草稿、参考、大纲或代码库自行解决，应先自行探索填补。提问类型包括技术选型、边界处理、权衡、依赖、回退方案等。访谈完成后把澄清内容整合回原文档，保留原有结构、补全缺失细节、标注关键决策的理由、列出已识别风险与缓解措施；覆盖前需向用户展示拟修改内容（diff 或摘要）并确认，不得静默替换文档，最后提交更新后的文档，并把关键发现（被否决的备选方案、风险评估、非显然决策）持久化到 .writing/findings.md。
返回流程：若由头脑风暴调用，应将控制权交回头脑风暴清单，下一步通常是 Ask about worktree，然后 Transition to implementation；不要从此处直接调用 writing-plans。若为独立手动触发，提交更新文档后即结束。
限制与常见错误：所有提问必须使用 AskUserQuestion 工具，不要用纯文本提问；不要问草稿已回答的问题，不要问显而易见的问题，不要一次问太多，不要接受模糊回答，不要只关注功能而漏掉七个维度，访谈后必须及时更新文档。资料未提供收费、平台、价格等信息。