# Requirements To Prd

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-lucky2024-pllove-product-to-delivery-lifecycle-skills-requirements-to-prd`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [Lucky2024-pllove](https://agentstack.voostack.com/s/lucky2024-pllove)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [Lucky2024-pllove](https://github.com/Lucky2024-pllove)
- **Source:** https://github.com/Lucky2024-pllove/product-to-delivery-lifecycle-skills/tree/main/requirements-to-prd

## Install

```sh
agentstack add skill-lucky2024-pllove-product-to-delivery-lifecycle-skills-requirements-to-prd
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Requirements To Product Docs

# Production Addendum

Before doing normal PRD work, read and follow [references/production-pipeline-rules.md](references/production-pipeline-rules.md). These production rules override older default behavior when they conflict.

Key production requirements:

1. Prefer the gated flow: raw requirement -> requirement analysis -> user confirmation -> interactive prototype -> user confirmation -> PRD.
2. Support shortcuts, but mark skipped stages as risk and list assumptions.
3. Produce both structured technical documents and natural-language guide documents when writing files.
4. Requirement analysis must include JTBD: situation, motivation, expected progress, functional job, emotional job, social job.
5. AI/Agent sections are conditional. First classify the work as Traditional, AI-enhanced, or AI-core, explain why, and let the user confirm or override.
6. Traditional requirements must not get AI/Agent chapters beyond a short "not in scope" note.
7. Every output stage must include open questions and a confirmation checklist.
8. Use the user-specified output folder or `PRD/`; never overwrite existing files.

Produce a **complete stage package** by default, not only the main PRD body. The production rules require every generated stage to account for four output types: structured document, natural-language guide, open-question list, and confirmation checklist.

When producing the requirement-analysis stage, write or output:

```text
01-requirement-analysis.md
01-requirement-analysis-guide.md
01-open-questions.md
01-requirement-analysis-confirmation.md
```

When producing the PRD stage, write or output:

```text
03-prd.md
03-prd-guide.md
03-open-questions.md
03-prd-confirmation.md
03-traceability-matrix.md
```

`03-traceability-matrix.md` may be omitted only when the PRD is small and the PRD itself already contains a complete FA/FR/AC/OQ traceability matrix; explicitly state the reason when omitting it.

If the user asks for only one document, still account for the missing companion outputs in the response: either generate them, state that the user explicitly scoped them out, or list them as intentionally omitted. If the user asks to write files, prefer the numbered pipeline file names above. Project-name legacy names may be used only when the user requests them.

When the project name is missing, infer a concise name from the requirement. If inference is risky, use `待命名项目` in the document title and ask the user to confirm before writing final files.

## Operating Rules

1. Start from the user's source words, then separate **facts**, **inferences**, **assumptions**, and **questions to confirm**.
2. Do not copy the user's proposed solution blindly. First identify the real problem and evaluate whether the proposed solution solves the root cause.
3. Atomize requirements before writing EARS. A functional atom must have independent value and a clear **Input -> Process -> Output** chain, plus constraints and acceptance signal.
4. Use EARS for system behavior and Given-When-Then for acceptance. Keep every FR traceable to one or more AC items.
5. Treat AI as a solution pattern, not a default answer. Decide whether the product is traditional, AI-enhanced, or AI-core before writing the PRD. Traditional software uses the standard PRD structure; AI-enhanced/AI-core products must add AI/Agent-specific sections.
6. Keep PRD acceptance criteria inside the PRD. Put full test cases in a separate document only when the user asks for test cases.
7. Include standard PRD visualizations by scenario signal. Every **core scenario / MVP main path** must include at least one business flowchart unless the scenario is truly atomic and the PRD explicitly explains why no diagram is useful. Add sequence/state/ER/architecture diagrams when their signals are present. Use Mermaid by default for Codex, Claude Code, Cursor, and other Markdown-capable agents. See [references/diagram-guide.md](references/diagram-guide.md).
8. Mermaid diagrams must use cross-platform compatible syntax. Use English/digit/underscore IDs, put Chinese in display labels or aliases, avoid high-risk edge-label syntax such as `-.label.->`, keep version numbers and punctuation-heavy text out of edge labels, and run a Mermaid compatibility self-check before delivery.
9. Treat generated documents as **drafts** until human review. When the user says the PRD is approved, mark it as **baselined** and prepare handoff inputs for the downstream `prd-to-dev-spec` skill.
10. Demo files are for regression and maintenance only. Do not read demo files during normal generation unless the user asks to run or inspect the demo.
11. Use stable IDs across the monorepo pipeline (see **ID conventions** below). Prefer numbered open questions `OQ-{nn}` with owner and impact over bare **待确认** on execution-critical fields (amount rules, auth, deployment, data store).
12. Include a **traceability table** (goal or FA -> FR -> AC) in the PRD for human review and downstream agents. Optional: append `{project-name}-traceability-matrix.md` when the project is large.

