Ready to supercharge your AI agents?

Install any skill in seconds. Free to start, no credit card required.

PRD Writer · vibeeval | DecimalAI

Prd Writer

SkillScore91Maintained

prd-writer

Product Requirements Document writing - PRD templates, MoSCoW prioritization, user personas, competitive analysis, feature specs, acceptance criteria, risk assessment

Documentationby vibeeval

Links this skill to your agents and keeps it current with the author’s updates.

Automatic

Product Management pack

1 · One-time — install the CLI (docs ↗)

pip install decimalai

2 · Get the skill — writes .claude/skills/prd-writer/SKILL.md

decimalai skills pull prd-writer --out .claude/skills/

No CLI? Get the same file — curl · raw file

curl -fsSL --create-dirs -o .claude/skills/prd-writer/SKILL.md https://app.decimal.ai/s/prd-writer/SKILL.md

Raw file: /s/prd-writer/SKILL.md ↗ · machine-readable summary at /s/prd-writer.json ↗

In productionGlobal

how this skill behaves on real traffic · last 30 days

No production data for this skill yet — usage numbers appear here once agents start running it.

Anonymized aggregate across every org using this skill — proof from real production use, not a demo.

Does this skill help? · Benchmark: with vs. withoutsign in to run this on your agents

22 test cases from the publisher’s eval.yaml · each run twice on gemini-3.6-flash — with the skill injected, then without · last run 51d ago

Yes — +50% lift · at higher cost+106% tokens0% turns91% of whole cases pass with skill (20/22)

Test case	Without → With	Effect	Δ tokens	Δ turns
case-01	✗→✓	▲ Improved	50%	0%
case-07	✗→✓	▲ Improved	97%	0%
case-08	✗→✓	▲ Improved	105%	0%
case-09	✗→✓	▲ Improved	63%	0%
case-11	✗→✓	▲ Improved	135%	0%

Showing 5 of 22 cases

SkillSafety

✓ 3 of 3 passed

Code scan15 of 15 checks clean

0 critical · 0 warning · 0 info — scanner v4 — 8/1/2026

live_secretremote_code_executionreverse_shelldata_exfiltrationssrf_metadataagent_snoopinganti_refusaldestructive_commandsobfuscated_unicodeunicode_homoglyphopaque_blobsuspicious_urltool_overreachtrigger_abuseprompt_injection_phrasing

IntentSafe

LLM judge · does the skill do what it claims

ContentClean

LLM judge · policy & harmful-content review

Source

Imported

vibeeval / vibecosystem

skills/prd-writer/SKILL.md

View on GitHub ↗

License MITImported 8/1/2026Version v2

Skill contents

SKILL.md

PRD Writer

PRD Template

markdown
# Product Requirements Document

## Meta
| Field | Value |
|-------|-------|
| Product | [urun adi] |
| Author | [yazar] |
| Version | [v1.0] |
| Status | [Draft / In Review / Approved] |
| Last Updated | [tarih] |
| Stakeholders | [paydas listesi] |

---

## 1. Problem Statement

### The Problem
[Kullanicilarin yasadigi sorunu 2-3 cumle ile acikla]

### Who is Affected
[Etkilenen kullanici segmenti ve buyuklugu]

### Current Solutions
[Mevcut cozumler ve neden yetersiz oldugu]

### Evidence
- [Veri noktasi 1: kullanici arastirmasi, anket, metrik]
- [Veri noktasi 2]
- [Veri noktasi 3]

---

## 2. Goals & Success Metrics

### Goals
| Goal | Description | Metric | Target |
|------|-------------|--------|--------|
| G1 | [birincil hedef] | [olcum] | [hedef deger] |
| G2 | [ikincil hedef] | [olcum] | [hedef deger] |

### Non-Goals (Out of Scope)
- [Bu PRD kapsaminda OLMAYAN seyler]
- [Gelecek iterasyona birakilanlar]

### Success Metrics
| Metric | Current | Target | Measurement |
|--------|---------|--------|-------------|
| [KPI 1] | [mevcut] | [hedef] | [nasil olculecek] |
| [KPI 2] | [mevcut] | [hedef] | [nasil olculecek] |

---

## 3. User Personas

