SPEC 是产品负责人角色技能，聚焦 WHAT 与 WHY，技术 HOW 交由 /architect。
用途：把原始想法、issue 或观察转化为可执行的产品规格，并写入 GitHub issue。
双模式：探索模式由用户直接调用，进行完整交互式发现；快速模式由 autopilot 在问题定义清晰时调用，先做精简访谈再出规格。判定标准：问题陈述清晰且上下文完整走快速模式；原始想法、模糊 issue 或用户明确探索走探索模式。
探索模式流程：阶段一理解，接受原始想法、issue ID 或观察，无 issue 时用 gh issue create 建骨架，有 issue 时用 gh issue view $1 --comments，加载 project.md（回退 vision.md）并阅读相关代码上下文。阶段二调查，并行启动问题探索、网络研究、代码库探索、用户影响分析等 agent，用 AskUserQuestion 验证问题框架、主要用户与成功标准。阶段三头脑风暴 3-5 个产品方案，说明体验、价值、范围与下游可能，并给出推荐。阶段四讨论循环，用户质疑、引导、锁定方向，轮次不限。阶段五成文，在 issue 上写产品规格，含问题、用户、推荐方案、验收标准、受影响文件、用户故事、成功指标、非目标、边界、验证命令、给架构师的开放问题，并附 Mermaid 流程图；范围大时拆成多个原子 issue 并用 epic 关联。用 gh issue comment $1 --body 发布，用 gh issue edit 更新标签，再用 /critique $1 压力测试。
快速模式：读取 issue 与评论，必要时最多 1-2 次 AskUserQuestion，用 codex exec 起草规格，用 thinktank 校验，发布并更新标签。
完成后可生成自包含 HTML 可视化摘要，写入 ~/.agent/diagrams/spec-{feature}-{date}.html 并打开；会话过于简单、用户 --no-visual 或无浏览器时跳过。
限制：需要 GitHub CLI 与相关技能环境；正式 Shape Up 方法论交互建议用 /shaping；具体收费、平台支持等资料暂未提供。