### ID conventions (pipeline-wide)

| Type | Format | Example |
|------|--------|---------|
| Functional atom | `FA-{nnn}` | FA-001 |
| Functional requirement (EARS) | `FR-{nnn}` | FR-001 |
| Acceptance criterion (GWT) | `AC-{nn}` | AC-01 |
| Open question | `OQ-{nn}` | OQ-01 |
| Business rule | `BR-{nnn}` | BR-001 |
| Use case (optional) | `UC-{nn}` | UC-01 |

Do **not** mix `AC-001` and `AC-01`. Test cases (`TC-{nnn}`) are produced by `prd-to-dev-spec`, not this skill.

## Reference Loading

Load only the references needed for the current request:

| Need | Reference |
|------|-----------|
| Seven-layer product methodology | [references/methodology.md](references/methodology.md) |
| Requirement analysis, functional atomization, EARS conversion | [references/requirement-decomposition.md](references/requirement-decomposition.md) |
| Real solution discovery and feasibility judgement | [references/solution-feasibility.md](references/solution-feasibility.md) |
| AI-enhanced or AI-core PRD patterns | [references/ai-prd-patterns.md](references/ai-prd-patterns.md) |
| Acceptance criteria vs test cases | [references/acceptance-testing.md](references/acceptance-testing.md) |
| Diagram selection | [references/diagram-guide.md](references/diagram-guide.md) |
| Mermaid rendering compatibility | [references/mermaid-compatibility.md](references/mermaid-compatibility.md) |

## Agent Compatibility

Keep outputs portable across Codex, Claude Code, Cursor, and other Markdown-capable agents:

- Use plain Markdown, tables, and Mermaid diagrams.
- Do not rely on proprietary canvas/design tools unless the user explicitly asks.
- If an agent cannot load `references/`, summarize the needed reference rules into the current response.
- If an agent cannot write files, output the file names and Markdown bodies in chat.

## Bilingual Usage

Match the user's requested output language. If the user writes in Chinese or does not specify a language, Chinese output is acceptable; if the user asks for English, produce English documents. Keep frontmatter metadata in English for cross-agent compatibility.

Common Chinese requests that should trigger this skill include:

- 需求分析
- 产品需求文档 / PRD
- 把想法整理成 PRD
- AI 产品需求分析
- 判断需求是否需要 AI 能力
- 梳理用户场景
- 需求确认清单

## Workflow

### 1. Intake And Classification

Extract:

| Item | Output |
|------|--------|
| User source text | Quote or summarize the original requirement |
| Project name | Infer or mark `待确认` |
| Requirement type | New product / feature / process optimization / AI application / integration / reporting / other |
| Current shape | Problem statement / feature wish / proposed solution / mixed |
| Delivery mode | Complete stage package by default; local files if requested |

### 2. Requirement Analysis

Build the analysis before the PRD:

1. Background and opportunity
2. Problem statement and root cause
3. Users, roles, scenarios, and current workflow
4. Goals, constraints, dependencies, and non-goals
5. Functional atom table
6. Candidate solution comparison and feasibility decision
7. AI/traditional solution classification
8. MVP scenario recommendation: the smallest closed-loop V1 scenario, later versions, and out of scope
9. Risks, open questions, and validation plan

Use [references/requirement-decomposition.md](references/requirement-decomposition.md) and [references/solution-feasibility.md](references/solution-feasibility.md) when the request is vague, complex, solution-shaped, or AI-related.

### 3. PRD

Convert the approved or recommended analysis into a PRD:

1. Background and goals
2. Problem definition
3. Users, scenarios, and current state
4. Product solution and scope, including the smallest MVP scenario
5. Functional requirements with EARS
6. Business rules
7. Exceptions, boundaries, and error handling
8. Permissions and data
9. Non-functional requirements
10. Acceptance criteria with GWT
11. Priority, versioning, roadmap, metrics, risks, and traceability

