prd

Create, update, or list PRDs. Each PRD is a self-contained feature spec with status and priority.

Guardrails

• Do not implement code.
• Keep features "PRD-sized": one feature = one PRD.
• Split the feature if it spans >2 subsystems, >1 UI surface + backend, or >~1 day of work.
• Prefer asking a small number of high-value questions; otherwise write a draft PRD with explicit assumptions.
• Write the PRD so a junior dev (or another AI) can implement it without extra context.
• Use plain language, explicit edge cases, and verifiable acceptance criteria.
• Do not use Markdown tables (use checklists + bullets).
• When asking users for decisions, always provide numbered options with low-keystroke reply formats.
• Treat context capture as built-in.
• If durable decisions are made, update tasks/context.md in this step.
• Do not defer to a separate context pass.

Modes

• Create / update (default): write or revise a single PRD.
• List: scan tasks/ for active (non-archived) PRDs and display a summary of feature ID, name, status, and priority. No file modifications.

Workflow — Create / Update

1. Determine intent:
   • New project (no tasks/context.md or empty): ask project-definition questions, initialise tasks/context.md with project gist, then write the first PRD.
   • New PRD (project exists): proceed to PRD creation.
   • Update existing PRD: locate the existing PRD file and edit in place.
2. Read context:
   • If tasks/context.md exists, skim project gist, key decisions, and notes/gotchas.
   • Avoid conflicts with prior decisions.
3. Assign feature ID:
   • Scan existing PRD files in tasks/ and tasks/archive/ for the highest f-## number.
   • New PRD gets (max existing f-##) + 1.
   • For updates, preserve the existing ID.
4. Ask clarifying questions only when needed (numbered A/B/C/D options, up to ~7, answerable like 1A, 2C).
5. Determine PRD file path:
   • Look for an existing active PRD matching the feature ID in tasks/ (tasks/f-##-*.md).
   • If found, use it (update in place).
   • Otherwise use tasks/f-##-<feature-slug>.md.
6. Write or update the PRD at the chosen path using references/prd-template.md:
   • Set Status: and Priority: in the Summary section.
   • For new PRDs, default Status: draft. Prompt the user to confirm ready when scope is locked.
   • Priority: uses P0 (critical), P1 (high), P2 (medium), P3 (low).
   • Ensure implementation progress is trackable via checklist items.
   • For UI/UX-heavy features, include expected design inputs and state whether design should run before implement.
7. Update context:
   • Update project gist in tasks/context.md if this is the first PRD or project scope changed.
   • Capture any durable decisions or constraints.
8. Reply with updated file paths and a short change summary.

Workflow — List

1. Scan tasks/ for files matching f-##-*.md (exclude tasks/archive/).
2. For each file, extract from the Summary section: Feature ID, name, Type, Status, Priority.
3. Display sorted by priority (P0 first), then by feature ID.
4. Suggest the highest-priority Status: ready PRD as the next candidate for implement.
5. No file modifications in list mode.

Clarifying Questions (Only If Needed)

Ask up to ~7 high-value questions. Keep them answerable via 1A, 2C, 3B.

Focus on ambiguity around:

• target user + primary use case
• the problem + desired outcome
• constraints (platforms, timeline, integrations)
• success metrics / how we know it worked
• scope boundaries (what's explicitly in vs out)
• whether this is Type: feat vs fix vs chore
• priority (P0 / P1 / P2 / P3)
• dependencies between features (by ID)

Example question format

1. What are we building?
   A. A brand new feature
   B. A fix for existing behaviour
   C. A maintenance/chore item
   D. Other: [describe]

Feature Writing Guidelines

• Prefer feature names as verb phrases (e.g., "Invite teammates", "Export CSV").
• For fix items, name them clearly (e.g., "Fix <problem>") and set Type: fix. Include minimal bug info:
  • Current behaviour: …
  • Expected behaviour: …
  • Repro steps (if known): …
• For chores, keep them crisp and outcome-oriented (e.g., "Chore: remove dead code") and set Type: chore.
• Ensure each feature has a crisp outcome (what changes for the user).
• Avoid implementation tasks ("refactor", "set up DB") unless they are truly user-facing requirements.
• If a feature is too large, split by user goal or workflow step until each item could reasonably become a single PRD.

Update Rules (When a PRD Exists)

• If a PRD already exists at that path, update it in place.
• Do not create a duplicate PRD unless the user asks.
• Do not reset existing checklist items inside the PRD.
• Preserve existing Status: and Priority: unless the user explicitly asks to change them.
• Keep feature IDs stable; IDs must be globally unique across tasks/ and tasks/archive/.
• When adding a new feature, use the next ID as (max existing f-##) + 1 (never reuse old IDs).

PRD Template

Use references/prd-template.md as the default PRD template and checklist.

• Read it before drafting a new PRD.
• For updates to an existing PRD, edit only impacted sections and preserve existing checkbox state.
• Keep acceptance criteria concrete and verifiable; examples are in the reference file.

Output

• Create or reuse tasks/.
• Save/update the PRD at the chosen path.
• Update tasks/context.md when durable decisions or project scope changes warrant it.
• For UI/UX-heavy PRDs, recommend design (optional) before implement.
• Suggest the next action:
  • If Status: draft, suggest refining to ready.
  • If Status: ready, suggest implement.
• End with a short status block:
  • Files changed: list of created/updated files
  • Key decisions: any assumptions or choices made (if any)
  • Next step: recommended next skill or action

Quality Checklist

Before saving:

• PRD Summary includes Feature ID, Type, Status, and Priority.
• Feature ID is unique and stable (checked against existing PRDs in tasks/ and tasks/archive/).
• If updating an existing PRD, existing story/task checkboxes were preserved (not reset).
• If a PRD already existed, it was updated in place (no duplicates).
• Each feature has a user-visible outcome and explicit scope boundaries (goals + non-goals).
• Dependencies reference valid feature IDs.
• Acceptance criteria are concrete and verifiable.
• PRD is consistent with tasks/context.md (or tasks/context.md was updated in this run).