PRD Creation

Follow the phases below to transform product ideas into a complete PRD document. All PRD content is written in Chinese (the target audience is Chinese-speaking teams).

Output Mode

Determine output mode from $ARGUMENTS:

| Argument | Mode | Output | |----------|------|--------| | --md (default) | Local Markdown | Save as .md file to project directory | | --lark | Feishu Cloud Doc | Create via lark-cli using Lark rich-text features |

--lark mode accepts optional location arguments (mutually exclusive), supporting token or Feishu URL:

• --folder-token — Target folder (token or URL)
• --wiki-node — Target wiki node (token or URL)
• --wiki-space — Target wiki space root (ID or URL, or my_library)

Pass URL directly to lark-cli — no manual token extraction needed. Defaults to user's personal space root when no location specified.

Phase 0: Import Context

Check for existing design or requirements documents:

1. Search for docs/, prd/ directories or user-specified files
2. If found, extract key information (problem statement, target users, core features) as pre-filled content
3. If nothing found, skip this phase

Phase 1: Determine PRD Type

Ask the user which PRD type they need:

• Full (recommended): All standard sections, suitable for complex features
• Brief: Core sections only, suitable for small features or quick iteration
• One-pager: Single-page summary, suitable for concept validation and executive reporting

Phase 2: Gather Information

Follow the interview questions in references/prd-interview-questions.md, one question at a time. Wait for the answer before continuing.

• Basic info (7 items): required for all types
• Full version extras (5 items): full type only
• AI Agent boundaries: needed when the PRD will be consumed by AI coding agents

If Phase 0 found pre-filled content, show it to the user for confirmation and skip covered questions.

Phase 3: Generate PRD Document

1. Select template:

• Full: references/prd-template-full.md
• Brief: references/prd-template-brief.md
• One-pager: references/prd-template-onepager.md

1. Fill content: Use gathered information for each section, following references/prd-best-practices.md writing principles

1. AI Agent consumability:

• Write each requirement as a discrete, verifiable item (lists over long paragraphs)
• Express non-goals as positive constraints
• Split P0 features into 5-15 minute agent work stages with testable checkpoints
• Full version includes a three-layer boundary framework: autonomous / needs confirmation / prohibited

1. Quality requirements:

• Problem statement backed by specific data or research
• Goals follow SMART principles
• Success metrics are quantifiable
• Avoid vague terms ("approximately", "maybe", "try to")
• Use active voice and concrete verbs

1. Format:

• --md mode: Standard Markdown with clear heading hierarchy
• --lark mode: Lark-flavored Markdown (see Feishu enhancements section)

Phase 4: Validate and Save

Run validation per references/prd-validation-checklist.md — completeness, SMART goals, content quality, BDD acceptance criteria.

--md Mode

Save file after validation:

• Filename: PRD-[ProductName]-[YYYYMMDD].md
• Prefer docs/ or prd/ directory, otherwise current working directory
• Report path and file summary

--lark Mode

Create Feishu document after validation:

1. CRITICAL — Confirm standalone lark plugin (lark@frad-dotclaude) is installed; follow its lark-shared skill for authentication
2. Follow the lark plugin's lark-doc skill for document creation guidance
3. Refer to lark-doc-create.md for full docs +create parameters and Lark-flavored Markdown syntax
4. Convert PRD content to Lark-flavored Markdown (see Feishu enhancements section)
5. Create document:

bash lark-cli docs +create --title "PRD-[ProductName]-[YYYYMMDD]" \ [--folder-token TOKEN_OR_URL | --wiki-node TOKEN_OR_URL | --wiki-space ID_OR_URL] \ --markdown "<lark-flavored-markdown>"

1. For longer PRDs, split: docs +create for first half, then docs +update --mode append for remaining sections
2. If board_tokens are present:

• Follow the lark plugin's lark-whiteboard skill
• Fill each whiteboard with actual content (flowcharts, architecture diagrams)
• All whiteboards must have real content before task is complete

1. Report the document URL

Phase 5: Next Steps

After saving, suggest follow-up options:

• Convert PRD into implementation tickets
• Refine design decisions in open questions
• Share with team for review and feedback

Feishu Document Enhancements

CRITICAL — In --lark mode, use Lark-flavored Markdown syntax to leverage Feishu's rich-text capabilities.

Required Feishu Features by PRD Section

| PRD Section | Feishu Feature | Description | |---|---|---| | Project metadata (version/date/owner) | <lark-table> | Enhanced table with header row | | Key risks/assumptions/dependencies | <callout> | Color-coded: risk=red, assumption=blue, dependency=yellow | | Core goals / success metrics | <callout emoji="..." background-color="light-green"> | Highlight key OKRs | | Priority comparison (P0/P1/P2) | <grid cols="3"> | Three-column side-by-side layout | | User journey / business process | <whiteboard type="blank"> | Flowchart, filled via lark-whiteboard | | System architecture | <whiteboard type="blank"> | Architecture diagram, filled via lark-whiteboard | | Milestones / timeline | <whiteboard type="blank"> | Timeline chart | | Non-goals / scope exclusions | <callout emoji="..." background-color="light-red"> | Red highlight for prohibited scope | | Glossary / abbreviations | Two-column Markdown table | Compact reference | | Decision records | <callout> + blockquote | Key decisions with rationale |

Whiteboard Rules

Insert whiteboards for: user journeys, system architecture, data flows, milestones, team organization. Skip for pure text, data-heavy content (use tables), or when user requests text-only.

Format Principles

• Max 4 heading levels
• Use --- dividers between sections
• Do NOT write a top-level heading duplicating the title (Feishu auto-generates it)
• Use callouts sparingly; bold only core terms
• Use <text color="red"> for key metrics or status
• Feishu auto-generates table of contents — do not add manually

Quality Principles

• Data-driven: Support problem statements with specific data and user research
• SMART goals: Specific, Measurable, Achievable, Relevant, Time-bound
• Concise and clear: Avoid verbosity; descriptions must be clear enough for dev teams to implement directly
• Collaboration-oriented: PRD is a collaboration tool; tone promotes discussion, not command
• Dual-audience design: Serve both human teams and AI coding agents

Supporting Files

• references/prd-interview-questions.md — Information gathering questionnaire
• references/prd-validation-checklist.md — Validation checklist
• references/prd-template-full.md — Full version template
• references/prd-template-brief.md — Brief version template
• references/prd-template-onepager.md — One-pager template
• references/prd-best-practices.md — Best practices guide
• references/prd-examples.md — High-quality PRD examples
• Standalone lark plugin (lark@frad-dotclaude) — Lark CLI skills (--lark mode)