to-prd — Generate PRD
- Trigger:
/to-prdor keywords "write PRD", "product requirements", "spec document" - Best for: Turning discussions into formal PRDs, documenting requirements
- Not for: Undiscussed requirements, purely technical implementation plans
Overview
to-prd turns the current conversation context into a structured Product Requirements Document and publishes it to the project issue tracker. It extracts requirements, constraints, and acceptance criteria from the discussion.
Trigger Conditions
to-prd auto-triggers when you:
- Mention "write a PRD", "create a spec"
- Need to document requirements after discussion
- Use the
/to-prdcommand
Examples
Example 1: Conversation to PRD
/to-prd Turn our discussion about the permission system into a PRDClaude generates a document with:
- Background and goals
- User stories
- Functional requirements (Must have / Should have / Nice to have)
- Non-functional requirements (performance, security, scalability)
- Acceptance criteria
- Technical constraints and dependencies
Example 2: Incremental Feature PRD
/to-prd Add "batch export" to the order system, supporting CSV and Excel formatsExample 3: Migration PRD
/to-prd Migration plan for splitting the payment module from monolith to microservicePRD Template
markdown
# [Feature Name] PRD
## Background
Why is this needed? What problem does it solve?
## Target Users
Who will use this?
## User Stories
- As a [role], I want [feature], so that [value]
## Functional Requirements
### Must Have
- [ ] Requirement 1
### Should Have
- [ ] Requirement 2
## Non-functional Requirements
- Performance: response time < 200ms
- Security: ...
## Acceptance Criteria
- Given / When / Then format
## Milestones
- M1: ...
- M2: ...Notes
- PRDs must be reviewed by a human — AI may miss business context
- Keep PRDs focused on "what" and "why", not premature "how"
- For cross-team projects, add "Stakeholders" and "Communication Plan" sections
- Verify labels and milestones in the issue tracker before publishing