← ClaudeAtlas

prdlisted

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.
modeled-information-format/mif-docs-plugin · ★ 0 · Web & Frontend · score 69
Install: claude install-skill modeled-information-format/mif-docs-plugin
# 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 1. **Problem Statement** — lead with the user/business problem and its evidence. Never open with the solution. 2. **Goals & Success Metrics** — measurable outcomes (e.g. "reduce checkout abandonment from 30% to 20%"). 3. **Users / Personas** — who is affected and their context. 4. **Requirements** — the functional needs. Express testable ones as **EARS** criteria (see the `ears-acceptance-criteria` skill). 5. **Scope & Non-Goals** — explicitly what's out, to prevent scope creep. 6. **Milestones** — rough sequencing. 7. **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`.