[Asagidaki Persona Template'i kullan]

---

## 4. User Stories

[Epic → Story → Acceptance Criteria hiyerarsisi]

---

## 5. Requirements

### Functional Requirements

| ID | Requirement | Priority | Notes |
|----|------------|----------|-------|
| FR-1 | [gereksinim] | Must | [detay] |
| FR-2 | [gereksinim] | Should | [detay] |

### Non-Functional Requirements

| ID | Category | Requirement | Target |
|----|----------|------------|--------|
| NFR-1 | Performance | Page load time | < 2s |
| NFR-2 | Scalability | Concurrent users | 10,000 |
| NFR-3 | Availability | Uptime SLA | 99.9% |
| NFR-4 | Security | Data encryption | AES-256 |

---

## 6. Design & UX

### User Flows
[Temel kullanici akislari - diyagram veya adim listesi]

### Wireframes
[Link veya embed]

### Edge Cases
| Scenario | Expected Behavior |
|----------|-------------------|
| [durum 1] | [beklenen davranis] |
| [durum 2] | [beklenen davranis] |

---

## 7. Technical Considerations

### Architecture
[Mimari yaklasim ve entegrasyonlar]

### Dependencies
| Dependency | Type | Risk | Mitigation |
|-----------|------|------|------------|
| [dep 1] | External API | Medium | Fallback mechanism |
| [dep 2] | Internal service | Low | Already available |

### Migration / Backward Compatibility
[Mevcut sistemle uyumluluk plani]

---

## 8. Timeline & Milestones

| Phase | Milestone | Duration | Target Date |
|-------|-----------|----------|-------------|
| Phase 1 | MVP | [sure] | [tarih] |
| Phase 2 | Beta | [sure] | [tarih] |
| Phase 3 | GA | [sure] | [tarih] |

---

## 9. Risks & Mitigations

[Asagidaki Risk Assessment framework'unu kullan]

---

## 10. Open Questions

| # | Question | Owner | Status |
|---|----------|-------|--------|
| 1 | [soru] | [kisi] | Open |
| 2 | [soru] | [kisi] | Resolved: [cevap] |

MoSCoW Prioritization

Framework

| Category | Definition | Guideline | |----------|-----------|-----------| | Must | Critical, non-negotiable | Launch blocker - no release without it | | Should | Important but not critical | Expected by users, can workaround temporarily | | Could | Nice to have | Enhances experience, not core | | Won't | Out of scope (this iteration) | Documented for future consideration |

Prioritization Matrix

markdown
## Feature Prioritization

| Feature | Impact (1-5) | Effort (1-5) | Risk (1-5) | Priority |
|---------|-------------|-------------|-----------|----------|
| [F1] | 5 | 2 | 1 | Must |
| [F2] | 4 | 3 | 2 | Should |
| [F3] | 3 | 4 | 3 | Could |
| [F4] | 2 | 5 | 4 | Won't |

### Scoring Rules
- Impact: Business/user value (5 = critical)
- Effort: Dev time and complexity (5 = very hard)
- Risk: Technical/business uncertainty (5 = very risky)
- Priority = High Impact + Low Effort + Low Risk = Must

User Persona Template

markdown
## Persona: [Isim]

**Photo:** [placeholder]
**Role:** [is unvani / kullanici tipi]
**Age:** [yas araligi]
**Tech Savvy:** [Low / Medium / High]

### Background
[2-3 cumle: kim, ne yapiyor, nerede calisiyor]

### Goals
1. [birincil hedef - isini kolaylastiran]
2. [ikincil hedef - uzun vadeli]
3. [ucuncul hedef - kisilsel]

### Pain Points
1. [en buyuk sorun - gunluk frustration]
2. [ikinci sorun]
3. [ucuncu sorun]

### Behaviors
- [nasil bilgi arar]
- [hangi araclari kullanir]
- [ne siklikta etkilesin]

### Motivations
- [ne motive eder]
- [ne icin para oder]

### Quote
> "[Persona'nin tipik bir sozu - empati kurmak icin]"

### Scenario
[Tipik bir gun: urunu ne zaman, nasil, neden kullanir]

Persona Anti-Patterns

| Anti-Pattern | Neden Yanlis | Dogru Yol | |-------------|-------------|-----------| | Too many personas (5+) | Odak kaybeder | 2-3 primary persona | | Vague demographics only | Actionable degil | Behavior + motivation ekle | | No pain points | Cozum odakli olamaz | Gercek kullanici arastirmasindan cikar | | Fictional without data | Yaniltici | Interview/survey veriyle destekle |

Competitive Analysis Framework

markdown
## Competitive Analysis

### Market Landscape

| Competitor | Market Share | Target Segment | Pricing |
|-----------|-------------|---------------|---------|
| [rakip 1] | [%] | [segment] | [fiyat modeli] |
| [rakip 2] | [%] | [segment] | [fiyat modeli] |

### Feature Comparison Matrix

| Feature | Us | Competitor A | Competitor B | Competitor C |
|---------|-----|-------------|-------------|-------------|
| [F1] | [planned] | [var/yok] | [var/yok] | [var/yok] |
| [F2] | [planned] | [var/yok] | [var/yok] | [var/yok] |
| [F3] | [planned] | [var/yok] | [var/yok] | [var/yok] |

### Differentiators
1. [Bizi farkli kilan 1]
2. [Bizi farkli kilan 2]
3. [Bizi farkli kilan 3]

### Competitive Moat
[Neden kopyalanamaz / zorlasilir]

### Gaps & Opportunities
- [Rakiplerin zayif noktasi 1]
- [Rakiplerin zayif noktasi 2]

Feature Specification Format

markdown
## Feature: [Ozellik Adi]

**ID:** FEAT-001
**Priority:** Must / Should / Could
**Epic:** [bagli epic]
**Owner:** [sorumluluk]

### Description
[1-2 paragraf: ne yapiyor, neden onemli]

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

### Acceptance Criteria
- [ ] Given [precondition], when [action], then [result]
- [ ] Given [precondition], when [action], then [result]

### UI/UX
[Wireframe link veya description]

### Edge Cases
| Case | Behavior |
|------|----------|
| [durum] | [davranis] |

### Technical Notes
[API endpoint, data model, entegrasyon notlari]

### Dependencies
- [Bagimlilik 1]
- [Bagimlilik 2]

### Out of Scope
- [Bu iterasyonda yapilmayacak]

Acceptance Criteria Yazimi

Given-When-Then (BDD) Format

gherkin
Feature: User Registration

  Scenario: Successful registration with valid data
    Given the user is on the registration page
    And the user has not previously registered
    When the user enters valid email "user@example.com"
    And the user enters a password meeting complexity requirements
    And the user clicks "Register"
    Then a new account should be created
    And a verification email should be sent
    And the user should see a success message

  Scenario: Registration with existing email
    Given the user is on the registration page
    And an account with "user@example.com" already exists
    When the user enters email "user@example.com"
    And the user clicks "Register"
    Then the user should see "Email already in use" error
    And no duplicate account should be created

Acceptance Criteria Checklist

] Happy path covered
] Error states defined
] Edge cases documented
] Performance requirements specified
] Security requirements included
] Accessibility requirements noted
] Testable (can be verified objectively)

