| name | prd |
| description | Write a Product Requirements Document that leads with the problem, defines success metrics and non-goals, and expresses functional requirements as testable EARS criteria. Use when scoping what to build and why before design. Anti-trigger; for the technical how use feature-spec or a design doc, not a PRD. |
| argument-hint | <the product or feature to scope> |
prd
Produces a Product Requirements Document: problem-first, outcome-focused. A
PRD says what problem we solve, for whom, and how we'll know it worked —
not the implementation.
Pattern
- Problem Statement — lead with the user/business problem and its evidence.
Never open with the solution.
- Goals & Success Metrics — measurable outcomes (e.g. "reduce checkout
abandonment from 30% to 20%").
- Users / Personas — who is affected and their context.
- Requirements — the functional needs. Express testable ones as EARS
criteria (see the
ears-acceptance-criteria skill).
- Scope & Non-Goals — explicitly what's out, to prevent scope creep.
- Milestones — rough sequencing.
- Open Questions — known unknowns.
Agentic PRD note
Modern PRDs increasingly carry machine-readable, EARS-encoded requirements an
implementation agent can consume directly. Prefer EARS over prose for anything an
agent or QA must verify.
MIF frontmatter
type: semantic. Climb to L2 with namespace, tags, title. Gate with
mif-validate --level 1. See templates/good.md and templates/bad.md.
