菜单
Use when 用户需要编写产品需求文档、整理功能需求、拆解 GitHub Issues 或制定实施计划时。触发场景：写PRD、产品需求、需求文档、prd、需求分析、功能设计、产品设计、需求评审、需求拆解、issue拆解、帮我写需求、整理功能点、我有个想法要落地、新功能规划。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
超压缩通信模式。通过去掉废话、冠词和客套语，在保持完整技术准确性的同时削减约 75% token 用量。 当用户说"caveman 模式"、"简洁模式"、"少废话"、"省 token"、"简短点"或调用 /caveman 时触发。
对用户的计划或设计进行不留情面的深度追问，直到达成共同理解，逐一解决决策树的每个分支。当用户想要压力测试计划、检验设计时触发。触发词：追问我、grill me、逐一问我、挑战我的方案、深度追问、质疑设计、设计评审追问。
将当前对话压缩为交接文档，供下一个 Agent 会话接续工作。触发词：交接、handoff、下一个会话、会话摘要、接续工作、传给下一个 agent。
在代码库中发现架构"深化"机会——将浅模块变成深模块的重构，提升可测试性和 AI 可导航性。与 architecture-advisor 互补：architecture-advisor 设计新架构，本技能改善现有代码库结构。触发词：改进代码库架构、架构深化、找重构机会、模块耦合太紧、难以测试、代码难以理解、架构改进、improve architecture、refactor opportunities。
快速验证设计的一次性原型。区分两条分支——逻辑/状态模型用终端交互 App，UI 布局用多变体路由切换。当用户想原型验证、检验数据模型或状态机、探索多种 UI 方案时触发。触发词：原型、prototype、验证方案、快速试验、让我玩一玩、试几个设计。
Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。
| name | prd-engineer |
| description | Use when 用户需要编写产品需求文档、整理功能需求、拆解 GitHub Issues 或制定实施计划时。触发场景：写PRD、产品需求、需求文档、prd、需求分析、功能设计、产品设计、需求评审、需求拆解、issue拆解、帮我写需求、整理功能点、我有个想法要落地、新功能规划。 |
铁律：PRD 不写具体实现代码。描述"做什么"和"为什么"，而非"怎么做"。实施决策留给开发者。
在完成**阶段一（问题理解与背景探索）**和至少**2 轮迭代访谈**之前，禁止开始编写 PRD 正文内容。 直接根据用户第一条描述就写 PRD 是最常见的质量问题来源。启动时询问用户选择模式：
请选择工作模式：
1. 仅写 PRD — 输出产品需求文档
2. PRD + Issues — 文档 + GitHub Issues 拆解
3. 完整模式 — 文档 + Issues + 实施计划（最详细）
Step 1.1：初始问卷
以下问题按重要性逐步询问（不要一次性全问）：
优先问（必须回答）：
按需追问：
Step 1.2：探索代码库（如果有相关代码）
# 了解现有相关模块
rg "相关关键词" --type py --type ts -l
# 查看相关文件的接口
cat relevant_file.py | head -100
识别：现有的接口契约、数据模型、相关业务逻辑。
用苏格拉底式提问帮助用户厘清需求（每轮问 1-2 个问题）：
经过 2-3 轮迭代，需求应该足够清晰。
加载 references/prd-template.md，填充以下内容：
必须包含：
不得包含：
将 PRD 草稿分节展示给用户确认，每节得到批准再继续。
加载 references/issue-breakdown-guide.md。
将 PRD 中的用户故事拆解为 GitHub Issues：
Issue 粒度原则：
Issue 类型：
feat: 新功能test: 测试覆盖docs: 文档refactor: 重构（如有必要）加载 references/user-story-guide.md 中的实施规划部分。
输出：
提交前检查：
遇到以下想法，立刻停下——没有经过迭代访谈的 PRD 是不合格的：
| 借口 | 现实 |
|---|---|
| "用户描述得很详细，直接写就行" | 详细描述 ≠ 需求已完整。边界条件、错误路径、Out of Scope 都需要通过问题确认。 |
| "我帮用户假设一下这个边界情况" | 假设需求会导致 PRD 偏离用户真实意图，后续返工成本极高。 |
| "PRD 里写一些实现细节让开发更清楚" | PRD 描述"做什么"和"为什么"，绝不写"怎么做"。实现决策属于开发阶段。 |
| "访谈太耗时，用户只是想要一个文档" | 没有访谈的 PRD 是猜测文档，不是需求文档。2-3 轮提问是最低要求。 |
| "Issue 粒度大一点，开发自己拆" | 过大的 Issue 无法独立测试和交付，会成为项目管理的噩梦。 |
references/prd-template.md — PRD 标准模板references/user-story-guide.md — 用户故事编写指南references/issue-breakdown-guide.md — Issues 拆解指南