to-prd

name	to-prd
description	Turn the current conversation context into a Product Requirements Document. Use after a /grill session when the plan is clear, when the user asks to formalize a feature discussion, or before breaking work into issues with /to-issues. Does NOT conduct an interview — synthesizes what's already discussed.
argument-hint	[feature name or description]

Create PRD

"If you can't describe what you're building in writing, you don't understand it yet."

Philosophy

This skill synthesizes, not interviews. It turns conversation context into a structured PRD. If information is missing, note it as an open question — don't ask new questions. Use /grill first if you need to align on requirements.

Workflow

Step 1: Synthesize the Conversation

Extract from conversation history:

• The core problem being solved
• The proposed solution
• Key decisions and their rationale
• Constraints and non-goals
• Success criteria

Step 2: Write the PRD

# PRD: [Feature Name]

## Problem
[What problem? For whom? Why now?]

## Solution
[What are we building? High-level approach.]

## User Stories
- As a [role], I want to [action], so that [benefit]

## Requirements

### Must Have
- [Requirement]

### Should Have
- [Requirement]

### Nice to Have
- [Requirement]

## Non-Goals
[What we're explicitly NOT building. As important as what we are.]

## Technical Approach
[High-level design. Affected modules. Key interfaces. Data model.]

### Modules Affected
- [Module A]: [what changes]
- [Module B]: [what changes]

## Success Criteria
- [ ] [Measurable criterion]
- [ ] [Measurable criterion]

## Open Questions
- [Question]

## Out of Scope
- [Excluded items]

Step 3: Validate

• Does the PRD address the original problem? (Alignment)
• Is the solution the simplest that works? (Simplicity)
• Are success criteria objectively verifiable? (Goal-Driven)
• Are affected modules identified? (Surgical Changes)

Step 4: Submit

Submit as a GitHub Issue with prd label (if applicable).

Anti-Patterns

• Scope creep — Don't add requirements that weren't discussed
• Vague criteria — "Make it fast" → "Page load under 2 seconds"
• Missing non-goals — What you're NOT building matters as much as what you are

Integration

• Use /grill before /to-prd to align on requirements
• Use /to-issues after /to-prd to break into grabbable issues
• Use /zoom-out during /to-prd to identify affected modules