---

name: yepai-pm-write-prd description: >- PRD and product-writing specialist for turning a product problem, initiative, or idea into a structured product requirements draft. Use when the user needs a PRD, requirement doc, decision-ready scope draft, or clearer product writing for cross-functional alignment. metadata: {"openclaw":{"emoji":"📝"}} license: MIT-0

YepAI PM Write PRD

Use this skill when the user needs a structured product document, not just discussion.

Use Cases

• "write a PRD"
• "turn this into a requirement doc"
• "draft scope for engineering and design"
• "convert this discussion into a product spec"
• "make this proposal clearer and more actionable"

Core Rule

A PRD is not a feature dump. It should connect a user problem to goals, scope, constraints, tradeoffs, and validation. It must always make scope boundaries explicit through a Non-goals section.

PRD Workflow

1. Confirm the problem

Identify:

• target user
• current problem
• desired outcome
• why this matters now

If the problem is unclear, draft with explicit assumptions instead of faking certainty.

2. Define the scope

Clarify:

• what is included
• what is excluded
• what decision this document is supporting
• what constraints shape the scope

If the user does not provide explicit exclusions, infer the most likely draft non-goals from the problem, scope, and constraints, and label them clearly as draft non-goals.

3. Translate into execution-ready structure

A strong PRD should usually include:

• problem
• target users
• goals
• non-goals
• solution direction
• success metrics
• risks
• open questions

4. Make ambiguity visible

Separate:

• confirmed facts
• assumptions
• unresolved questions
• dependencies

5. End with next-step alignment

Make it easy for a team to react:

• review
• challenge
• estimate
• prioritize
• test

Output Format

Prefer this structure:

# PRD: [Initiative Name]

## Problem
## Target Users
## Goals
## Non-goals
## Proposed Solution
## Scope Notes
## Success Metrics
## Risks / Assumptions
## Open Questions
## Recommended Next Step

Do not omit section headings. If the user wants a lightweight draft, keep the full structure and shorten the content inside each section instead.

Quality Rules

• Start from the problem, not the feature
• Keep non-goals explicit
• Always include a ## Non-goals section, even when the exclusions are provisional
• Do not invent metrics or research
• Do not confuse PRD with roadmap timing
• Prefer clear, reviewable language over corporate filler
• If the user only wants a lightweight draft, keep it lean but preserve structure