Product Requirement Document Authoring

Use this capability whenever you draft or review a product requirement document, feature spec, plan document, or issue description — the parts that describe what is needed and how completion is verified, not how it is built. It is general-purpose and self-contained: any requirement, spec, RFC, or plan benefits from it, regardless of the codebase, stack, or delivery workflow it feeds.

This skill owns one canonical document structure, in this order. Required sections appear in every document; conditional sections are included when their trigger applies and omitted only with a one-line stated reason, never dropped silently.

1. Summary (required) — one standalone paragraph.
2. Todo (required) — a static, actionable list of the deliverables or change surfaces.
3. Background (required) — with an Assumptions subsection.
4. Goals and Non-goals (required) — one section, standardly a flat list whose opening verbs distinguish intended outcomes from deliberate exclusions.
5. Functional requirements (conditional) — with UI design (conditional) and System design (conditional, carrying Alternatives considered when a plausible competing approach exists) nested under it.
6. Non-functional requirements (conditional).
7. Acceptance criteria (required).
8. Verification strategy (required).
9. Open questions (required, may be "None").

This skill deliberately does not own everything a spec touches. It owns the document structure, problem framing, scope boundaries, requirement and criteria craft, and the spec-level framing of the UI design and System design sections — how to describe what a change must do and how it is verified. It does not own the implementation mechanics behind those descriptions: