to-prdlisted

# To PRD A PRD is not a frozen memo — it is one RST document in the spec: a single *feature* need carrying the prose (motivation, scope, non-goals) plus child *requirement* needs linked back to it (ADR_0010). This is true regardless of the issue backend; `/to-issues` handles slicing later. ## Workflow ### 1. Resolve configuration Read `[tool.patdhlk-skills]` from `ubproject.toml` (repo root, then `spec*/`, `docs/`): `spec_dir`, `builder`, and the role map. The roles `feature` and `requirement` must be mapped — if the table or either role is missing, stop and tell the user to run `/setup-patdhlk-skills` first. Below, `feat`/`req` mean *whatever directives the role map names*. ### 2. Synthesize, then confirm Draft the PRD from the conversation: title, motivation, scope, non-goals, and 3–10 requirements. Each requirement is **one testable shall-statement** — split anything with an "and" joining two behaviors; park open questions in the prose, not in requirements. Present the outline (title + requirement one-liners) and get the user's go-ahead **before** touching files. ### 3. Allocate IDs Build a fresh needs.json — never grep RST, never cache (ADR_0006): ```bash pds build # fresh needs.json at <spec_dir>/_build/needs/needs.json # no pds: ubc build needs --outpath <spec_dir>/_build/needs/needs.json # (or uv run sphinx-build -b needs <spec_dir> <spec_dir>/_build/needs) ``` Take the highest numeric suffix per prefix and allocate dense max+1 (ADR_0008), reading e