prd-planner

prd-planner skill 概览

prd-planner 的作用是什么

prd-planner 是一个用于 Requirements Planning 的 skill。它不是靠一次超长 prompt 直接生成 PRD，而是通过可持续、基于文件的工作流来产出产品需求文档。它的核心价值不只是“写一份 PRD”，更在于把调研、假设、任务进度、最终需求和技术后续拆分到稳定的文件里，避免 agent 在过程中途丢失上下文。

谁适合使用 prd-planner

prd-planner 最适合那些不满足于“一次性 PRD 草稿”的团队或独立开发者。尤其当你需要在需求发现、边界情况梳理、PRD 撰写和技术设计之间保留可追溯性时，它会很有用。如果你预期要经过多轮迭代来打磨需求，这个 skill 会比普通 prompt 更可靠。

要解决的核心任务

用户通常会采用 prd-planner，是因为他们需要一套能承受迭代的结构化 PRD 创建流程：先澄清需求、记录笔记、产出可用的 PRD，并且很多时候还能顺势交接到技术设计。仓库对它的定位也很明确：解决上下文切换、思路丢失，以及 PRD 输出不一致的问题。

prd-planner 有什么不同

它最明显的差异点是 4-file pattern。prd-planner 不会把所有内容都塞进一段回复里，而是把 plan、notes、PRD 和 technical design 分别写到独立文件中，通常放在 docs/ 下，并共享一个 scope 前缀。对于需要回看、评审和持续扩展的 Requirements Planning 工作，这种方式更合适。

什么情况下不该用 prd-planner

如果你只想快速写一段 feature brief、做一次松散的头脑风暴，或者只需要纯架构方案文档，就不建议用 prd-planner。这个 skill 本身也明确说明：如果只是 architecture-only 请求，应该优先用 architecting-solutions，除非用户明确要求 PRD。

如何使用 prd-planner skill

prd-planner 的安装背景

这个仓库本身没有提供通用包管理式安装方式。附带的 README.md 展示的是一种本地 symlink 风格的安装方式，把 skill 挂到 Claude 的 skills 目录中：

ln -s ~/Documents/code/GitHub/agent-playbook/skills/prd-planner/SKILL.md ~/.claude/skills/prd-planner.md

如果你使用的是别的 skill loader，可以按这个思路改成你的 agent 平台所要求的目录或注册方式。若你是在 GitHub 上查看仓库，skill 位于 zhaono1/agent-playbook 的 skills/prd-planner。

建议先读这几个文件

如果你想快速完成一次 prd-planner install 和评估，建议按这个顺序读：

1. skills/prd-planner/SKILL.md
2. skills/prd-planner/README.md
3. skills/prd-planner/references/edge-case-analysis.md

SKILL.md 会告诉你它的触发规则、工作流意图、工具要求，以及核心文件模式。参考文件则补充了非常实用的 edge-case 扫描方法，能显著提升 PRD 质量。

prd-planner 如何被触发

这个 skill 的设计前提是：当用户明确提出要 PRD、说出 “product requirements document”，或者使用对应的中文表达时才触发。这一点很关键，因为它不是一个通用规划 skill。如果你的 prompt 更像“设计架构”，而不是“创建 PRD”，那就可能触发错误的工作流，或者得到偏弱的结果。

你应该预期的 4-file pattern

一次标准的 prd-planner usage 流程，会在 docs/ 下基于一个简短的 kebab-case scope 创建四个项目文件：

docs/{scope}-prd-task-plan.md
docs/{scope}-prd-notes.md
docs/{scope}-prd.md
docs/{scope}-tech.md

这就是这个 skill 的主要运行模型。如果你不想创建文件，也不需要持久化产物，那 prd-planner 很可能不适合你。

prd-planner 需要你提供哪些输入

prd-planner 在你提供以下信息时效果最好：

