用途：在启动需求尚不明确的功能，或被要求编写规格（spec）时，通过访谈、代码库探索与模块设计产出一份规格文档（PRD）。
主要能力：先探索代码库，梳理数据模型、服务、API 路由、前端与测试的现状，区分已存在与待构建内容，无法验证的说法标记为不确定而不臆造；随后进行访谈，每次只问一个问题，提供 2–4 个选项，推荐答案排在最前并标注 (Recommended)，能通过读代码回答的就不提问。访谈按分支覆盖范围与入口、数据与概念、行为、展示、访问与隐私、边界、集成等主题，其中数据与概念、边界不可跳过。之后梳理灰色地带（歧义、矛盾、未言明的假设）并给出解决方案，全部解决后再继续。接着设计模块，倾向深模块（1–3 个入口点隐藏大量实现），识别浅模块信号，并确认哪些模块需要测试。最后写入规格文件。
使用方式：以 $ARGUMENTS 传入想法，若为空则先询问问题与解决思路。从首个 —/– 之前的文本派生 kebab-case 的 <slug>（不超过 4 个有意义单词，不含命令动词或填充词），输出到 .specs/specs/<slug>.md；若文件已存在，询问覆盖（推荐）或换名。规格结构包含功能名、问题陈述、当前状态（全新项目可跳过）、解决方案（用户体验而非架构）、用户故事（编号，覆盖正常、边界与错误）、实现决策（新模块、架构决策、Schema 变更、API 契约、导航）、测试决策与范围外内容，空章节省略，不写文件路径或代码片段。完成后建议执行 /plan <slug>。
适用场景：需求模糊的新功能立项、需要先对齐范围与边界的开发任务。
限制：资料未提供具体平台、收费、价格或效果信息；不写文件路径与代码片段，无法验证的内容需标记为不确定。