| name | prd-writer |
| description | PRD authoring and refinement. Activated when the user says "write PRD", "draft PRD", "break down feature", "scope this", "requirements for", "define feature", or wants to turn a rough idea into a structured product document. |
| allowed tools | Read, Write, Edit, Grep, Glob |
PRD Writer
Turn rough ideas into structured PRDs following the project's template.
The PRD is the single source of truth for what to build and why.
Rules
- Always use the template — read
docs/product/_template-prd.md first
- Clarify before writing — ask questions if the idea is ambiguous (max 5 questions)
- Scope aggressively — define what is OUT of scope as clearly as what is IN scope. The "Not Doing" list is arguably the most valuable part of the PRD
- User stories over descriptions — "As a [user], I want [action], so that [benefit]"
- Acceptance criteria are testable — each criterion must be verifiable by running code
- Check memory first — search for past features that might overlap or inform this one
- Reference, don't duplicate — link to ADRs, specs, and existing PRDs with
[[wiki-links]]
- Output to docs/product/ — never create PRDs elsewhere
Workflow
Phase 1: Understand the idea
- Read the user's description / rough idea
- Search memory for related past features:
python memory/query.py "[topic]"
- Check existing PRDs in
docs/product/ for overlap
- If the idea is vague, ask up to 5 clarifying questions:
- Who is the target user?
- What problem does this solve?
- What does "done" look like?
- Are there constraints (timeline, tech, regulatory)?
- What is explicitly out of scope?
Phase 2: Draft the PRD
Read the template and fill in every section:
- Context — why now? What triggered this feature?
- Objective — one sentence: what this feature will accomplish
- Scope
- Includes: specific deliverables
- Excludes: what this PRD does NOT cover (critical for preventing scope creep)
- "Not Doing" list — explicitly document what you chose NOT to build and why.
This is arguably the most valuable section: it prevents scope creep and aligns expectations.
## Not Doing (and why)
- **Multi-language support** — not needed for MVP; all users are PT-BR
- **Admin dashboard** — managed via database until user count justifies UI
- **Email notifications** — WhatsApp is the primary channel; email adds complexity without value
- User stories — 3-7 stories in
As a... I want... So that... format
- Design — reference Figma link OR note "use design tokens" for agent flow
- Acceptance criteria — numbered, testable statements:
AC-1: When [condition], then [expected result]- Each must be verifiable by running a test or checking behavior
- Technical decisions — link to existing ADRs or note that new ones are needed
- Impact on specs — check each active spec module:
- Rollout — feature flags, migration plan, rollback strategy
Phase 3: Review
- Read the PRD back and verify:
- Every user story has acceptance criteria
- Scope excludes are clear
- Technical decisions reference ADRs
- Spec impact is assessed
- Name the file:
docs/product/feat-{short-name}.md
- Present the PRD summary and ask for approval before saving
PRD Quality Checklist
References
docs/product/_template-prd.md — the templatedocs/product/vision.md — product vision (PRD must align)docs/architecture/ — existing ADRs to referencedocs/specs/ — active spec modules to check for impact
