prd-planner

PRD 规划器

一项 PRD 创建技能，通过基于文件的持久化规划保持思路连贯，避免“左脑与右脑”之间切换上下文的问题。

此技能的激活条件

出现以下情况时，此技能会激活：

• 明确说出“PRD”、“prd”、“创建 PRD”或“产品需求文档”
• 说出“产品需求文档”或“产品需求”
• 提到“为……编写 PRD”
• 说出“PRD 规划”或“PRD 设计”

如果用户说“设计解决方案”或“架构设计”，但没有提到 PRD，请改用 architecting-solutions。

核心理念

“PRD 创建应当可追溯、连贯且持久，而不是散落在上下文切换之间。”

此技能结合了：

• PRD 方法论（来自 architecting-solutions）
• 基于文件的持久化（来自 planning-with-files）

从而创建一个统一、连贯且不会丢失上下文的 PRD 创建工作流。

PRD 创建的 4 文件模式

每个 PRD 项目都要创建四个文件：

选择一个 SCOPE（简短、唯一、kebab-case 的标识），并将其用作所有文件的前缀。

docs/{scope}-prd-notes.md     → Store research, requirements, findings, options
docs/{scope}-prd-task-plan.md → Track PRD creation phases and progress
docs/{scope}-prd.md           → Product requirements (what & why)
docs/{scope}-tech.md          → Technical design (how)

文件用途

文件	用途	受众	更新时机
{scope}-prd-notes.md	原始调研、需求、架构选项（A/B/C）	自己 + 评审者	收集到新信息时
{scope}-prd-task-plan.md	跟踪进度、阶段、复选框、时间戳	PM + 开发负责人	每个阶段完成时
{scope}-prd.md	产品需求（做什么以及为什么）、用户流程	PM + 利益相关方 + 开发人员	需求明确后
{scope}-tech.md	技术设计（API、数据流、实现）	开发人员 + 架构师	架构确定后

工作流

┌─────────────────────────────────────────────────────────────────┐
│                     PRD Creation Workflow                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Initialize → Create 4 files with template                   │
│  2. Requirements → Gather to {scope}-prd-notes.md               │
│  2.5 Edge Cases → Scan codebase, infer patterns, ask smartly    │
│  3. Analysis → Research best practices, save to notes           │
│  4. Design → Propose architecture options (A/B/C), save to notes │
│  5. PRD → Write product requirements to {scope}-prd.md          │
│  6. Tech → Write technical design to {scope}-tech.md            │
│  7. Validate → Review with user, finalize                       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
                    ↓
           All thinking persisted to files
                    ↓
              No context switching

步骤 1：初始化

使用模板创建四个文件：

{scope}-prd-task-plan.md

# PRD Task Plan: {Feature Name}

## Goal
Create a PRD and technical design for {feature description}.

## Owner
{User name/role}

## Phases
- [x] Phase 1: Initialize files ✓
- [ ] Phase 2: Gather requirements (CURRENT)
- [ ] Phase 3: Research & analysis
- [ ] Phase 4: Design solution
- [ ] Phase 5: Write PRD
- [ ] Phase 6: Write technical design
- [ ] Phase 7: Validate & finalize

## Status
**Currently in Phase 2** - Gathering requirements from user

## Progress Log
- {timestamp} - Phase 1 complete: Files initialized

{scope}-prd-notes.md

# PRD Notes: {Feature Name}

## Raw Requirements
(Add user requirements as they emerge)

## Constraints
(Add technical, business, time constraints)

## Inferred Patterns (from codebase)

| Edge Case | Source | Pattern Applied |
|-----------|--------|-----------------|
| (Filled after Step 2.5 codebase scan) | | |

## Edge Cases

### Auto-handled (following codebase patterns)
- (Filled after Step 2.5 analysis)

### Confirmed by User
- (Filled after user confirms edge case decisions)

### Open Questions
- (Track questions to ask user)

## Research Findings
(Add research on best practices, similar solutions)

## Architecture Options

- Option A: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option B: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option C: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

**Selected**: Option {X}

{scope}-prd.md

# PRD: {Feature Name}

> Status: DRAFT
> Last updated: {timestamp}

