prd-authorlisted

# PRD authoring Produce or update `docs/PRD.md` — the product intent of record. The PRD is the WHAT and WHY. It contains no HOW: no architecture, no tech choices, no implementation detail (those belong in a TDD). Keep it the WHAT. The HOW is `/tdd-author`'s job. Do not start designing. Run this in its own session. If `docs/PRD.md` already exists you are UPDATING it — read it first and preserve requirements still valid; note what changed. ## Relationship to superpowers (read first) This skill IS the design/requirements step for throughline — it is the governance-producing equivalent of `superpowers:brainstorming`. When the user invokes `/prd-author`, do NOT also invoke `superpowers:brainstorming` or `writing-plans`; this skill owns the phase and its output is the PRD of record (see [[ADR 0001]] in `docs/adr/`). But do not redo discovery that already happened: if a `docs/superpowers/specs/*` (or `plans/*`) file or other prior design notes exist, READ them and fold their substance into the PRD instead of re-interviewing from scratch. Treat `docs/superpowers/*` as transient input — never authoritative, never relocated. The canonical record is `docs/PRD.md`. ## Process > Tip: this phase is an interactive interview — consider toggling `/fast` for > snappier back-and-forth. Fast mode keeps Opus, just with faster output, so it > suits requirements/design conversation without trading quality. 1. Explore the problem space. Establish what exists, who the users are, and what suc