用途
PRD Planner 是一个创建产品需求文档（PRD）的技能。它使用基于持久化文件的规划方式，保持思路连贯，避免“左脑与右脑”式的上下文切换问题。该技能把 PRD 方法论（来自 architecting-solutions）与文件持久化（来自 planning-with-files）结合起来，形成单一的 PRD 创建工作流。
触发条件
当用户出现以下表述时激活：明确说“PRD”“prd”“create a PRD”或“产品需求文档”；说“product requirements document”或“产品需求”；提到“write a PRD for...”；说“PRD planning”或“PRD 设计”。如果用户只说“design solution”或“architecture design”而未提及 PRD，则应改用 architecting-solutions。
四文件模式
每个 PRD 项目创建四个文件，先选定一个简短、唯一、kebab-case 的 SCOPE 作为所有文件的前缀：
docs/{scope}-prd-notes.md：存放调研、需求、发现和选项，面向自己与评审者，在收集到新信息时更新。docs/{scope}-prd-task-plan.md：跟踪 PRD 创建阶段与进度，面向 PM 与开发负责人，在每个阶段完成时更新。docs/{scope}-prd.md：产品需求（做什么与为什么）与用户流程，面向 PM、利益相关者与开发者，在需求明确后更新。docs/{scope}-tech.md：技术设计（API、数据流、实现），面向开发者与架构师，在架构确定后更新。
工作流程
- 初始化：用模板创建四个文件。
- 收集需求：将信息收集到
{scope}-prd-notes.md。 - 边界情况分析：扫描代码库、推断模式、有针对性地提问（详见 references/edge-case-analysis.md）。
- 调研分析：研究最佳实践，保存到 notes。
- 方案设计：提出架构选项（A/B/C），保存到 notes。
- 撰写 PRD：将产品需求写入
{scope}-prd.md。 - 撰写技术设计：将技术设计写入
{scope}-tech.md。 - 验证定稿：与用户评审并最终确认。所有思考都持久化到文件中，避免上下文切换。
各阶段说明
步骤 1：初始化
创建带模板的四个文件。task-plan 文件中包含目标、负责人、阶段复选框、状态和进度日志；notes 文件包含原始需求、约束、推断模式、边界情况、研究结果和架构选项；prd 文件包含目录、问题陈述、目标与非目标、成功标准、范围、需求、用户流程和实施计划；tech 文件包含概览、关键组件、API 设计、数据流、实现细节和迁移计划。
步骤 2：收集需求
提出澄清问题并把回答保存到 notes 文件，核心问题包括：问题（我们要解决什么问题）、用户（谁会使用）、成功（如何判断成功）、约束（技术/时间/预算约束）。每次收集后更新 task-plan 文件。
步骤 2.5：上下文感知的边界情况分析
在向用户询问边界情况之前，先扫描代码库以推断现有模式。扫描内容包括删除策略、错误处理、空状态、分页等；识别需求类型（CRUD、状态工作流、异步、数据展示、表单、文件）；生成智能假设——代码中已有的模式无需用户确认；仅在无先例、存在多种冲突模式或需要业务决策时才提问。输出写回 notes 文件（推断模式表和边界情况小节），并更新 task-plan。
步骤 3：调研分析
通过代码检索与网络检索研究最佳实践，将结果保存到 {scope}-prd-notes.md 的 Research Findings 小节。
步骤 4：方案设计
提出带权衡的架构选项，保存到 notes 文件，例如 Option A/B/C 及各自的 Pros/Cons，并标注所选方案与原因。
步骤 5：撰写 PRD
阅读 {scope}-prd-notes.md，综合成完整 PRD，写入 {scope}-prd.md，包含清晰的问题陈述、目标与非目标（显式排除项）、可衡量的成功标准、范围（纳入/排除）、功能与非功能需求、用户流程和高层实施计划，并引用技术文档。
步骤 6：撰写技术设计
阅读 notes 中选定的架构选项，撰写 {scope}-tech.md，包含概览、关键组件、API 设计、数据流、实现细节和迁移计划（如适用）。
步骤 7：验证定稿
与用户评审：展示 PRD 摘要、征求反馈、纳入修改、标记阶段完成。
重要规则
- 使用文件：不要只留在记忆中，保存到
{scope}-prd-notes.md。 - 更新计划：不要不更新就继续，用复选框更新 task-plan.md。
- 先读再决定：不要凭记忆决定，先阅读 notes。
- 分离文档：不要把 PRD 与技术混在一起，PRD 管“做什么”，Tech 管“如何做”。
- 包含选项：不要直接跳到方案，记录 2-3 个带优劣的选项。
- 阶段转换：每个阶段后用复选框 ✓ 和时间戳更新 task-plan。
完成与清理
完成 PRD 后，标记所有阶段完成，状态设为 COMPLETE，记录最终交付物。可选清理：保留 notes 供参考（展示决策过程），归档或删除 task-plan，最终输出为 {scope}-prd.md 与 {scope}-tech.md。
为什么有效
文件化思考解决了上下文切换、需求丢失、PRD 不一致、左右脑割裂、重复解释上下文、关注点混杂和决策隐藏等问题。
参考
- planning-with-files：基于文件的规划方法论
- architecting-solutions：非 PRD 的方案与架构设计
- 边界情况扫描：references/edge-case-analysis.md
后续元数据
该技能完成后，记录或运行受支持的后续动作：self-improving-agent（后台，提出可复用模式）、session-logger（自动，在支持时保存会话上下文）。