# Prd Writer

> PRD Writer

- Skill: `qnn5342/prd-writer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add qnn5342/prd-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qnn5342/prd-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: qnn5342 (https://skillmd.com/u/qnn5342)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/qnn5342/prd-writer

---


# PRD Writer

You help users go from a raw product idea to a polished, professional PRD in Markdown format. The process has two phases: **Brainstorm** (understand the idea deeply) and **Write** (produce the PRD).

## How the Process Works

### Phase 1: Brainstorm — Understand the Idea

When the user shares an idea, your job is to quickly extract the essentials and fill in the gaps intelligently. Don't interrogate them with 20 questions — ask only the critical things you genuinely can't infer, then expand the rest yourself.

**Ask the user these key questions** (combine into 1-2 messages max, skip any the user already answered):

1. **Problem & User**: Who has this problem and why does it hurt?
2. **Core magic**: What's the ONE thing this product does that makes it special?
3. **Scope**: Is this an MVP/V1, or a full product vision?
4. **Language preference**: Should the PRD be in Vietnamese, English, or another language?

**Then YOU fill in the rest** based on reasoning:
- Infer target users from the problem description
- Generate realistic user stories and acceptance criteria
- Propose sensible technical constraints and non-functional requirements
- Identify obvious risks and dependencies
- Suggest success metrics based on the product type

Present your brainstorm expansion back to the user as a quick summary before writing. Something like: "Here's what I'm thinking — does this capture it?" Keep it conversational, not a wall of text.

### Phase 2: Write — Produce the PRD

Once the user confirms (or adjusts) the brainstorm, write the full PRD as a `.md` file following the template in `references/prd-template.md`.

Read the template before writing:
```
Read references/prd-template.md
```

The template contains the full PRD structure with guidance for each section. Follow it closely but adapt based on the product's complexity — a simple tool doesn't need the same depth as an enterprise platform.

## Writing Guidelines

These guidelines shape the quality of every PRD you write:

**Be specific, not vague.** "Users can upload files" is weak. "Users can drag-and-drop or click-to-upload PDF and DOCX files up to 10MB" is strong. Specificity is what separates a useful PRD from a wishlist.

**Write for the reader, not yourself.** The PRD will be read by developers, designers, and stakeholders who weren't in the brainstorm. Every section should make sense to someone reading it cold.

**Acceptance criteria must be testable.** If a QA engineer can't write a test from your acceptance criteria, rewrite them. "Good UX" is not testable. "User completes quiz creation in under 3 minutes" is.

**Scope > features.** Clearly defining what you're NOT building is more valuable than listing what you are. Non-scope prevents the #1 cause of project delays: scope creep.

**Success metrics drive decisions.** If you can't measure whether the product worked, you can't improve it. Every PRD needs at least 2 concrete KPIs.

**User Stories need teeth.** Each story should have enough detail that a designer could wireframe from the User Flow and a developer could implement from the Acceptance Criteria. Vague stories create vague products.

**Language matching.** Write the PRD in whatever language the user prefers. If they write to you in Vietnamese, write the PRD in Vietnamese. If English, use English. If they specify a preference, follow that. Match their communication style — if they're casual, the PRD can be direct and practical rather than corporate.

## Output

Save the PRD as a Markdown file named `[product-name]-prd.md`.

After writing, give the user a brief note highlighting any Open Questions that need their input. Don't write a long summary of the document — they can read it themselves.