PRD Creation Skill

PRD 创建技能

Create Product Requirements Documents suitable for RFC review and for AI agents to implement from.

The PRD describes WHAT to build and WHY, not HOW or in WHAT ORDER.

创建适用于RFC评审、可供AI Agent落地实现的产品需求文档。

PRD描述要构建的内容和构建原因，而非如何构建或按什么顺序构建。

Workflow

工作流

1. Gather context

1. 收集上下文

User describes the problem and any initial ideas. Explore the codebase to understand existing patterns, constraints, and dependencies.

用户描述问题和所有初始想法。遍历代码库以了解现有模式、约束和依赖项。

2. Interview the design tree

2. 设计树访谈

Walk through the design decision tree branch by branch. For each decision point:

Explore the codebase first — only ask the user what the code can't answer
One topic per turn — don't dump multiple questions at once
Resolve dependencies between decisions before moving on

Cover these domains as the tree branches into them:

Problem & motivation (what, who, why now, cost of inaction)
Users & stakeholders
End state & success criteria
Scope & boundaries (what's in, what's explicitly out, what must NOT be affected)
Constraints (performance, security, compatibility, accessibility)
Risks & dependencies
Alternatives considered

If ambiguous or overloaded domain terms surface, flag them and propose canonical terms.

Keep going until shared understanding is reached. No artificial cap on questions.

逐个分支遍历设计决策树，针对每个决策点：

优先调研代码库 —— 仅询问代码无法解答的问题
每轮仅沟通一个主题 —— 不要一次性抛出多个问题
先解决决策之间的依赖关系，再推进后续流程

当决策树分支延伸到以下领域时需全部覆盖：

问题与动机（是什么、面向谁、为什么现在做、不行动的代价）
用户与利益相关方
最终状态与成功标准
范围与边界（包含什么、明确不包含什么、绝对不能影响的内容）
约束（性能、安全、兼容性、可访问性）
风险与依赖项
已考虑的替代方案

如果出现模糊或过载的领域术语，需标记并提出规范术语建议。

持续沟通直到达成共识，不人为限制提问次数。

3. Identify modules

3. 识别模块

Sketch the major modules to build or modify. Look for opportunities to extract deep modules — small interface hiding lots of implementation, testable in isolation.

Check with the user:

Do these modules match their mental model?
Which modules warrant dedicated tests?

梳理需要构建或修改的核心模块，寻找提取深模块的机会——即接口简洁、隐藏大量实现逻辑、可独立测试的模块。

向用户确认：

这些模块是否符合用户的认知模型？
哪些模块需要专门的测试覆盖？

4. Write the PRD

4. 编写PRD

Generate markdown PRD to

prd-<feature-name>.md

in project root. Use the template below, including only sections relevant to the feature.

在项目根目录生成markdown格式的PRD文件，命名为

prd-<feature-name>.md

。使用下方模板，仅保留与当前功能相关的章节。

Template

模板

markdown

undefined

markdown

undefined

PRD: <Feature Name>

Date: <YYYY-MM-DD>

Problem Statement

What problem are we solving?

Clear description of the problem. Include user impact and business impact.

Why now?

What triggered this work? Cost of inaction?

Who is affected?

Primary users: Description
Secondary users: Description

Primary users: Description
Secondary users: Description

Proposed Solution

Overview

One paragraph describing what this feature does when complete.

User Experience (if applicable)

How will users interact with this feature? Include user flows for primary scenarios.

Design Considerations (if applicable)

Visual/interaction requirements
Accessibility requirements (WCAG level)
Platform-specific considerations

Visual/interaction requirements
Accessibility requirements (WCAG level)
Platform-specific considerations

End State

When this PRD is complete, the following will be true:

Capability 1 exists and works
Capability 2 exists and works
All acceptance criteria pass
Tests cover the new functionality
Observability/monitoring is in place

When this PRD is complete, the following will be true:

Capability 1 exists and works
Capability 2 exists and works
All acceptance criteria pass
Tests cover the new functionality
Observability/monitoring is in place

Acceptance Criteria

Feature: <Name>

Criterion 1
Criterion 2
Criterion 3

Criterion 1
Criterion 2
Criterion 3

Durable Architectural Decisions

Decisions unlikely to change regardless of implementation order:

Routes/URL patterns: ...
Schema shape: ...
Key data models: ...
Auth/authorisation approach: ...
Third-party service boundaries: ...

Include only what applies. These anchor the PRD for anyone implementing from it.

Decisions unlikely to change regardless of implementation order:

Routes/URL patterns: ...
Schema shape: ...
Key data models: ...
Auth/authorisation approach: ...
Third-party service boundaries: ...

Include only what applies. These anchor the PRD for anyone implementing from it.

Modules

Major modules to build or modify, with interface sketches where helpful.

Do NOT include specific file paths or code snippets — they become outdated quickly. Describe modules by name and responsibility.

Module name: What it owns, what it hides, how callers interact with it
Module name: ...

Major modules to build or modify, with interface sketches where helpful.

Do NOT include specific file paths or code snippets — they become outdated quickly. Describe modules by name and responsibility.

Module name: What it owns, what it hides, how callers interact with it
Module name: ...

Testing Strategy

Which modules are tested and at which tier (unit / integration / component / e2e)
What makes a good test for this feature (test behaviour through public interfaces, not implementation)
Prior art — similar test patterns already in the codebase

Which modules are tested and at which tier (unit / integration / component / e2e)
What makes a good test for this feature (test behaviour through public interfaces, not implementation)
Prior art — similar test patterns already in the codebase

Technical Context

Existing Patterns

Patterns in the codebase to follow (describe by name and purpose, not file paths):

Pattern name — why relevant, how it applies

Patterns in the codebase to follow (describe by name and purpose, not file paths):

Pattern name — why relevant, how it applies

System Dependencies

External services/APIs
Package requirements
Infrastructure requirements

External services/APIs
Package requirements
Infrastructure requirements

Data Model Changes (if applicable)

New entities/tables
Schema migrations required
Data backfill considerations

New entities/tables
Schema migrations required
Data backfill considerations

Boundary Tiers

Always (conventions to follow)

Convention 1
Convention 2

Convention 1
Convention 2

Ask First (decisions needing human input)

Decision area 1
Decision area 2

Decision area 1
Decision area 2

Never (must not be touched)

Protected area 1 — why
Protected area 2 — why

Protected area 1 — why
Protected area 2 — why

Risks & Mitigations

Risk	Likelihood	Impact	Mitigation
Risk 1	High/Med/Low	High/Med/Low	How to mitigate

Risk	Likelihood	Impact	Mitigation
Risk 1	High/Med/Low	High/Med/Low	How to mitigate

Alternatives Considered

Alternative 1: <Name>

Description: Brief description
Pros: What's good about it
Cons: Why we didn't choose it
Decision: Why rejected

Description: Brief description
Pros: What's good about it
Cons: Why we didn't choose it
Decision: Why rejected

Non-Goals (v1)

Explicitly out of scope:

Thing we're not building — why deferred
Future enhancement — why deferred

Explicitly out of scope:

Thing we're not building — why deferred
Future enhancement — why deferred

Interface Specifications (if applicable)

CLI

command-name [args] [options]

command-name [args] [options]

API

POST /api/endpoint
Request: { field: type }
Response: { field: type }
Errors: 4xx/5xx scenarios

POST /api/endpoint
Request: { field: type }
Response: { field: type }
Errors: 4xx/5xx scenarios

Success Metrics (if applicable)

How we'll know this worked:

Metric 1: current → target (how measured)
Metric 2: current → target (how measured)

How we'll know this worked:

Metric 1: current → target (how measured)
Metric 2: current → target (how measured)

Open Questions

Question 1
Question 2

undefined

Question 1
Question 2

undefined

Key Principles

关键原则

Problem Before Solution

先定义问题，再给出解决方案

Lead with the problem. Quantify the cost of inaction. Make the case for why this matters.

以问题为核心，量化不行动的代价，说明该需求的重要性。

Define End State, Not Process

定义最终状态，而非执行流程

Describe WHAT exists when done. Don't prescribe implementation order, priorities, or phases.

描述交付完成后存在的功能，不要规定实现顺序、优先级或阶段。

No File Paths

不要写入文件路径

File paths and code snippets go stale. Describe patterns by name and purpose. Reference modules by responsibility, not location.

文件路径和代码片段会很快过时，通过名称和用途描述模式，通过职责而非存放位置指代模块。

Boundaries Prevent Drift

边界防止需求偏移

Explicit boundary tiers (Always/Ask First/Never) and non-goals prevent agents from touching stable code or building unrequested features.

明确的边界层级（必须遵守/需先确认/绝对禁止）和非目标项可以避免Agent改动稳定代码或构建未被要求的功能。

Testing Strategy Is Architecture

测试策略即架构

Which modules are tested at which tier reveals the architecture. Deep modules get boundary tests; pure logic gets unit tests; composition gets integration tests.