• 功能或产品目标
• 目标用户
• 业务目标或成功指标
• 时间线、平台、合规、现有技术栈等约束
• 已知的非目标
• 相关代码、文档、工单或示例链接

如果这些信息缺失，它依然可以起草 PRD，但会更依赖假设。

如何把模糊需求变成高质量 prompt

弱 prompt：

Create a PRD for notifications.

更强的 prompt：

Create a PRD for in-app notifications for our B2B admin dashboard.
Users are account admins and support managers.
Goal: reduce missed follow-up tasks and improve response SLA compliance.
Constraints: web app first, existing React frontend and Node backend, no push notifications in v1.
Non-goals: email campaign tooling, mobile support.
Please use docs/notifications as the scope basis and call out edge cases, permissions, and rollout risks.

后者给了 prd-planner 足够的上下文，因此生成出来的 PRD 会更具体，而不是泛泛而谈。

实际使用中的 prd-planner 工作流建议

一个更实用的工作流是：

1. 明确提出要 PRD。
2. 提供业务背景、范围和约束。
3. 让 skill 先创建整套文件。
4. 先看 notes 文件，而不只是最终 PRD。
5. 尽早纠正错误假设。
6. 再要求做第二轮补充，重点覆盖 edge cases、acceptance criteria 和技术影响。
7. 用生成的 *-tech.md 作为进入实现规划的桥梁。

这也是它优于单次 prompt 的地方：你可以通过编辑 notes 并重新综合生成来迭代，而不是每次都从零开始。

尽早使用 edge-case 参考文件

最值得优先使用的支持文件是 references/edge-case-analysis.md。它包含需求类型分类，以及用于扫描代码库模式的命令，覆盖 deletion strategy、loading states、pagination、validation、error handling 等方面。对 Requirements Planning 来说，这一点非常关键，因为很多质量不高的 PRD，恰恰就是漏掉了这些行为细节。

能提升输出质量的仓库级技巧

这个 skill 允许使用 Read、Write、Edit、Bash、Grep、Glob、AskUserQuestion 和 WebSearch 等工具。实际含义是：prd-planner 的设计目标并不是凭空生成文字，而是去检查真实代码库、主动追问澄清问题。如果你的环境禁止写文件或 shell 搜索，那它的大部分预期价值都会打折。

面向现有产品的最佳 prompt 模式

如果这个功能属于已有系统，最好在请求里直接给出代码库定位，例如：

Create a PRD for bulk user deactivation.
Relevant areas:
- `src/features/users/`
- existing soft delete behavior
- admin audit log requirements
Please inspect current list, detail, and permission patterns before drafting requirements.

这样可以把 prd-planner 引导到“基于现状形成需求”，而不是写成脱离现实的抽象产品文案。

在接受输出前要检查什么

在你把结果当成最终 PRD 之前，先确认 prd-planner 是否覆盖了：

• 用户角色和权限
• 明确的非目标
• 边界情况和失败状态
• 发布或迁移相关顾虑
• 可衡量的成功标准
• 对当前系统行为的依赖

即使一份 PRD 看起来很完整，如果缺了这些，风险依然很高。

prd-planner skill 常见问题

prd-planner 适合新手吗

适合，前提是你已经大致知道自己要做什么功能，只是需要一个结构化流程。文件化模式能明显降低“无从下笔”的压力。但它并不能替代产品思考；如果输入本身很弱，产出的需求也依然会比较浅。

prd-planner 和普通 PRD prompt 有什么区别

普通 prompt 通常只会返回一份文档。prd-planner skill 则围绕可持续的 planning artifacts 来设计，帮助 agent 把调研、进度、输出和技术后续拆开管理。这样通常会带来更好的修订质量，也更不容易丢上下文。

prd-planner 只能用于新产品吗

不是。对于已有产品，它反而可能更有价值，因为参考材料会鼓励你扫描代码库中的现有模式，从而让 PRD 更贴近真实实现约束。

我能把 prd-planner 只用于架构设计吗

