Skill

write-prd

Create a Product Requirements Document from a feature idea or mission.

npx claudepluginhub choam2426/geas

Tool Access

This skill uses the workspace's default tool permissions.

Preview

Create a structured Product Requirements Document.

SKILL.md

Similar Skills

prd

Generates a concise 1-2 page structured PRD from product ideas or feature descriptions, resolving ambiguities and enforcing decisions for engineering teams.

2 tools

claude-code-pm-skills

prd

Generates structured Product Requirements Documents (PRDs) by gathering project context from files and commits, asking 3-5 clarifying questions with lettered options, and producing sections like user stories, functional requirements, non-goals, and success metrics.

2 files

toby-essentials

prd

12.8k

Generates Product Requirements Documents (PRDs) for features via clarifying questions on goals, users, and scope. Structures into user stories, requirements; saves to tasks/prd-[feature].md.

ralph-skills

Stats

Parent Repo Stars4

Parent Repo Forks2

Last CommitApr 6, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Write PRD

Create a structured Product Requirements Document.

Input

$ARGUMENTS — a feature idea, problem statement, or mission.

Output Format

# PRD: <product/feature name> ## Problem What problem are we solving? Who has this problem? How do they deal with it today? ## Objective What does success look like? Define 2-3 measurable outcomes. ## Target Users Who is the primary user? What are their characteristics and needs? ## Scope ### In Scope - Feature 1 - Feature 2 ### Out of Scope - Feature X (why: too complex for initial release) - Feature Y (why: not validated) ## User Flows Describe the key user journeys step by step. ## Requirements ### Functional | # | Requirement | Priority | Notes | |---|-------------|----------|-------| | 1 | ... | P0 | ... | ### Non-Functional - Performance: ... - Accessibility: ... - Security: ... ## Success Metrics How will we measure if this is working? ## Open Questions What do we still need to figure out?

Guidelines

Keep it concise — a PRD is a communication tool, not a novel

Focus on the "what" and "why", not the "how" (that's for the engineers)

Every requirement should trace back to a user need

Be explicit about what's out of scope — this prevents scope creep

Write PRD

Create a structured Product Requirements Document.

Input

$ARGUMENTS — a feature idea, problem statement, or mission.

Output Format

# PRD: <product/feature name>

## Problem
What problem are we solving? Who has this problem? How do they deal with it today?

## Objective
What does success look like? Define 2-3 measurable outcomes.

## Target Users
Who is the primary user? What are their characteristics and needs?

## Scope

### In Scope
- Feature 1
- Feature 2

### Out of Scope
- Feature X (why: too complex for initial release)
- Feature Y (why: not validated)

## User Flows
Describe the key user journeys step by step.

## Requirements

### Functional
| # | Requirement | Priority | Notes |
|---|-------------|----------|-------|
| 1 | ... | P0 | ... |

### Non-Functional
- Performance: ...
- Accessibility: ...
- Security: ...

## Success Metrics
How will we measure if this is working?

## Open Questions
What do we still need to figure out?

Guidelines

Keep it concise — a PRD is a communication tool, not a novel
Focus on the "what" and "why", not the "how" (that's for the engineers)
Every requirement should trace back to a user need
Be explicit about what's out of scope — this prevents scope creep