## Table of Contents
- [Problem Statement](#problem-statement)
- [Goals and Non-Goals](#goals-and-non-goals)
- [Success Criteria](#success-criteria)
- [Scope](#scope)
- [Requirements](#requirements)
- [User Flows](#user-flows)
- [Implementation Plan](#implementation-plan)

---

## Problem Statement
_To be filled after requirements gathering_

## Goals and Non-Goals
### Goals
- {Specific achievable outcomes}

### Non-Goals
- {Explicit exclusions}

## Success Criteria
_To be filled with measurable criteria_

## Scope
### In Scope
- {Specific items included}

### Out of Scope
- {Specific items excluded}

... (rest of PRD sections)

{scope}-tech.md

# Technical Design: {Feature Name}

> Status: DRAFT
> Last updated: {timestamp}

## Overview
{High-level technical approach}

## Key Components
{List major components and their responsibilities}

## API Design
{API signatures, request/response formats}

## Data Flow
{How data flows through the system}

## Implementation Details
{Specific implementation notes}

## Migration Plan
{If applicable, how to migrate from existing system}

步骤 2：收集需求

提出澄清问题，并将回答保存到 {scope}-prd-notes.md：

要提出的核心问题

1. 问题：我们要解决什么问题？
2. 用户：谁会使用它？
3. 成功标准：如何判断它是否成功？
4. 限制条件：是否有技术、时间或预算限制？

将每个回答保存到 {scope}-prd-notes.md 中的相应章节。

收集信息后，务必更新 {scope}-prd-task-plan.md：

- [x] Phase 2: Gather requirements ✓
- [ ] Phase 2.5: Edge case analysis (CURRENT)
- [ ] Phase 3: Research & analysis

步骤 2.5：结合上下文分析边缘情况

在询问用户边缘情况之前，先扫描代码库，推断现有模式。这样可以减少重复提问，并确保与项目保持一致。

详细参考：完整的扫描命令和输出格式请参见 references/edge-case-analysis.md。

快速流程

1. 扫描代码库，查找现有模式（删除策略、错误处理、空状态、分页）
2. 识别需求类型（CRUD、状态工作流、异步、数据显示、表单、文件）
3. 生成合理假设——代码中已有的模式无需用户确认
4. 仅在必要时提问——没有先例、存在多种模式，或需要业务决策时

何时询问用户

条件	操作
代码库中存在相应模式	自动应用，无需提问
未找到先例	向用户提供选项并询问
存在多种互相冲突的模式	请用户选择
需要业务规则	询问用户

输出到备注文件

更新 {scope}-prd-notes.md，写入：

## Inferred Patterns (from codebase)
| Edge Case | Source | Pattern Applied |
|-----------|--------|-----------------|
| Delete | `src/models/User.ts:45` | Soft delete |

## Edge Cases
### Auto-handled (following codebase patterns)
- Empty list → Use existing EmptyState component

### Confirmed by User
- Concurrent edit: Last write wins (confirmed {date})

更新任务计划：

- [x] Phase 2.5: Edge case analysis ✓
- [ ] Phase 3: Research & analysis (CURRENT)

步骤 3：调研与分析

调研最佳实践，并保存到 {scope}-prd-notes.md：

# Search for similar implementations
grep -r "keyword" packages/ --include="*.ts"

# Search web for best practices
web search "best practices for {feature}"

将调研结果保存到 {scope}-prd-notes.md → Research Findings 章节。

步骤 4：设计解决方案

提出架构方案并说明权衡，将其保存到 {scope}-prd-notes.md：

## Architecture Options

- Option A: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option B: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option C: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

**Selected**: Option {X} - because {reason}

步骤 5：编写 PRD

阅读 {scope}-prd-notes.md，并综合整理成完善的 PRD：

1. Read {scope}-prd-notes.md to understand:
   - Requirements gathered
   - Research findings
   - Architecture decision (which option was selected)

2. Write {scope}-prd.md with:
   - Clear problem statement
   - Goals and Non-Goals (explicit exclusions)
   - Measurable success criteria (specific numbers/timings)
   - Scope (In Scope / Out of Scope)
   - Functional requirements
   - Non-functional requirements
   - User flows
   - Implementation plan (high level)

3. Reference tech doc: "See {scope}-tech.md for technical design"

步骤 6：编写技术设计

1. Read {scope}-prd-notes.md for selected architecture option

2. Write {scope}-tech.md with:
   - Overview (technical approach summary)
   - Key Components (what pieces, responsibilities)
   - API Design (signatures, contracts)
   - Data Flow (how data moves through system)
   - Implementation Details (specific notes)
   - Migration Plan (if applicable)

第 7 步：验证与定稿

与用户一起审核：

1. 呈现 PRD 摘要
2. 征求反馈
3. 根据反馈进行修改
4. 标记第 7 阶段已完成

重要规则

规则	错误做法	正确做法
使用文件	保存在内存中	保存到 {scope}-prd-notes.md
更新计划	不更新就直接继续	使用复选框更新 task-plan.md
阅读后再决定	凭记忆做决定	先阅读笔记
分开文档	混合 PRD 与 Tech	PRD 写“是什么”，Tech 写“怎么做”
提供选项	直接给出方案	记录 2-3 个选项及其优缺点

阶段转换

每个阶段结束后，使用复选框 ✓ 和时间戳更新 {scope}-prd-task-plan.md。

完成 PRD

将所有阶段标记为已完成，将状态设为“✅ COMPLETE”，并记录最终交付物。

文件清理（可选）

PRD 完成后：

• 保留 {scope}-prd-notes.md 供参考（展示决策过程）
• 归档或删除 {scope}-prd-task-plan.md
• 最终输出为 {scope}-prd.md 和 {scope}-tech.md

快速入门模板

# PRD Task Plan: {Feature}

## Goal
Create PRD and technical design for {description}

## Phases
- [ ] Initialize 4 files
- [ ] Gather requirements
- [ ] Research & analysis
- [ ] Design solution (A/B/C options)
- [ ] Write PRD
- [ ] Write technical design
- [ ] Validate & finalize

## Status
Phase 1: Initializing files

为什么这样有效

问题	解决方案
上下文切换	将所有思考记录在文件中，随时阅读
需求丢失	立即保存到 {scope}-prd-notes.md
PRD 不一致	使用相同的流程和结构
“左脑与右脑”	采用统一连贯的工作流
重复解释上下文	文件包含完整上下文
关注点混杂	将 PRD（产品）与 Tech（实现）分开
决策隐藏	记录架构选项 A/B/C

参考资料

• planning-with-files - 基于文件的规划方法
• architecting-solutions - 非 PRD 的解决方案与架构设计
• 边缘情况扫描：references/edge-case-analysis.md

---

自动触发（后续元数据）

此技能完成后，记录或运行受支持的后续操作：

1. self-improving-agent（后台）- 提出可复用的模式
2. session-logger（自动）- 在支持时保存会话上下文