spec 用于在规划阶段之前构建需求规格，聚焦 WHAT 与 WHY，不涉及技术实现（架构、API、数据模型留待规划阶段）。若调用时参数为空，会先询问用户要规格化的工作类型（功能、缺陷修复、重构等）。
主要能力：以“研究→扩展待办→提问→写入发现→重复”的循环推进；扮演资深产品经理，挖掘隐藏需求、边界情况与用户未考虑的假设，用具体选项降低歧义。规格文件写入 /tmp/spec-{YYYYMMDD-HHMMSS}-{name-kebab-case}.md，访谈日志写入 /tmp/spec-interview-{YYYYMMDD-HHMMSS}-{name-kebab-case}.md，时间戳在 Phase 1.1 生成一次并复用；再次运行会新建文件而非覆盖。
使用方式：分四阶段。Phase 1 建立待办列表与访谈日志；Phase 2 判断是否需代码库研究（涉及代码、文件、功能、缺陷、重构、系统行为则研究，纯外部研究/分析/比较则跳过），读取相关文档并写初稿；Phase 3 迭代访谈，每轮记录问题、回答、影响与新领域，动态扩展待办；Phase 4 刷新上下文、定稿规格并输出可审批摘要（含状态机图、需求清单、关键决策、范围外项）。
适用场景：功能定义、缺陷修复、重构、迁移、集成等需要明确需求边界的工作。限制：不产出架构、API、数据模型等实现细节；若用户要求“其余自行推断”，未决项以 [INFERRED] 标记；资料未提供具体收费、平台或效果信息。