create-prd

create-prd

Based on the business context and requirements background provided by the user, generate a structured B2B PRD document with initial content.

Supports explicit invocation (e.g., /create-prd) and automatic triggering (when the user explicitly requests to create or write a PRD, requirements document, product plan, or enterprise system design).

Input

The business context and requirements background provided by the user (free text, meeting minutes, brief description, etc. are all acceptable)
or via $ARGUMENTS the file path passed in

If parameters are passed in, prioritize them as the input source:

$ARGUMENTS

Generation Process

Strictly follow the order below; steps must not be skipped or reordered.

Phase 0: Understand Context and Product Typing

Fully read and understand all business context provided by the user.
Infer from the user's description:
- Commercial attribute: commercial product or enterprise in-house system
- Function type: business management software / tool-based software / transaction-based platform / foundational service type
Present the inference result to the user in one sentence and request confirmation:

Based on your description, this is a [{commercial attribute} × {function type}] product {, brief rationale}. I will adjust the emphasis of each PRD chapter accordingly. Please correct me if anything is wrong.

Wait for user confirmation before continuing.
After confirmation, load the typing reference file to determine the adaptation rules for each chapter:

Product Typing and Chapter Adaptation

Phase 1: Front Chapters (Chapters 1-9)

Generate Chapters 1 through 9 in order. Upon completing each chapter,immediately outputthat chapter's content; do not wait until all chapters are complete to output them together.

Load the corresponding generation guide for each chapter:

Phase 2: Core Functional Requirements (Chapter 10)

This is the largest and most core chapter in the PRD. Load the generation guide:

Chapter 10 Functional Requirements

Generate in subsections:

10.1 Product Framework Overview (system framework diagram, data model diagram, business process diagram, state machine diagram, function list)
10.2 Detailed Product Requirements (module by module: flowchart → page interaction → business rules)
10.3 Exception Handling Plan

Phase 3: Back Chapters (Chapters 11-14)

Phase 4: Self-Check and Gap Analysis

After all chapters are generated, perform a lightweight self-check:

Self-Check and To-Be-Improved List

Output Specifications

Document Format

Output the PRD as a single Markdown document, with the following structure:

# {产品/项目名称} PRD

| PRD 审核人 | {待填写} |
| --- | --- |
| 重要性 | {高/中/低} |
| 紧迫性 | {高/中/低} |
| 需求方 | {从上下文推断或标注待填写} |
| PRD 编写人 | {用户姓名或待填写} |
| PRD 提交日期 | {当前日期} |

## PRD 修改记录

| 变更时间 | 变更内容 | 变更提出部门与理由 | 修改人 | 审核人 | 版本号 |
| --- | --- | --- | --- | --- | --- |
| {当前日期} | 初始版本 | — | {编写人} | {待填写} | v1.0 |

---

## 1、项目背景
...（各章节内容）

## 14、待决事项
...

---

## 附：待完善清单
...

Content Generation Rules

Generate substantive content when information is available: Based on the context provided by the user, generate a draft that is as specific and substantive as possible.
Mark when information is insufficient [TODO]: For parts where the user has not provided enough information, use [TODO: 具体需要补充什么] to mark them, rather than fabricating content.
Distinguish product types: Commercial products and enterprise self-developed systems have different content emphases; strictly adjust according to the product finalization results.
Make the theoretical framework explicit: In key chapters, use brief notes to explain the methodological framework used, helping users understand the design basis.
Structure first: Tables, lists, and Mermaid diagrams take priority over long passages of prose.
Use Mermaid for diagrams: Architecture diagrams, flowcharts, state machines, ER models, etc. are all generated using Mermaid code blocks, not ASCII pseudo-diagrams.

Diagram Generation Rules

In Chapter 10, Product Framework Overview, the following diagramsmust use Mermaid syntax：

Diagram Type	Mermaid Syntax	Must Include
Application Architecture Diagram	`graph TB` + `subgraph` Layering	User layer, access layer, business service layer, data layer, external systems
ER Data Model	`erDiagram`	All core entities + relationships + key attributes (PK/FK/status)
Business Flowchart	`flowchart TD`	Main flow + key branches + exception paths, with key nodes colored
State Machine Diagram	`stateDiagram-v2`	Normal + exception paths, with notes explaining constraints

Notes:

After the Mermaid diagram, attach the corresponding detailed table as supplementary explanation (e.g., state machine diagram + state transition table)
Use <br/> for line breaks in node text within diagrams to keep them concise
For specific templates and examples, see the Chapter 10 generation guide file

Chapter-by-Chapter Output Rules

Output each chapter immediately upon completion; do not wait until all chapters are complete to output them together.
Each chapter must have a clear chapter title, consistent with the PRD template structure.
For structured data (fields, permissions, rules, etc.), prioritize using tables.
Use > 💡 方法论提示： blockquotes to present the applied theoretical framework.
Mark uncertain content with [TODO] and explain what information needs to be supplemented.

Working Style

The goal is to generate a usable PRD scaffold that accelerates the product manager's work, rather than replacing their judgment.
When the user's context is sufficient, be as specific and substantive as possible; when information is insufficient, honestly mark the gaps.
Maintain a professional PRD writing style: precise, structured, and unambiguous.
Adjust depth according to the richness of the context provided by the user—a one-paragraph context generates a lightweight PRD, while detailed context generates a rich PRD.
If the context provided by the user is very limited, generate a structural framework with guidance notes, and proactively ask what supplementary information would help enrich the key chapters.