build-prd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

build-prd

Create a Product Requirements Document through collaborative discussion with the user, ending with a complete GitHub issue ready for implementation.

通过与用户协作讨论创建产品需求文档（PRD），最终生成一份可直接用于开发的完整GitHub Issue。

When to Use

适用场景

User asks to "create a PRD" or "write requirements"
Working from a GitHub issue labeled
```
feature-request
```
or
```
enhancement
```
User needs to document requirements before implementation
Transforming a vague idea into a structured, implementable spec

用户要求「创建PRD」或「撰写需求」
处理带有
```
feature-request
```
或
```
enhancement
```
标签的GitHub Issue
用户需要在开发前记录需求
将模糊的想法转化为结构化、可落地的规范

When NOT to Use

不适用场景

Issue already has a complete PRD (check for
```
[PRD]
```
prefix in title)
Pure bug reports — those need reproduction steps, not requirements
Implementation is already underway — write a spec retroactively instead

Issue已有完整PRD（检查标题是否带有
```
[PRD]
```
前缀）
纯Bug报告——这类问题需要复现步骤，而非需求文档
开发已在进行中——此时应追溯撰写规范文档

Prerequisites

前置条件

bash

gh auth status        # GitHub CLI authenticated
gh repo view          # Inside a valid repo (or org/repo provided)

bash

gh auth status        # 已完成GitHub CLI认证
gh repo view          # 处于有效仓库内（或已提供组织/仓库信息）

Workflow

工作流程

Step 1: Understand the request

步骤1：理解需求请求

If triggered from a GitHub issue:

bash

gh issue view ISSUE_NUMBER --repo ORG/REPO

Read project context:

bash

cat project-instructions.md  # or equivalent project instructions file
cat README.md

Articulate the core request in 1-2 sentences. If you can't, ask the user to clarify before continuing.

若从GitHub Issue触发：

bash

gh issue view ISSUE_NUMBER --repo ORG/REPO

读取项目上下文：

bash

cat project-instructions.md  # 或等效的项目说明文件
cat README.md

用1-2句话明确核心需求。若无法明确，请先让用户澄清后再继续。

Step 2: Identify gaps

步骤2：识别信息缺口

Check the request against required PRD sections:

Section	Required?	Source
Problem Statement	Yes	Why does this matter?
User Stories	Yes	Who needs it and why?
Success Metrics	Yes	How do we measure success?
Scope (in + out)	Yes	What's included and excluded?
Technical Constraints	Yes	Limitations, integrations, patterns?
Mockups/Examples	No	Visual references if available
Dependencies	No	Related features or systems
Timeline	No	Priority or deadline

Build a list of questions for anything missing.

对照PRD必填检查需求请求：

章节	是否必填	信息来源
问题陈述	是	该需求解决什么问题？为何重要？
用户故事	是	谁需要该功能？需求原因是什么？
成功指标	是	如何衡量成功？
范围（包含/排除）	是	哪些内容包含在内？哪些排除在外？
技术约束	是	存在哪些限制、集成需求或模式要求？
原型/示例	否	如有可用的视觉参考
依赖项	否	相关功能或系统
时间线	否	优先级或截止日期

列出所有缺失信息对应的问题清单。

Step 3: Ask all questions in one batch

步骤3：一次性提出所有问题

text

To create a complete PRD, I need some additional information:

Q1: [specific question]
Q2: [specific question]
Q3: [specific question]
Q4 (Optional): [nice-to-have question]

Warning: Ask ALL questions at once. Do not drip-feed one question at a time — that wastes the user's time and breaks flow.

If working from a GitHub issue, add the

question

label:

bash

gh issue edit ISSUE_NUMBER --repo ORG/REPO --add-label "question"

Wait for user responses before proceeding.

text

为创建完整的PRD，我需要以下补充信息：

Q1: [具体问题]
Q2: [具体问题]
Q3: [具体问题]
Q4（可选）: [非必需但有帮助的问题]

注意： 一次性提出所有问题。不要逐个提问——这会浪费用户时间并打断流程。

若处理的是GitHub Issue，添加

question

标签：

bash

gh issue edit ISSUE_NUMBER --repo ORG/REPO --add-label "question"

等待用户回复后再继续。

Step 4: Draft the PRD

步骤4：起草PRD

Use this template — replace ALL placeholders with actual content:

markdown

undefined

使用以下模板——替换所有占位符为实际内容：

markdown

undefined

[Feature Name]

[功能名称]

Problem Statement

问题陈述

[2-3 sentences: what user problem this solves and why it matters now]

[2-3句话：该功能解决的用户问题，以及为何现在需要解决]

User Stories

用户故事

As a [user type], I want [goal] so that [benefit]
As a [user type], I want [goal] so that [benefit]

作为[用户角色]，我希望[达成目标]，以便[获得收益]
作为[用户角色]，我希望[达成目标]，以便[获得收益]

Success Metrics

成功指标

[Metric]: [specific target or measurement approach]
[Metric]: [specific target or measurement approach]

[指标]：[具体目标或衡量方式]
[指标]：[具体目标或衡量方式]

Scope

范围

In Scope

包含范围

[Concrete feature or deliverable]
[Concrete feature or deliverable]

