write-prd

此技能用于创建产品需求文档（PRD）。PRD 涵盖功能需求、用户流程、UX/UI、用户画像和业务约束。技术架构、实现决策和测试策略不属于 PRD 的内容——它们应在后续步骤中单独创建的 ADR 文档中说明。

跳过明显不适用的步骤，但不得跳过必需的提问步骤。不要重复询问用户已经提供的信息。

---

流程

步骤 1 — 收集初始描述

如果用户尚未提供详细描述，请询问产品或功能解决什么问题、面向哪些用户，以及他们对产品或功能应如何运作已有的想法。

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

如果这是在现有代码库中添加功能，请探索代码库以了解当前状态，并核实用户的假设。如果存在相关代码，不要跳过此步骤。

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

在撰写 PRD 之前，至少向用户提出 5 个有针对性的澄清问题。在得到回答之前不要开始撰写。如果需求说明已涵盖某个主题，请针对其他决策提出更深入的问题，不要重复询问。

至少涵盖以下内容：

• 用户是谁？是否有特定用户画像或边缘情况？
• 主要成功流程中的操作完成后会发生什么？（例如，提交表单后、AI 作出决定后）
• 此 PoC/MVP 明确不包含哪些内容？
• 在错误和模糊不清的情况下应如何处理？
• 是否存在需要在撰写前验证的外部约束，例如法律要求、API 限制、第三方规则或文件格式？
• 在线框图层面，UI/UX 需要是什么样的？
• 如果涉及 AI/Agent：Agent 无法明确作出决定时应如何处理？它不得执行哪些操作？

撰写前解决影响主要流程的决策。将其余假设或未决问题记录在 PRD 中，不要自行编造答案。

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

如果产品涉及外部 API、文件格式限制、法律要求或第三方服务限制，请在撰写前进行调研。不要在 PRD 中写入未经核实的数字或约束。

步骤 5 — 撰写 PRD

使用下方模板。将结果保存为 docs/PRD.md（或用户指定的路径）。

步骤 6 — 停下，然后询问是否要编写 ADR

PRD 保存后即停止。不要开始实现，也不要在同一轮中撰写 ADR。

询问用户是否要立即继续使用 write-adr 技能，根据此 PRD 生成 ADR。由用户决定——不要主动开始，也不要假定用户会同意。

---

规则

• 语言：无论需求说明或对话使用何种语言，始终使用英文撰写 PRD。
• 不要使用营销语言：不要写空话、不要说“用户会感到愉悦”，也不要使用含糊的最高级表述。每句话都必须对实现产品的开发者或 Agent 有用。
• 不要写技术实现细节：不要指定框架、库、文件路径、SDK 选择、数据库架构或代码模式。这些内容属于 ADR（架构决策记录）。只描述功能行为。
• 不要写测试策略：测试用例和测试决策属于 ADR，不属于 PRD。
• 可衡量的验收标准：每条 AC 都必须可验证。“运行正常”不算验收标准。应写成：“对于大于 10 MB 的文件，产品不会保存该文件，并显示‘文件超过 10 MB 限制’。”
• 范围外内容为必填项：明确列出不在范围内的内容与列出范围内的内容同等重要。这可以防止实现过程中范围不断扩大。
• 用途：开发者 Agent 将使用 PRD 创建 ADR，然后实现应用程序。请面向该受众撰写。

---

PRD 模板

# PRD — [Product / Feature Name]

---

## 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. Problem Statement

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

---

## 3. Users / Personas

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

---

## 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.

---

## 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)

---

## 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.

---

## 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.

---

## 8. Constraints

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

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

### 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.

---

## 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.

---

## 10. User Flow Diagram

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

```mermaid
flowchart TD
    ...
```

---

## 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

---

## 12. Further Notes (optional)

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