The /to-prd Skill
Translates high-level business goals and customer problems into structured Product Requirements Documents with user stories, SMART acceptance criteria, and explicit non-goals.
"What is the condition? Can the condition be satisfied? Separate the various parts of the condition. Can you write them down?" — George Pólya, How to Solve It (1945)
/to-prd Draft PRD for team workspace invite flow, defining user stories, acceptance criteria, and non-goals.What it does
to-prd bridges commercial product strategy and engineering architecture. It translates user feedback, founder briefs, or discovery notes into a structured, unambiguous Product Requirements Document at docs/prd/{slug}-prd.md. It organizes requirements into standardized User Stories (US-XX), SMART Acceptance Criteria (AC-XX), target persona profiles, and explicit Out-of-Scope Non-Goals.
It focuses exclusively on What to build and Why, leaving technical data schemas, DTO models, and implementation mechanics to /to-spec. It writes zero code and authors exactly one canonical PRD markdown file.
When to reach for it
Where the work currently lives decides whether this is the right skill:
| The work is… | Reach for |
|---|---|
| A feature proposal needing clear business requirements and user stories | /to-prd |
| An approved PRD ready for technical contracts, ports, and DTO schemas | /to-spec @docs/prd/{slug}-prd.md |
| Internal infrastructure, refactoring, or CLI tooling (no end-user stories) | /to-spec directly (PRD optional bypass) |
| An ambiguous problem domain needing competitive research or spikes first | /to-explore |
Prerequisites
- Feature Brief or Problem Statement: High-level problem description or discovery notes from
docs/discovery/. - Domain Consistency: Adheres to canonical terminology defined in
CONTEXT.md. - Document-Only Scope: Strictly confined to authoring
docs/prd/{slug}-prd.md.
What one run does
A single PRD authoring run follows five structured steps:
- Context Ingestion & Persona Formulation: Identifies target users and establishes primary personas.
- User Story Definition: Formulates user stories formatted strictly as "As a [persona], I want [capability] so that [benefit]".
- SMART Acceptance Criteria: Defines boolean-verifiable criteria for each user story (
AC-XX). - Explicit Non-Goals: Clearly enumerates what will NOT be built to lock boundaries and prevent scope creep.
- PRD Persistence: Writes strictly one document to
docs/prd/{slug}-prd.mdand hands off to/to-spec.
Common questions
Is /to-prd mandatory for all features?
No. The PRD is an optional Phase 0.5. For backend optimizations, database migrations, developer tooling, or routine fixes where user-facing stories are irrelevant, you can bypass directly to /to-spec.
Why are Non-Goals so prominent in the PRD?
Unstated boundaries are the #1 cause of AI scope creep. Explicitly writing down what is out-of-scope prevents agents from adding speculative abstractions or unwanted features.
It's working if
- All user stories follow the persona-capability-benefit structure with numbered IDs (
US-XX). - Acceptance criteria are testable, measurable, and free of vague adjectives.
- It defines explicit out-of-scope Non-Goals.
- It authors strictly one PRD at
docs/prd/{slug}-prd.mdwithout creating duplicate copies.
Where it fits
to-prd is Phase 0.5 in the main idea-to-ship pipeline:
/to-explore → 📝 /to-prd → /to-spec → /to-clarify → /to-plan → 🛑 PAUSE → /to-code → /to-review → /to-docs
It receives discovery notes from /to-explore and produces the business foundation for /to-spec to formulate technical architecture.