For AI-enhanced or AI-core products, add AI/Agent sections for Agent work design, AI/Agent function list, prompt design, data/privacy, evaluation, fallback, and monitoring. Use [references/ai-prd-patterns.md](references/ai-prd-patterns.md).

### 4. Visualization

Include Mermaid diagrams when they help standard PRD communication:

| Signal | Recommended Diagram |
|--------|---------------------|
| Core scenario or MVP main path | At least one `flowchart`, unless explicitly explained as unnecessary |
| User or business steps across roles | `flowchart` |
| Object lifecycle, approval, order, ticket, task states | `stateDiagram` |
| Multiple systems or roles exchanging messages | `sequenceDiagram` |
| Key entities and relationships | `erDiagram` |
| System/module boundaries | Architecture `flowchart` or lightweight C4-style diagram |

Diagram decision rules:

1. For each **core scenario** in the requirement analysis, decide whether it is part of the MVP main path.
2. For the MVP main path, include a business flowchart by default.
3. If the scenario involves two or more systems, roles, or services exchanging messages, add a sequence diagram.
4. If a business object has states, approvals, lifecycle, or allowed/forbidden transitions, add a state diagram.
5. If entities/fields/relationships are important for implementation or reporting, add an ER/data relationship diagram.
6. If module/system boundaries matter, add an architecture/module diagram.
7. If a diagram type is not useful, explicitly say why in the PRD.

Use [references/diagram-guide.md](references/diagram-guide.md) for detailed selection. Keep all diagrams as Markdown/Mermaid so the skill remains portable across Codex, Claude Code, Cursor, and other agents. Use [references/mermaid-compatibility.md](references/mermaid-compatibility.md) before final delivery.

### 5. Optional Test Cases

If the user asks for test cases, produce a separate file:

```text
{project-name}-测试用例.md
```

Derive test cases from PRD acceptance criteria, not directly from raw requirements. Use [references/acceptance-testing.md](references/acceptance-testing.md).

### 6. Companion Outputs And Stage Gate

After drafting the analysis or PRD body, generate the companion outputs for the same stage:

| Stage | Structured document | Natural-language guide | Open-question list | Confirmation checklist | Optional traceability |
|---|---|---|---|---|---|
| Requirement analysis | `01-requirement-analysis.md` | `01-requirement-analysis-guide.md` | `01-open-questions.md` | `01-requirement-analysis-confirmation.md` | Included in analysis when useful |
| PRD | `03-prd.md` | `03-prd-guide.md` | `03-open-questions.md` | `03-prd-confirmation.md` | `03-traceability-matrix.md` |

The guide explains the document in plain language for non-technical stakeholders. The open-question file carries all `OQ-{nn}` items with owner, impact, and blocker status. The confirmation file states what must be approved before the next pipeline stage. Do not rely on a PRD appendix alone when the user asked to write files; create the separate files unless explicitly scoped out.

### 7. Human Review And Baseline

Use this status model:

| Status | Meaning | Next Step |
|--------|---------|-----------|
| Draft | AI-generated initial document | Human product/business review |
| In Review | Reviewer comments are pending or being addressed | Revise and summarize changes |
| Baselined | Human-approved product scope | Hand off to `prd-to-dev-spec` |
| Changed | Approved PRD was modified after baseline | Create change note and re-review |

When reviewers provide comments, revise the analysis/PRD and output a concise change summary. Do not silently change baselined scope.

Before downstream handoff, ensure the PRD contains:

- [ ] Baselined version and approval status
- [ ] MVP scenario and V1 scope
- [ ] Functional atoms, FR, AC, and traceability
- [ ] Business rules, data, permissions, exceptions, NFRs
- [ ] Diagrams or explicit explanation for omitted diagrams
- [ ] Open questions either closed or assigned owners

Downstream file names should use the same project name:

```text
{project-name}-开发说明文档.md
{project-name}-测试用例.md
{project-name}-开发任务确认单.md
```

## Requirement Analysis Template