Anti-Patterns

| Anti-Pattern | Neden Yanlis | Dogru Yol | |-------------|-------------|-----------| | "System should be fast" | Olculemez | "Page loads in < 2 seconds" | | "Should work correctly" | Belirsiz | Specific expected behavior | | No error scenarios | Incomplete | Define every failure mode | | Implementation details | Cozumu kisitlar | Focus on behavior, not how |

Risk Assessment

Risk Matrix

markdown
## Risk Register

| ID | Risk | Likelihood (1-5) | Impact (1-5) | Score | Mitigation | Owner |
|----|------|-------------------|--------------|-------|------------|-------|
| R1 | [risk] | [L] | [I] | [LxI] | [plan] | [kisi] |
| R2 | [risk] | [L] | [I] | [LxI] | [plan] | [kisi] |

### Risk Categories
- **Technical:** Architecture, integration, performance
- **Resource:** Staffing, skills, availability
- **Schedule:** Dependencies, estimation accuracy
- **Business:** Market changes, stakeholder alignment
- **External:** Third-party, regulatory, competitive

### Risk Response Strategies
- **Avoid:** Change plan to eliminate risk
- **Mitigate:** Reduce likelihood or impact
- **Transfer:** Insurance, outsource, vendor SLA
- **Accept:** Monitor and contingency plan

Timeline & Milestone Planning

Phase Planning Template

markdown
## Implementation Phases

### Phase 1: Foundation (Week 1-2)
- [ ] Data model design
- [ ] API scaffolding
- [ ] Auth integration
**Deliverable:** Backend API functional
**Exit Criteria:** API tests passing, deployed to staging

### Phase 2: Core Features (Week 3-5)
- [ ] Feature A implementation
- [ ] Feature B implementation
- [ ] Integration testing
**Deliverable:** Core functionality complete
**Exit Criteria:** All Must requirements met, QA passed

