Product Requirements Document writing - PRD templates, MoSCoW prioritization, user personas, competitive analysis, feature specs, acceptance criteria, risk assessment
npx skills add https://github.com/vibeeval/vibecosystem --skill prd-writer
# 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] |
| 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 |
## 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
## 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]
| 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
### 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: [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]
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 "[email protected]"
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 "[email protected]" already exists
When the user enters email "[email protected]"
And the user clicks "Register"
Then the user should see "Email already in use" error
And no duplicate account should be created
| 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 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
## 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
Convert Markdown files to HTML similar to `marked.js`, `pandoc`, `gomarkdown/markdown`, or similar tools; or writing custom script to convert markdown to html and/or working on web template systems like `jekyll/jekyll`, `gohugoio/hugo`, or similar web templating systems that utilize markdown documents, converting them to html. Use when asked to "convert markdown to html", "transform md to html", "render markdown", "generate html from markdown", or when working with .md files and/or web a templating system that converts markdown to HTML output. Supports CLI and Node.js workflows with GFM, CommonMark, and standard Markdown flavors.
Write and maintain technical documentation. Trigger with "write docs for", "document this", "create a README", "write a runbook", "onboarding guide", or when the user needs help with any form of technical writing — API docs, architecture docs, or operational runbooks.
Translate visa application documents (images) to English and create a bilingual PDF with original and translation
Write, review, and edit documentation files with consistent structure, tone, and technical accuracy. Use when creating docs, reviewing markdown files, writing READMEs, updating `/docs` directories, or when user says "write documentation", "review this doc", "improve this README", "create a guide", or "edit markdown". Do NOT use for code comments, inline JSDoc, or API reference generation.
Real-time Constitution compliance checker for devflow documents. Blocks partial implementations and hardcoded secrets during file editing.
Write self-documenting code with minimal, evergreen comments that explain complex logic without describing recent changes or temporary fixes. Use this skill when writing code comments, documentation strings, explaining complex algorithms, clarifying business logic, or deciding whether code needs comments. Apply when working with any source code files where comments or documentation might be added, ensuring comments remain relevant, helpful, and focused on explaining why rather than what the code does, while preferring clear code structure and naming over excessive commenting.
Use when writing technical documentation that needs to be readable by both humans and AI models, converting existing docs to HADS format, validating a HADS document, or optimizing documentation for token-efficient AI consumption.
Draft a structured investment committee memo for PE deal approval. Synthesizes due diligence findings, financial analysis, and deal terms into a professional IC-ready document. Use when preparing for investment committee, writing up a deal, or creating a formal recommendation. Triggers on "write IC memo", "investment committee memo", "deal write-up", "prepare IC materials", or "recommendation memo".
Take vibeeval/prd-writer from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.