Back to Details

write-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
This skill creates a Product Requirements Document (PRD). The PRD covers functional requirements, user flows, UX/UI, personas, and business constraints. Technical architecture, implementation decisions, and testing strategy are NOT part of PRD — they belong in a separate ADR document created in a later step.
Skip steps that are clearly not applicable, but do not skip the required question step. Do not repeat information the user has already provided.
本技能用于生成产品需求文档（PRD）。PRD涵盖功能需求、用户流程、UX/UI、用户画像和业务约束。技术架构、实现决策和测试策略不属于PRD的范畴——这些内容应归入后续步骤中创建的独立ADR文档。
明显不适用的步骤可以跳过，但不得跳过必填的提问环节。不要重复用户已经提供的信息。

Process

流程

Step 1 — Gather initial description

步骤1 — 收集初始描述

If not already provided, ask the user for a detailed description of the product or feature: what problem it solves, who it's for, and any ideas they already have about how it should work.
如果用户尚未提供相关信息，请向其索要产品或功能的详细描述：它解决什么问题、面向哪些用户、以及用户对其运作方式已有的任何想法。

Step 2 — Explore the repo (if applicable)

步骤2 — 探索代码仓库（如适用）

If this is a feature added to an existing codebase, explore it to understand the current state. Verify the user's assumptions. Do not skip this if there is relevant existing code.
如果这是添加到现有代码库的功能，请先探索代码库以了解当前状态，验证用户的假设。如果存在相关的现有代码，不得跳过此步骤。

Step 3 — Ask clarifying questions (REQUIRED — minimum 5)

步骤3 — 提出澄清问题（必填 — 至少5个）

Ask the user at least five focused clarifying questions before writing the PRD. Do not start writing until you have answers. If the brief already covers a listed topic, ask a deeper question about another decision instead of repeating it.
Cover at minimum:
  • Who are the users? Any specific personas or edge cases?
  • What happens after the main happy-path action? (e.g., after form submit, after AI decision)
  • What are the explicit out-of-scope items for this PoC/MVP?
  • What should happen in error and unclear/ambiguous cases?
  • Are there any external constraints — legal, API limits, third-party rules, file formats — that need to be validated before writing?
  • What does the UI/UX need to look like at a wireframe level?
  • If AI/agents are involved: what should the agent do when it cannot make a clear decision? What is it NOT allowed to do?
Resolve decisions that affect the main flows before writing. Record any remaining assumptions or open questions in the PRD rather than inventing answers.
在撰写PRD之前，至少向用户提出5个有针对性的澄清问题。在得到答复前不得开始撰写。如果需求简介已经涵盖了某个列出的主题，请针对其他决策提出更深入的问题，而非重复已有内容。
至少涵盖以下方面：
  • 用户是谁？有哪些特定的用户画像或边缘场景？
  • happy path（正常流程）的主操作完成后会发生什么？（例如：表单提交后、AI做出决策后）
  • 本次PoC/MVP的明确不包含项有哪些？
  • 出现错误或情况不明确/模棱两可时应如何处理？
  • 是否存在任何外部约束——法律、API限制、第三方规则、文件格式——需要在撰写前验证？
  • 线框图层面的UI/UX需要是什么样的？
  • 如果涉及AI/Agent：当Agent无法做出明确决策时应该怎么做？它有哪些禁止操作？
在撰写前先确定影响主流程的决策。将所有剩余的假设或待解决问题记录在PRD中，不要自行编造答案。

Step 4 — Research external facts (if needed)

步骤4 — 调研外部事实（如需要）

If the product involves external APIs, file format constraints, legal requirements, or third-party service limits, research them before writing. Do not put unverified numbers or constraints into the PRD.
如果产品涉及外部API、文件格式约束、法律要求或第三方服务限制，请在撰写前进行调研。不要将未经核实的数字或约束写入PRD。

Step 5 — Write the PRD

步骤5 — 撰写PRD

Use the template below. Save the result as 
docs/PRD.md
(or the path the user specifies).
使用下方的模板。将结果保存为
docs/PRD.md
（或用户指定的路径）。

Step 6 — Stop, then ask about the ADR

步骤6 — 停止，然后询问ADR相关事宜

Stop once the PRD is saved. Do not begin implementation, and do not write the ADR in the same run.
Ask the user whether they want to continue now with the 
write-adr
skill to generate the ADR from this PRD. The user decides — do not start it unprompted, and do not assume the answer is yes.
PRD保存完成后立即停止。不要开始实现，也不要在同一次运行中撰写ADR。
询问用户是否要现在使用
write-adr
技能基于该PRD生成ADR。由用户决定——不要未经提示就开始，也不要默认答案是肯定的。

Rules

规则

  • Language: Always write the PRD in English, regardless of the language of the brief or conversation.
  • No marketing language: No fluff, no "users will be delighted", no vague superlatives. Every sentence must be useful to a developer or agent implementing the product.
  • No technical implementation details: Do not specify frameworks, libraries, file paths, SDK choices, database schemas, or code patterns. Those belong in the ADR (Architecture Decision Records). Mention functional behavior only.
  • No testing strategy: Test cases and testing decisions belong in the ADR, not the PRD.
  • Measurable acceptance criteria: Every AC must be verifiable. "Works correctly" is not an AC. "For a file larger than 10 MB, the product does not save the file and displays 'File exceeds the 10 MB limit'" is.
  • Out of Scope is mandatory: Explicitly listing what is NOT in scope is as important as listing what is. It prevents scope creep during implementation.
  • Purpose: The PRD will be used by a developer agent to create an ADR, and then to implement the application. Write for that audience.
  • 语言：无论需求简介或对话使用何种语言，PRD始终使用英文撰写。
  • 禁止营销话术：不要空话套话，不要“用户将倍感愉悦”这类表述，不要模糊的最高级形容词。每一句话都必须对实现产品的开发者或Agent有实用价值。
  • 禁止技术实现细节：不要指定框架、库、文件路径、SDK选型、数据库schema或代码模式。这些内容属于ADR（架构决策记录）的范畴。仅描述功能行为。
  • 禁止测试策略内容：测试用例和测试决策属于ADR范畴，不属于PRD。
  • 可衡量的验收标准：每条AC都必须是可验证的。“正常运行”不算是验收标准。“对于大于10 MB的文件，产品不保存该文件并显示‘File exceeds the 10 MB limit’”才是合格的验收标准。
  • 必须包含“不包含范围”：明确列出不在范围内的内容与列出包含的内容同等重要，这可以防止实现过程中的范围蔓延。
  • 用途：PRD将供开发者Agent用于创建ADR，进而实现应用程序。请面向该受众撰写。

