prd（珠三角）

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.

1. Read context:

- If tasks/context.md exists, skim project gist, key decisions, and notes/gotchas. - Avoid conflicts with prior decisions.

1. 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.

1. Ask clarifying questions only when needed (numbered A/B/C/D options, up to ~7, answerable like 1A, 2C).
2. 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.

1. 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.

1. 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.

1. 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 ") 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).