product-spec

Purpose

Writes a product requirements document with the user: problem, goals, non-goals, user stories, numbered requirements, measurable success metrics and open questions, with every claim marked as fact, assumption or decision.

Source Skill purpose

When to use it

Use product-spec when a product idea needs a PRD before being split into implementation tasks. It writes the problem and affected users, goals, non-goals, stories with observable criteria, functional and nonfunctional requirements, measurable success metrics, assumptions and open questions. Every claim is a marked fact, assumption or decision with its source or decider. Unknowns do not become asserted product facts. A deterministic checker validates the draft, its review and the eventual requirement-to-task trace before approval and splitting.

A user story's acceptance criterion names a situation and an observable outcome. Metrics explain how success will be measured, while blocking open questions remain separate from resolved requirements. Task splitting happens only after readiness checks confirm the PRD and review result.

Source Skill purpose

How it works

Steps of the skill, in source order

Source Flow

Choose draft folder Use the product slug and keep the PRD draft outside the final folder.
Source Flow
Ask about the problem Resolve users, goals, non-goals and success through ordered questions.
Source Flow
Gather approved facts Read user-named sources and give each sourced fact an id.
Source Flow
Draft the PRD Write stories, requirements, metrics and blocking questions in the template.
Source Flow
Check the draft Run the PRD checker and repair every reported issue.
Source Flow
Approve the document Show the checked PRD and write it to the product folder after approval.
Source Flow
Review the spec Record a spec-review verdict and any conditions in the review file.
Source Flow
Split requirements Check readiness, then turn covered requirements into tasks with trace links.
Source Flow

Key rules

Derive every statement from the user or a named source.
Source Hard rules
Mark each claim as fact, assumption or decision, with one source of authority.
Source Hard rules
Make criteria and success metrics observable and measurable.
Source Hard rules
Keep non-goals explicit rather than leaving them empty.
Source Hard rules
Show a PRD for approval only after its checker succeeds.
Source Hard rules

Output and gate

Output

Report the PRD path, check result, open questions and task-trace status.
Source Output

Gate

The skill definition states no gate rule.

Source Skill definition

Source