prd-authoringlisted

# PRD Authoring — the source of truth The PRD is the root artifact every downstream stage derives from. Get it right and propagate from it. **Never jump to a plan or a solution from the PRD stage** (#1) — the PRD captures *what* and *why*, not *how*. ## Fits in the pipeline - **Stage 1** (`/prd`) — co-author the PRD from the objective, using the `brainstorming` skill. - **Stage 9** (`/change-request`) — EVERY change re-enters here first, then propagates downstream via `change-propagation`. Editing code before the PRD is a process violation. Owned by `product-manager`. ## Operating rules 1. **End-objective first.** Open by asking the single end objective: what does success look like for the user/business? Everything else hangs off this. 2. **Let the user dump everything.** Invite them to share anything and everything — context, constraints, half-formed ideas, references — before you structure anything. Capture freely into a scratchpad. Do NOT start planning, designing, or estimating yet. 3. **Reflect, then structure.** Once the dump is done, organize it into the PRD below, asking targeted questions only where a material gap exists. Present interpretations when ambiguous; don't pick silently. 4. **Modular by default.** Frame requirements so the system decomposes into self-contained modules, dynamically linked, where an upgrade in one propagates to dependents. This framing carries into `platform-blueprint` (Stage 1/3) and `module-architecture` (Stage 4)