[具体功能或交付物]
[具体功能或交付物]

Out of Scope

排除范围

[Explicitly excluded item — prevents scope creep]
[Explicitly excluded item]

[明确排除的内容——防止范围蔓延]
[明确排除的内容]

Technical Requirements

技术要求

[Requirement referencing existing codebase patterns]
[Constraint or integration point]

[参考现有代码库模式的要求]
[约束条件或集成点]

Dependencies

依赖项

[Related system or feature, if any]

[相关系统或功能（如有）]

Open Questions

待解决问题

[Anything unresolved — do not guess]

[所有未确定的内容——请勿猜测]

Implementation Notes

开发说明

[Architectural decisions, patterns to follow, files to reference]

undefined

[架构决策、需遵循的模式、参考文件]

undefined

Step 5: Review with user

步骤5：与用户评审

Present the full PRD draft. Highlight assumptions:

text

I've drafted a PRD based on our discussion. Please review:

[FULL PRD]

Assumptions I made:
- [Assumption 1]
- [Assumption 2]

Does this capture everything? Anything to change?

Warning: NEVER proceed to Step 6 without explicit user approval. "Looks good" or "yes" counts. Silence does not.

提交完整的PRD草稿，并突出说明假设内容：

text

我已根据讨论内容起草了PRD，请评审：

[完整PRD内容]

我的假设：
- [假设1]
- [假设2]

这份文档是否涵盖了所有内容？是否需要修改？

注意： 在未获得用户明确批准前，绝不能进入步骤6。「看起来不错」或「可以」视为批准，沉默不算。

Step 6: Update the GitHub issue

步骤6：更新GitHub Issue

Only after user approval:

bash

gh issue edit ISSUE_NUMBER --repo ORG/REPO \
  --body "$(cat /tmp/prd-draft.md)" \
  --title "[PRD] Feature Name" \
  --add-label "ready-to-work"

gh issue edit ISSUE_NUMBER --repo ORG/REPO --remove-label "question" 2>/dev/null || true

Label	Action
`ready-to-work`	Add — signals PRD is complete
`question`	Remove if present
`feature-request` , `enhancement`	Keep — preserve original labels

仅在获得用户批准后执行：

bash

gh issue edit ISSUE_NUMBER --repo ORG/REPO \
  --body "$(cat /tmp/prd-draft.md)" \
  --title "[PRD] Feature Name" \
  --add-label "ready-to-work"

gh issue edit ISSUE_NUMBER --repo ORG/REPO --remove-label "question" 2>/dev/null || true

标签	操作
`ready-to-work`	添加——表示PRD已完成
`question`	若存在则移除
`feature-request` , `enhancement`	保留——保留原始标签

Step 7: Confirm

步骤7：确认通知

bash

gh issue comment ISSUE_NUMBER --repo ORG/REPO \
  --body "PRD created. Issue updated with complete requirements. Ready for implementation planning."

bash

gh issue comment ISSUE_NUMBER --repo ORG/REPO \
  --body "PRD已创建。Issue已更新为完整需求，可进入开发规划阶段。"

Error Handling

错误处理

User unsure about scope — propose MVP: include only what's essential for core value, move everything else to "Out of Scope (future)".

Scope too broad — suggest splitting into multiple PRDs, each focused on one capability. Start with the foundational one.

User provides implementation details instead of requirements — redirect: "Before implementation, let's clarify: what problem does this solve? What should users be able to do that they can't now?"

Missing success metrics — suggest based on feature type:

Feature Type	Suggested Metrics
User-facing	Adoption rate, usage frequency, satisfaction
Performance	Latency reduction, error rate decrease
Developer tool	Time saved, code quality improvement
Infrastructure	Uptime, cost reduction, incident frequency

用户对范围不确定——提议最小可行产品（MVP）：仅包含核心价值所需的内容，其余内容移至「排除范围（未来版本）」。

范围过于宽泛——建议拆分为多个PRD，每个PRD聚焦一项能力。从基础功能开始。

用户提供开发细节而非需求——引导用户：「在开发前，我们先明确：这解决了什么问题？用户现在无法完成的操作是什么？」

缺失成功指标——根据功能类型提供建议：

功能类型	建议指标
用户端功能	采用率、使用频率、满意度
性能优化	延迟降低率、错误率下降幅度
开发者工具	节省时间、代码质量提升
基础设施	可用性、成本降低、事件发生频率

Critical Rules

核心规则

Never update a GitHub issue without explicit user approval — the PRD is a contract
Never make up technical details — mark unknowns as Open Questions
Batch all questions — one message, numbered Q1-Qn
No placeholder text in final PRD — every bracket must be replaced
Preserve original labels — only add
```
ready-to-work
```
, never remove
```
feature-request
```
or
```
enhancement
```

未获得用户明确批准，绝不能更新GitHub Issue——PRD是一份契约
绝不能编造技术细节——将未知内容标记为待解决问题
批量提出所有问题——一次发送，编号Q1-Qn
最终PRD中不能有占位符文本——所有括号内容必须替换
保留原始标签——仅添加
```
ready-to-work
```
，绝不能移除
```
feature-request
```
或
```
enhancement
```