---
name: new-prd
description: Walk the user through creating a new Product Requirements Document section-by-section using the global template, then save to docs/prd/YYYY-MM-{slug}.md and recommend Walter's audit.
---

# New PRD

Guided creation of a Product Requirements Document. The goal is a complete,
testable PRD that Walter (the spec auditor in the global team) will approve
on first pass.

## Source template

Base everything on `~/.claude/templates/prd.md`. Do not re-derive structure —
copy the template and fill it in.

## How this skill works

Ask **one question at a time**. Wait for the answer before continuing. If the
user gives a half-answer, push back: a vague PRD now is a costly rewrite later.

Do not pre-fill placeholder values. Better to leave a section blank with a
note than to invent content the user hasn't approved.

## Questions, in order

1. **Slug.** Short kebab-case name for the feature (e.g. `rate-limiting`,
   `user-export`). Used in the filename.

2. **Ticket reference.** Is there a TaskHerder ticket already? If yes, capture
   the number. If no, note that one should be created and linked after the
   PRD is approved.

3. **Problem.** What pain are we solving, and what's the evidence? Push for
   concrete signals: usage data, support tickets, user quotes, a specific
   incident. Reject "we should improve X" with no evidence.

4. **Users.** Who is this for? Name them. If the audience is internal (e.g.
   Dialogs CMS editors), say so. Personas help when relevant.

5. **Success criteria.** Measurable outcomes. Push hard here — "users will
   like it" is not a success criterion. "p50 page-build time drops below
   400ms within two weeks of rollout" is.

6. **Constraints.** Hard limits: existing schema we can't change, deploy
   window, dependency on a third-party API, regulatory requirement, etc.

7. **Out of scope.** What this PRD explicitly does NOT cover. If the user
   gives an empty list, prompt with the obvious adjacent areas to confirm.
   An empty out-of-scope is almost always wrong.

8. **Open questions.** Anything unresolved. Each must have a **named owner**.
   An unowned open question becomes a blocker for Walter's audit.

9. **Acceptance criteria.** Testable Given/When/Then or "this is done when…"
   statements. Each must name the verification artifact (test file path,
   manual QA step, or metric+threshold). Push back on vague ACs ("works
   correctly", "is fast", "is robust") — see the memory `feedback-prd-writing`
   for paired examples of good vs. vague.

10. **Verification mapping.** For each acceptance criterion from step 9, name
    the test file path or manual QA step. If the test doesn't exist yet, name
    what it will be called. Build the verification table.

11. **Rollout.** Feature flag? Phased? Migration? Backfill? Anything
    operational that needs to happen the day this ships.

## Output

Write the result to `docs/prd/YYYY-MM-{slug}.md` (today's date + slug from
question 1). Use `~/.claude/templates/prd.md` as the structural base. Fill
in the metadata block (Date = today, Status = `draft`, Owner = git config
user.name, Ticket = from question 2).

If the `docs/prd/` directory doesn't exist, create it.

## After saving

Tell the user:
- The file path that was created
- That Walter should audit it before coding starts: `/audit-prd <path>`
- The TaskHerder ticket should reference this PRD path in its description

## Quality bar (the rule)

Every acceptance criterion names the artifact that proves it — a test file
path, a manual QA step, or a metric+threshold. If you can't name the artifact,
the criterion isn't done — it's a wish. Refuse to save the PRD if any AC
doesn't meet this rule.