Skip to content

to-prd — Generate PRD

  • Trigger: /to-prd or 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-prd command

Examples

Example 1: Conversation to PRD

/to-prd Turn our discussion about the permission system into a PRD

Claude 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 formats

Example 3: Migration PRD

/to-prd Migration plan for splitting the payment module from monolith to microservice

PRD 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
  • to-issues — Break PRD into dev tasks after completion
  • grill-me — Get grilled before writing PRD to ensure completeness
  • triage — Prioritize existing PRDs