不同模块对应的测试层级能够体现架构设计：深模块需要边界测试；纯逻辑代码需要单元测试；组合逻辑需要集成测试。

Bad vs Good Examples

好坏示例对比

Bad (Prescriptive / Phases)

坏示例（过于强调执行/分阶段）

markdown

undefined

markdown

undefined

Phase 1: Database

Create users table
Add indexes

Create users table
Add indexes

Phase 2: API

Build registration endpoint

undefined

Build registration endpoint

undefined

Bad (Missing RFC Context)

坏示例（缺失RFC所需上下文）

markdown

undefined

markdown

undefined

Overview

We need user authentication.

Acceptance Criteria

Users can register
Users can log in

Missing: Why? What problem? Risks? Alternatives? Testing strategy?

Users can register
Users can log in

缺失内容：为什么做？解决什么问题？风险？替代方案？测试策略？

Good (RFC-Ready)

好示例（符合RFC要求）

markdown

undefined

markdown

undefined

Problem Statement

Users can't persist data across sessions. 47% drop off when asked to re-enter information. ~$50k/month in lost conversions.

Durable Architectural Decisions

Routes: POST /api/auth/register, POST /api/auth/login
Schema: users table with email (unique), password_hash, created_at
Auth: JWT with 24h expiry, refresh token with 7d expiry

Routes: POST /api/auth/register, POST /api/auth/login
Schema: users table with email (unique), password_hash, created_at
Auth: JWT with 24h expiry, refresh token with 7d expiry

Modules

AuthService: Owns registration, login, token lifecycle. Callers pass credentials, receive tokens. Hides hashing, token signing, refresh logic.

AuthService: Owns registration, login, token lifecycle. Callers pass credentials, receive tokens. Hides hashing, token signing, refresh logic.

Testing Strategy

AuthService: integration tests against real DB (prior art: tests/int/)
Token validation: unit tests for expiry, malformed tokens, refresh flows

AuthService: integration tests against real DB (prior art: tests/int/)
Token validation: unit tests for expiry, malformed tokens, refresh flows

Boundary Tiers

Never

Payment module — unrelated, must not be affected
User profile schema — separate concern, future PRD

undefined

Payment module — unrelated, must not be affected
User profile schema — separate concern, future PRD

undefined

After PRD Creation

PRD创建完成后

Before sharing, verify:

Problem statement is clear and compelling
Scope boundaries are explicit (boundary tiers + non-goals)
Testing strategy covers the identified modules
No file paths or code snippets that will go stale
Durable architectural decisions are separated from implementation detail

Tell the user: PRD saved to

prd-<name>.md

分享前需确认：

问题描述清晰且有说服力
范围边界明确（边界层级+非目标项）
测试策略覆盖了所有识别的模块
没有包含会很快过时的文件路径或代码片段
长期有效的架构决策已和实现细节分离

告知用户：PRD已保存至

prd-<name>.md

prd

Original

Translation

PRD Creation Skill

PRD 创建技能

Workflow

工作流

1. Gather context

1. 收集上下文

2. Interview the design tree

2. 设计树访谈

3. Identify modules

3. 识别模块

4. Write the PRD

4. 编写PRD

Template

模板

PRD: <Feature Name>

PRD: <Feature Name>

Problem Statement

Problem Statement

What problem are we solving?

What problem are we solving?

Why now?

Why now?

Who is affected?

Who is affected?

Proposed Solution

Proposed Solution

Overview

Overview

User Experience (if applicable)

User Experience (if applicable)

Design Considerations (if applicable)

Design Considerations (if applicable)

End State

End State

Acceptance Criteria

Acceptance Criteria

Feature: <Name>

Feature: <Name>

Durable Architectural Decisions

Durable Architectural Decisions

Modules

Modules

Testing Strategy

Testing Strategy

Technical Context

Technical Context

Existing Patterns

Existing Patterns

System Dependencies

System Dependencies

Data Model Changes (if applicable)

Data Model Changes (if applicable)

Boundary Tiers

Boundary Tiers

Always (conventions to follow)

Always (conventions to follow)

Ask First (decisions needing human input)

Ask First (decisions needing human input)

Never (must not be touched)

Never (must not be touched)

Risks & Mitigations

Risks & Mitigations

Alternatives Considered

Alternatives Considered

Alternative 1: <Name>

Alternative 1: <Name>

Non-Goals (v1)

Non-Goals (v1)

Interface Specifications (if applicable)

Interface Specifications (if applicable)

CLI

CLI

API

API

Success Metrics (if applicable)

Success Metrics (if applicable)

Open Questions