product-requirement-guidelines

name	product-requirement-guidelines
description	How to write a product requirement, feature spec, or issue description. Covers framing the problem/outcome before the solution, separating "what" from "how", explicit non-goals and assumptions, right-sizing scope to the change, testable acceptance criteria, and — for view-affected or architecturally broad changes — framing a spec's UI-design and system-design/architecture sections.
when_to_use	Apply when writing, refining, or reviewing a requirement or spec, including any plan-writing or issue-drafting step of a delivery workflow — "write a PRD", "refine this issue", "write acceptance criteria", "what's the scope of this change", "is this requirement testable", or "does this need a UI design / architecture section".
user-invocable	false

Product Requirement Guidelines

Apply this skill whenever drafting or reviewing the parts of a product requirement, feature spec, or issue description that describe what is needed and how completion is verified — not how it is built. It is general-purpose: any product requirement, feature specification, or issue description benefits from it, not only a delivery workflow's plan-writing step.

This skill deliberately does not own everything a spec contains. It owns problem framing, scope boundaries, acceptance-criteria craft, and — when those sections are warranted — the spec-level framing of the UI design and system-design/architecture sections. It does not own the implementation mechanics behind them:

• UI component structure, CSS, and markup mechanics — the project's own UI/component skill (created during INIT). This skill owns only how to describe hierarchy, states, accessibility, and responsive intent in the spec (see below).
• Actual data flow implementation, routes, and module placement — the project's own structure skill (created during INIT). This skill owns only how to describe system-design decisions in the spec (see below).
• Test coverage strategy — the project's end-to-end testing and unit-test guidelines.

Problem Framing and Scope

See problem-and-scope.md for:

• stating the user-facing outcome and problem before any solution detail
• writing explicit non-goals and out-of-scope bullets
• separating stated assumptions from open questions
• right-sizing the section to the size of the change
• replacing vague quality adjectives with concrete, checkable statements

Acceptance Criteria Craft

See acceptance-criteria.md for:

• writing criteria a reviewer can verify independently, without reading implementation code
• preferring concrete, checkable phrasing over adjectives
• covering the happy path, edge/error/empty states, and explicit non-effects
• right-sizing the checklist and including verification-gate criteria
• tracing every criterion back to the rest of the spec

UI Design Section Framing

See ui-design-framing.md for:

• when a spec needs a UI design section at all (view-affected changes only) and at what fidelity
• describing hierarchy and layout intent in spec terms, not implementation
• enumerating interaction states (default, disabled, loading, error, empty)
• stating accessibility intent as testable, WCAG-referencing criteria
• stating responsive behavior intent and copy/microcopy constraints

Architecture Overview Framing

See architecture-overview-framing.md for:

• when a spec needs a system-design/architecture section at all (broad or hard-to-reverse changes only)
• describing data flow and module boundaries at spec level, not implementation
• recording alternatives considered and why they were rejected
• stating constraints and non-functional requirements as measurable targets

Product Requirement Section Template

See template.md for:

• a self-contained, annotated Markdown skeleton for the Product requirement and Acceptance criteria sections
• what belongs in each slot (problem/outcome, scope, non-goals, assumptions/constraints, checklist)