---
name: project-prd
description: Use when writing or reviewing a project-agnostic PRD from brainstorm notes, user requirements, research findings, or existing repo context. Enforces PRD IDs and source mappings.
---

# Project PRD

Use this skill to create or review a PRD with stable requirement IDs.

## Rules

- Create or update the canonical `.prd_plugin/state/artifacts/prd/<artifact-id>.json`.
- Generate Markdown only on explicit human request.
- Every `PRD-REQ-*` should cite at least one source, usually `BR-REQ-*`.
- Separate functional requirements from non-functional requirements.
- Include acceptance criteria with `PRD-ACC-*` IDs.
- Mark open questions explicitly rather than hiding ambiguity.
- Route unproven or experimental requirement changes through a `DBR-*`
  document branch instead of changing mainline PRD truth.
- When a PRD creates or closes active project work, update or propose
  `.prd_plugin/state/tracking.json` records using `TRK-*`.
- When a PRD materially changes project direction, update or propose a
  `.prd_plugin/state/changelog.json` entry using `CHG-*`.
- Do not promote PRD-derived memory into `MEM-*` without source references and
  `AGENT-*` / `SES-*` provenance.
- Create or update `HLT-*` health findings when PRD requirements are orphaned,
  ambiguous, or missing testable acceptance criteria.
- Link accepted `REQ-*` records when a PRD incorporates request-intake work.

## Staleness Coverage

Apply the shared policy in `.prd_plugin/method/staleness-rules.md`.


Before changing mainline PRD truth, review existing open or stale `HLT-*`,
`TRK-*`, `REQ-*`, and `DBR-*` records that reference the affected requirements.
Resolve, refresh, or explicitly leave stale findings open with a reason.

## Canonical Format

JSON/JSONL is canonical for planning artifacts. Keep the PRD JSON compact:
stable requirement IDs, short summaries, source IDs, acceptance IDs, open
questions, stale follow-ups, and traceability links. Markdown exports are human
snapshots only and must not be edited as project truth.

## Required Sections

1. Artifact metadata
2. Agent summary
3. Goals
4. Non-goals
5. Requirements
6. Non-functional requirements
7. Acceptance criteria
8. Dependencies
9. Open questions
10. Traceability links
11. State updates, if applicable

## Review Checklist

- No orphan must-have requirement without source.
- No implementation detail masquerading as a product requirement unless it is a real constraint.
- Acceptance criteria are testable.
- Open questions are visible.
- Proposed changes from document branches are promoted only after evidence and a
  merge decision.
- Any `TRK-*` or `CHG-*` updates cite the relevant `PRD-*` IDs and session
  provenance.
- Relevant `HLT-*` findings are created, resolved, or left open with a reason.
- Accepted `REQ-*` records that affect the PRD are linked or graduated.

## Parallel Worker State Boundary

When `tracking.branching.require_for_parallel_agents` is true, a parallel worker
is launched with `PRD_WORKER_SESSION=1`, `PRD_TRACKING_BRANCH_ID=<DBR-*>`, and
`PRD_TRACKING_BRANCH_OWNER=<owner>`. It calls only
`prd_update_tracking_branch` on that assigned branch. It records proposed PRD,
`TRK-*`, `CHG-*`, and other canonical state changes as branch notes; the lead
applies them serially after merge and calls `prd_promote_tracking_branch`.
Workers never edit canonical state or `.prd_plugin/ids/registry.json` directly.