### Phase 3: Polish (Week 6-7)
- [ ] UI/UX refinement
- [ ] Performance optimization
- [ ] Should requirements
**Deliverable:** Beta-ready product
**Exit Criteria:** Beta user feedback positive

### Phase 4: Launch (Week 8)
- [ ] Production deployment
- [ ] Monitoring setup
- [ ] Documentation
**Deliverable:** GA release
**Exit Criteria:** All launch criteria met

PRD Review Checklist

] Problem statement is clear and evidence-based
] Success metrics are measurable and time-bound
] User personas based on real research
] Requirements use MoSCoW prioritization
] Acceptance criteria are testable
] Risks identified with mitigation plans
] Timeline is realistic with buffer
] Open questions have owners and deadlines
] All stakeholders have reviewed and agreed
] Non-goals explicitly stated

Illustrative Want to see what prd-writer would put in front of your model? Preview the rendered body and check its trigger phrases — no LLM call, no signup.

Latest benchmark · publisher runVerified

8/2/2026, 19:45 UTC · 22 cases

Lift

+50%

91% vs 41%

Agent turns

1.0 vs 1.0

Tokens

+106%

5,661.27 vs 2,748.55

fail → pass · 11pass → pass · 9fail → fail · 2

Per-case results (22)

Case	Status	Duration (ms)			Turns			Tokens			Tool calls
Case	Status	Without	With	Δ	Without	With	Δ	Without	With	Δ	Without	With	Δ
case-16 What are key guidelines and anti-patterns to keep in mind when writing acceptance criteria for software engineering stories?	pass→pass	14,098	13,313	-6%	1	1	0%	2,367	5,381	+127%	0	0	—
case-15 What common mistakes should product managers avoid when building user personas based on user research?	pass→pass	14,310	12,797	-11%	1	1	0%	2,332	5,380	+131%	0	0	—
case-01 I need a complete Product Requirements Document for a new automated expense tracking feature in our mobile banking app. Please format it with a standard metadata header, clear problem definition with evidence bullet points, goals with measurable targets, non-goals, user personas, MoSCoW-prioritized functional requirements, non-functional targets, user flows with edge cases, architectural considerations, phased implementation timeline, and a risk evaluation matrix with mitigations.	fail→pass	35,394	33,554	-5%	1	1	0%	5,965	8,974	+50%	0	0	—
case-02 Can you draft a detailed feature specification document and BDD acceptance criteria for an AI-powered smart search bar in an e-commerce platform? Include the feature metadata, detailed user stories, Given-When-Then scenarios covering both successful and edge case paths, UI guidelines, technical integration notes, and a competitive analysis matrix comparing our proposed solution against major market competitors.	fail→fail	40,112	34,379	-14%	1	1	0%	6,213	9,345	+50%	0	0	—
case-03 Help me write a PRD for a customer onboarding redesign for a B2B SaaS platform. I need user personas based on target roles, a feature prioritization matrix scoring impact versus dev effort and risk, functional requirements with priority labels, non-functional targets for page load and SLA, a phased timeline complete with exit criteria for each milestone, and a list of open questions with assigned owners.	fail→fail	18,955	28,174	+49%	1	1	0%	3,348	8,284	+147%	0	0	—
case-04 Draft a sprint retrospective document for the engineering team after finishing Sprint 42 on the checkout optimization initiative.	pass→pass	13,269	16,094	+21%	1	1	0%	2,168	5,708	+163%	0	0	—
case-05 Write an executive release note broadcast email for stakeholders announcing the deployment of v2.4 of our CRM software.	pass→pass	11,287	9,126	-19%	1	1	0%	1,802	4,570	+154%	0	0	—
case-06 Write a high-level lean product one-pager pitch to secure seed funding from internal investment committee for a prospective micro-frontend migration.	pass→pass	12,663	14,778	+17%	1	1	0%	2,011	5,424	+170%	0	0	—
case-07 We are evaluating four core features for our fleet management platform: driver GPS tracking, route optimization, automated maintenance alerts, and fuel usage prediction. We want to prioritize them using a structured scoring matrix balancing impact, dev complexity, and uncertainty. How should we score and assign priority categories to these features?	fail→pass	16,487	13,974	-15%	1	1	0%	2,960	5,834	+97%	0	0	—
case-08 Create a detailed user persona for 'Sarah', a mid-level HR administrator managing employee onboarding in our HR tech portal.	fail→pass	13,812	10,858	-21%	1	1	0%	2,267	4,646	+105%	0	0	—
case-09 Create a standalone feature specification for FEAT-102 'Multi-factor Authentication Reset' for our customer portal.	fail→pass	22,024	18,092	-18%	1	1	0%	3,816	6,232	+63%	0	0	—
case-10 Build a risk register table for launching a new payment gateway integration, calculating overall risk severity from likelihood and impact.	pass→pass	12,424	10,999	-11%	1	1	0%	2,321	5,127	+121%	0	0	—
case-11 Draft an 8-week implementation timeline for introducing real-time collaboration features into a document editor tool.	fail→pass	15,071	20,005	+33%	1	1	0%	2,619	6,147	+135%	0	0	—
case-12 Write BDD-style acceptance criteria scenarios for password reset functionality when a user submits an unregistered email address.	pass→pass	10,177	7,951	-22%	1	1	0%	1,772	4,492	+153%	0	0	—
case-13 Define standard Non-Functional Requirements (NFR) targets for our enterprise SaaS reporting dashboard, covering latency, scaling, availability, and encryption.	pass→pass	14,908	12,783	-14%	1	1	0%	2,604	5,335	+105%	0	0	—
case-14 Provide a competitive analysis comparing our cloud storage solution against top market rivals.	fail→pass	16,687	15,446	-7%	1	1	0%	2,939	5,641	+92%	0	0	—
case-17 Generate the top meta table header for a PRD covering a new AI copywriting tool.	fail→pass	10,918	3,016	-72%	1	1	0%	1,591	3,671	+131%	0	0	—
case-18 Draft Section 1 (Problem Statement) for a PRD addressing high cart abandonment rates on our mobile checkout app.	fail→pass	11,946	7,920	-34%	1	1	0%	1,904	4,420	+132%	0	0	—
case-19 Draft Section 2 (Goals & Success Metrics) for a PRD on introducing dark mode to our web platform.	pass→pass	9,353	7,225	-23%	1	1	0%	1,551	4,339	+180%	0	0	—
case-20 Draft Section 6 (Design & UX) for a PRD specifying an offline data sync feature for a field worker mobile app.	fail→pass	17,101	13,507	-21%	1	1	0%	2,704	5,256	+94%	0	0	—
case-21 Draft Section 7 (Technical Considerations) for a PRD migrating payment infrastructure to Stripe.	fail→pass	18,073	17,150	-5%	1	1	0%	2,998	5,082	+70%	0	0	—
case-22 Provide a PRD review checklist that a lead product manager can use during final approval before handing off to engineering.	fail→pass	14,490	11,925	-18%	1	1	0%	2,216	5,260	+137%	0	0	—

