Skill

prd-writer

Lightweight PRD (Product Requirements Document) writing guide for startups. Provides structured templates covering problem definition, hypothesis, success metrics, scope, and edge cases. Designed to be lean enough for fast iteration while comprehensive enough to align engineering and design teams.

From forged-claude-code

Install

Run in your terminal

npx claudepluginhub dokkabei97/forged-claude-code --plugin forged-claude-code

Tool Access

This skill uses the workspace's default tool permissions.

Skill Content

Similar Skills

cache-components

Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.

cache-components

138.6k

claude-opus-4-5-migration

2 files

Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.

claude-opus-4-5-migration

83.2k

evaluation-methodology

1 file

Details PluginEval's skill quality evaluation: 3 layers (static, LLM judge), 10 dimensions, rubrics, formulas, anti-patterns, badges. Use to interpret scores, improve triggering, calibrate thresholds.

plugin-eval

32.9k

Stats

Stars1

Forks0

Last CommitMar 1, 2026

Actions

View Source View Plugin View on GitHub View README

PRD Writer - Lightweight Product Requirements Document

Overview

Creates startup-appropriate PRDs — structured enough to align teams, lean enough to not slow you down. A good PRD answers "what and why", not "how".

1. When to Apply

Trigger	Behavior
New feature planning	Generate full PRD template
"write PRD", "feature spec"	Guided PRD creation workflow
Before sprint planning	Quick PRD for prioritized features

2. PRD Template

# PRD: [Feature Name]

> **Status**: Draft | In Review | Approved | In Development
> **Author**: [Name]
> **Date**: [YYYY-MM-DD]
> **Stakeholders**: [Names/Roles]

---

## 1. Problem Statement
[1-2 paragraphs. What problem are we solving? Who has this problem? How do they solve it today?]

**Evidence:**
- [User interview quote / data point / support ticket pattern]
- [Market research / competitor analysis finding]

## 2. Hypothesis
> If we [build X], then [target users] will [achieve Y],
> which we'll measure by [metric Z].

## 3. Success Metrics

| Metric | Current | Target | Measurement Method |
|--------|---------|--------|--------------------|
| Primary KPI | N/A or baseline | [target] | [how to measure] |
| Secondary KPI | N/A or baseline | [target] | [how to measure] |
| Guardrail Metric | [baseline] | [should not decrease] | [how to measure] |

## 4. Scope

### In Scope (MVP)
- [ ] [Core feature 1 — essential for value delivery]
- [ ] [Core feature 2 — essential for value delivery]
- [ ] [Core feature 3 — essential for value delivery]

### Out of Scope (Future)
- [Nice-to-have 1 — why deferred]
- [Nice-to-have 2 — why deferred]

### Non-Goals
- [What this feature explicitly will NOT do]

## 5. User Stories

### Primary Flow
> As a [user type], I want to [action], so that [benefit].

**Acceptance Criteria:**
- Given [context], when [action], then [result]
- Given [context], when [action], then [result]

### Secondary Flows
[Additional user stories as needed]

## 6. Design Considerations
- [UX principle or constraint]
- [Accessibility requirement]
- [Mobile/responsive considerations]

## 7. Technical Considerations
- [API changes needed]
- [Database schema impact]
- [Third-party integrations]
- [Performance requirements]

## 8. Edge Cases & Risks

| Edge Case | Expected Behavior |
|-----------|-------------------|
| [Edge case 1] | [How system should handle it] |
| [Edge case 2] | [How system should handle it] |

| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| [Risk 1] | H/M/L | H/M/L | [Plan] |

## 9. Timeline
- **Target Start**: [Date]
- **Target Ship**: [Date]
- **Estimated Effort**: [S/M/L or story points]

## 10. Open Questions
- [ ] [Question that needs answering before development]
- [ ] [Question that needs answering before development]

3. Writing Guidance

Problem Statement Tips

Lead with the user's pain, not your solution idea
Include at least one piece of evidence (data, quote, observation)
Avoid solutioning in the problem statement

Hypothesis Tips

Use the format: If/Then/Measured-by
Be specific enough that the hypothesis is falsifiable
One hypothesis per PRD (not a wishlist)

Scope Tips

Apply the "Would users pay for this alone?" test for MVP items
Everything else goes to Out of Scope
Non-Goals prevent scope creep ("this is NOT a...")

Metric Tips

Primary KPI: The ONE number this feature should move
Guardrail: Existing metric that should NOT get worse
Set targets BEFORE building, not after

4. PRD Complexity Levels

Level	When	Sections Required
Light (1-pager)	Small feature, <1 week effort	Problem, Hypothesis, Scope, Stories
Standard (2-3 pages)	Medium feature, 1-4 weeks	All sections
Detailed	Major initiative, cross-team	All sections + appendices

5. Tool Coordination

Tool	Purpose
Write	Generate PRD document
Read	Reference existing PRDs for consistency
Grep	Search codebase for related features
Glob	Find existing specs and documentation

6. Boundaries

Will:

Generate structured PRD templates at appropriate detail level
Guide users through each section with prompts and tips
Ensure hypothesis is falsifiable and metrics are measurable
Maintain consistent format across PRDs

Will Not:

Make product decisions for you (present options, not conclusions)
Write technical implementation details (that's engineering's job)
Replace user research with assumptions
Generate PRDs without understanding the problem first