```markdown
# {项目名} 需求分析文档

> **文档状态**：草案  **版本**：v0.1  **日期**：YYYY-MM-DD  **作者**：Agent+用户
> **评审状态**：待评审 | 评审中 | 已基线
> **关联 PRD**：{项目名}-产品需求文档PRD.md

## 0. 需求来源与处理说明
| 项目 | 内容 |
|------|------|
| 用户原始输入 | ... |
| 已确认事实 | ... |
| 推断与假设 | ... |
| 待确认 | OQ-01 ... |

## 1. 背景与机会
## 2. 问题定义与根因
### 2.1 问题陈述
**谁** 在 **什么场景** 下遇到 **什么问题**，导致 **什么影响**。
### 2.2 JTBD

## 3. 用户、角色、场景与当前流程
## 4. 目标、约束与不做范围
## 5. 需求拆解与功能原子
| 原始需求点 | 功能原子ID | 功能原子 | Input（输入/触发） | Process（处理/规则） | Output（输出/结果） | 约束 | 验收信号 |
|------------|------------|----------|--------------------|-----------------------|----------------------|------|----------|
| ... | FA-001 | ... | ... | ... | ... | ... | ... |

## 6. 候选方案与可行性判断
| 方案 | 解决的问题 | 依赖/成本 | 风险 | 建议 | 备注 |
|------|------------|----------|------|------|------|
| ... | ... | ... | 低/中/高 | 推荐/暂缓/不建议 | ... |

## 7. AI/传统方案分类
| 分类结果 | 判断依据 | 风险 | 用户确认点 |
|----------|----------|------|------------|
| 传统 / AI-enhanced / AI-core / 待确认 | ... | ... | ... |

## 8. AI/Agent 工作设计（AI 应用适用）
### 8.1 Agent 工作流
### 8.2 Agent 职责表
| Agent/能力 | 职责 | 输入 | 输出 | 工具/数据 | 质量指标 | 兜底 |
|------------|------|------|------|-----------|----------|------|

### 8.3 时序图说明
### 8.4 AI/Agent 功能清单
| 功能 | 描述 | 触发条件 | 输入 | 输出 | 质量指标 | 失败兜底 |
|------|------|----------|------|------|----------|----------|

### 8.5 Prompt 设计概要
| Prompt | 目的 | 输入变量 | 输出格式 | 安全边界 | 验收样例 |
|--------|------|----------|----------|----------|----------|

## 9. MVP 场景与 V1 范围建议
### 9.1 最小闭环 MVP 场景
用一句话说明 V1 最小可交付闭环：
> 当「目标用户」在「核心场景」中，需要完成「关键任务」时，系统通过「最小能力组合」帮助其得到「可验证结果」。
### 9.2 V1 / 后续 / 不做

## 10. 风险、开放问题与验证计划
```

## PRD Template

```markdown
# {项目名} 产品需求文档（PRD）

> **文档状态**：草案  **版本**：v0.1  **日期**：YYYY-MM-DD  **作者**：Agent+用户
> **评审状态**：待评审 | 评审中 | 已基线
> **关联需求分析**：{项目名}-需求分析文档.md

## 1. 背景与目标
### 1.1 背景
### 1.2 业务目标与指标
| 目标 | 指标 | 基线/目标值 | 备注 |
|------|------|-------------|------|

## 2. 问题定义
## 3. 用户、场景与当前状态
## 4. 产品方案与范围
### 4.1 产品能力与范围
### 4.2 业务流程、状态或系统协作
### 4.3 标准可视化图（按需）
- **MVP 主路径业务流程图**：（核心/MVP 场景默认必填；若不画，写明原因）
- **其他业务场景流程图**
- **系统/模块架构图**
- **时序图**
- **状态图**
- **ER/数据关系图**
- **不采用某类图的原因**

### 4.4 最小闭环 MVP 场景
**MVP 场景**：当「目标用户」在「核心场景」中，需要完成「关键任务」时，系统通过「最小能力组合」帮助其得到「可验证结果」。
### 4.5 MVP 范围
**V1 必须达到**：...
**明确推迟**：...
**Out of Scope**：...
### 4.6 产品边界

## 5. 功能需求（EARS）
| FR | EARS 类型 | 需求描述 | 关联功能原子 | 优先级 |
|----|-----------|----------|--------------|--------|
| FR-001

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Lucky2024-pllove](https://github.com/Lucky2024-pllove)
- **Source:** [Lucky2024-pllove/product-to-delivery-lifecycle-skills](https://github.com/Lucky2024-pllove/product-to-delivery-lifecycle-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-lucky2024-pllove-product-to-delivery-lifecycle-skills-requirements-to-prd
- Seller: https://agentstack.voostack.com/s/lucky2024-pllove
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.