These cases were also screened by the skill’s intent / safety pass.See the Trust review ↗Reproduce this benchmark in Colab ↗

How this skill was measured

DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +50 percentage points is the difference between those two pass rates over the 22 comparable cases.

Model measured: gemini-3.6-flash
Graded by: gemini-3.6-flash
Grading method: judged
Verification: verified
Pass rate without the skill: 40.9%
Pass rate with the skill: 90.9%
Cases attempted: 22
Cases counted toward lift: 22
Cases that regressed: 0
Skill version measured: v2
Run completed: 8/2/2026, 19:45 UTC

Measured example — same prompt, with vs. without the skill · from the benchmark run · case case-01

Prompt

I need a complete Product Requirements Document for a new automated expense tracking feature in our mobile banking app. Please format it with a standard metadata header, clear problem definition with evidence bullet points, goals with measurable targets, non-goals, user personas, MoSCoW-prioritized functional requirements, non-functional targets, user flows with edge cases, architectural considerations, phased implementation timeline, and a risk evaluation matrix with mitigations.

Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.

Show both answers

SkillScore blends 4 signals1 of 4 complete

BenchmarkPass rate WITH skill on a verified run91

Live evalNeeds ≥10 evaluated traces in 30 days

AI ratingNeeds ≥10 rated traces

AdoptionNeeds ≥10 serves across ≥2 orgs in 30 days

Efficiency · separate axis (at equal correctness)+0% turns+142% tokens

Shown for transparency; not credited unless a verified run shows no correctness regression.

Backed by 1 of 4 signals — each added signal makes the score more robust.

Verified on gemini-3.6-flash · re-tested 50 days ago

Model	Method	Date	Lift
gemini-3.6-flash	verified	7/29/2026	+36%

Other measured skills in the registry, with their headline benchmark lift.