不太合适。这个 skill 明确写了：如果只是 architecture-only 请求，应使用 architecting-solutions，除非用户真正想要的是 PRD。更准确地说，应该把 prd-planner for Requirements Planning 用在需求规划上，而不是当成通用设计工具。

prd-planner 是否需要文件写入权限

如果你想获得它原本设计的工作流体验，基本上是需要的。这个 skill 的核心价值就在于把内容写入文件并持续迭代。如果你的环境只有聊天窗口，依然可以借用它的 prompting 思路，但会失去持久化模型的优势。

什么情况下应该跳过 prd-planner

如果你只需要一小段一段话的 brief、单条 user story，或者还处于没有稳定范围的探索式创意阶段，就可以跳过它。4-file 流程的成本，通常只有在 PRD 需要评审、修订或移交给工程团队时才真正划算。

如何把 prd-planner skill 用得更好

给 prd-planner 提供更清晰的 scope 定义

影响质量最大的杠杆就是 scope 清晰度。给出一个简短、唯一的 scope 名称，并明确什么属于 v1、什么不在范围内。这样不仅文件命名更整洁，也能减少需求蔓延。

不要只给功能名，要给业务意图

“Build approvals” 很模糊；“Build an approval flow for purchase requests over $5,000 to reduce manual finance review time by 40%” 这样的描述，才真正给了 prd-planner 可转化为目标、用户故事和验收标准的素材。

提前说明已知约束

尽早把技术栈、合规要求、时间线、组织边界和现有工作流告诉这个 skill。这些约束对 PRD 的影响，往往比很多用户想象得更大。缺少约束，常常会导致需求看起来很漂亮，却根本无法落地。

明确要求记录假设

一个很有效的 prd-planner guide 用法是直接告诉 agent：“请把假设单独列在 notes 文件中，并标记所有需要确认的内容。” 这样能避免隐藏的猜测被直接写进最终 PRD，伪装成已经确认的事实。

使用结合代码库的 edge-case 分析

如果你能访问源码，建议让 prd-planner 在最终定稿前先检查当前系统中 validation、pagination、loading、permissions 和 delete behavior 的既有模式。这里提供的参考文件尤其有价值，因为它把模糊的“考虑边界情况”变成了可执行的具体扫描动作。

先审 notes 文件，再看最终 PRD

很多用户只会读 *-prd.md，但真正的质量瓶颈往往出现在 *-prd-notes.md。在 notes 阶段修正一个错误假设，成本远低于后期重写一份已经写得很漂亮但方向跑偏的 PRD。

迭代时补决策，不要只改措辞

第一版输出之后，不要只是笼统地要求“更详细一点”。更好的做法是提出具体改进方向，例如：

• 更明确的成功指标
• 清晰的权限规则
• 失败与恢复场景
• 依赖关系梳理
• 发布顺序规划
• 需要 stakeholder 确认的开放问题

这种迭代提升的是决策质量，而不只是文档长度。

prd-planner 常见失败模式

典型的低质量输出通常表现为：

• persona 很泛，没有真实用户语境
• 需求忽略当前系统行为
• 缺少非目标
• 没有覆盖 edge cases
• 技术设计读起来像模板套话
• acceptance criteria 模糊到无法测试

这些问题通常首先是输入问题，不只是模型问题。

把 prd-planner 和 stakeholder 评审循环结合起来

当你把第一版当作工作草稿，而不是最终定稿时，prd-planner usage 的效果会更好。可以让 product、design 和 engineering 分别审阅不同产物：产品看 PRD，工程看技术设计，所有人一起看假设列表。它的文件化结构非常适合这种分工。

通过标准化模板提升团队采用率

如果你的团队认可这套工作流，可以围绕 prd-planner 定义自己的 scope 命名规范、docs/ 约定、PRD 章节结构和评审清单。这个 skill 已经提供了很扎实的骨架，而你的内部标准能让输出更稳定地达到可交付水平。