PRD Template

PRD模板

markdown
undefined
markdown
undefined

PRD — [Product / Feature Name]

PRD — [Product / Feature Name]

1. Executive Summary

1. Executive Summary

2-3 sentences. What is being built, for whom, and what problem it solves. This is a PoC/MVP/feature — state it.
2-3 sentences. What is being built, for whom, and what problem it solves. This is a PoC/MVP/feature — state it.

2. Problem Statement

2. Problem Statement

What problem exists today. Why it matters. What the user currently has to do instead. No solution here — only the problem.
What problem exists today. Why it matters. What the user currently has to do instead. No solution here — only the problem.

3. Users / Personas

3. Users / Personas

2-3 concrete personas. For each: who they are, what they want to do, what they expect from the outcome.
2-3 concrete personas. For each: who they are, what they want to do, what they expect from the outcome.

4. Main Flows

4. Main Flows

One subsection per scenario (happy path + key alternative paths). Step-by-step numbered list. Include what the system does at each step, not just what the user does.
One subsection per scenario (happy path + key alternative paths). Step-by-step numbered list. Include what the system does at each step, not just what the user does.

5. User Stories

5. User Stories

Format: "As [who], I want [what], so that [why]."
Minimum 4 user stories. Cover:
  • Happy path (main scenario)
  • Error cases (invalid input, service unavailable, ambiguous result)
  • Session/state scenarios (if applicable)
Format: "As [who], I want [what], so that [why]."
Minimum 4 user stories. Cover:
  • Happy path (main scenario)
  • Error cases (invalid input, service unavailable, ambiguous result)
  • Session/state scenarios (if applicable)

6. Acceptance Criteria

6. Acceptance Criteria

Group by area (Form, AI Decision, Chat, Session, General, etc.). Each criterion is prefixed AC-XX and is a single, testable, measurable statement. Do not use subjective language.
Group by area (Form, AI Decision, Chat, Session, General, etc.). Each criterion is prefixed AC-XX and is a single, testable, measurable statement. Do not use subjective language.

7. Out of Scope

7. Out of Scope

Explicit list of what is NOT being built. Use bold headers for each item. Include: auth, integrations, admin UI, notifications, multilingual support, mobile apps, etc. — whatever does not apply.
Explicit list of what is NOT being built. Use bold headers for each item. Include: auth, integrations, admin UI, notifications, multilingual support, mobile apps, etc. — whatever does not apply.

8. Constraints

8. Constraints

Business

Business

Policy, legal, or operational constraints the product must respect.
Policy, legal, or operational constraints the product must respect.

Functional

Functional

Concrete limits: file size, accepted formats, number of items, supported browsers/devices, language, etc.
Concrete limits: file size, accepted formats, number of items, supported browsers/devices, language, etc.

External document / data references (if applicable)

External document / data references (if applicable)

If the product uses external files (policy docs, knowledge base, etc.), list them in a table: document name | file path | when it is used.
If the product uses external files (policy docs, knowledge base, etc.), list them in a table: document name | file path | when it is used.

9. UI Description (wireframe level)

9. UI Description (wireframe level)

One subsection per screen. Describe:
  • What the user sees (layout structure, key elements)
  • What each interactive element does
  • Error states and empty states
  • Loading states
  • Navigation between screens
No visual design details (colors, fonts, spacing). Functional and UX detail only.
One subsection per screen. Describe:
  • What the user sees (layout structure, key elements)
  • What each interactive element does
  • Error states and empty states
  • Loading states
  • Navigation between screens
No visual design details (colors, fonts, spacing). Functional and UX detail only.

10. User Flow Diagram

10. User Flow Diagram

Mermaid flowchart covering all main flows from Section 4, including branching and error paths.
mermaid
flowchart TD
    ...
Mermaid flowchart covering all main flows from Section 4, including branching and error paths.
mermaid
flowchart TD
    ...

11. Agent / System Behavior Specification (if applicable)

11. Agent / System Behavior Specification (if applicable)

Include this section if the product involves an AI agent, LLM, or automated decision system.
  • Role and purpose of the agent
  • What the agent is allowed to do and what it is NOT allowed to do
  • Decision categories and how each should be communicated
  • Mandatory disclaimers or legal notices the agent must always include
  • How the agent should handle off-topic questions or out-of-scope requests
  • Language and tone requirements
Include this section if the product involves an AI agent, LLM, or automated decision system.
  • Role and purpose of the agent
  • What the agent is allowed to do and what it is NOT allowed to do
  • Decision categories and how each should be communicated
  • Mandatory disclaimers or legal notices the agent must always include
  • How the agent should handle off-topic questions or out-of-scope requests
  • Language and tone requirements

12. Further Notes (optional)

12. Further Notes (optional)

Any open questions, assumptions made, or decisions deferred to a later stage.
undefined
Any open questions, assumptions made, or decisions deferred to a later stage.
undefined