---
name: bilal140202/doncheli-prd
source: https://app.decimal.ai/s/bilal140202-doncheli-prd@1/SKILL.md
source_sha256: 2882e64d17d4
---

# Don Cheli: PRD Generator

## Instructions

1. **Discover sources** — Identify all available inputs:
   - Figma links: analyze screens, flows, components, missing states
   - Brief documents: extract objectives, audience, problems
   - User research: identify personas, JTBD, pain points
   - Existing code: detect technical constraints
   - Conversation context: extract requirements mentioned by the user

2. **Analyze Figma** (if provided):
   - Count screens/frames and map navigation flow
   - Extract texts, labels, form fields, interactions
   - Detect missing UI states: loading, empty, error, success, offline
   - Identify gaps: flows not designed, edge cases missing
   - Convert each screen → user stories → acceptance criteria

3. **Risk analysis** — For each feature, evaluate 7 risk categories:
   - Technical (complexity, integrations, tech debt)
   - Product (market fit, adoption, competition)
   - UX (usability, accessibility, learning curve)
   - Business (revenue, cost, time-to-market)
   - Legal (GDPR, compliance, ToS)
   - Security (OWASP, sensitive data, auth)
   - Operational (support, scalability, monitoring)
   - Assign probability (Low/Medium/High) and impact (Low/Medium/High/Critical)
   - Propose mitigation for each risk

4. **Prioritize features** using MoSCoW + RICE:
   - MoSCoW: Must / Should / Could / Won't
   - RICE: (Reach × Impact × Confidence) / Effort
   - Rank features by RICE score

5. **Generate PRD** with 13 sections:
   1. Executive Summary
   2. Problem (context, pain points, evidence)
   3. Objectives & Success Metrics (KPIs, North Star)
   4. Target Audience (personas, JTBD, user journey)
   5. Proposed Solution (overview, main flow, features by priority)
   6. Detailed Requirements (functional with Gherkin, non-functional, integrations, data model)
   7. Design & UX (Figma analysis, UI states, responsive, accessibility)
   8. Risk Analysis (matrix, mitigations, dependencies)
   9. Scope (in scope, out of scope, future iterations)
   10. Timeline & Milestones
   11. Competitive Analysis
   12. Launch Plan (rollout, monitoring, rollback)
   13. Appendices (glossary, references, change history)

6. **Validate PRD quality**:
   - Every requirement must be verifiable/testable
   - Success metrics must be defined with baseline and target
   - Every risk must have a mitigation
   - Scope must be realistic for the timeline
   - Anti-scope (out of scope) must be explicit

## Output Format

```markdown
# PRD: [Product/Feature Name]

## Metadata
| Field | Value |
|-------|-------|
| Version | 1.0 |
| Author | [name] |
| Status | Draft / In Review / Approved |
| Date | [date] |

## 1. Executive Summary
...
(continue with all 13 sections)
```

Save output to:
- `.dc/prd/prd-v1.0.md` — Full PRD
- `.dc/prd/prd-risks.md` — Expanded risk matrix
- `.dc/prd/prd-figma-analysis.md` — Figma analysis (if applicable)

## Integration with SDD Pipeline

After generating the PRD, suggest:
```
/dc:specify    → Convert user stories into Gherkin specs
/dc:tech-plan  → Generate blueprint from the PRD
/dc:breakdown  → Create TDD tasks from the stories
```

## Templates

Select based on product type:
- `saas` — B2B platforms, dashboards, multi-tenant
- `mobile` — Native iOS/Android, PWA
- `ecommerce` — Online stores, marketplaces
- `api` — Public APIs, SDKs, developer platforms
- `internal` — Internal team tools
- `landing` — Landing pages, conversion funnels

## Quality Gate

- Never generate a PRD without at least 1 verifiable success metric
- Never omit the risk section — if no risks are visible, dig deeper
- Never leave scope ambiguous — mark unclear items as `[NEEDS CLARIFICATION]`
- Always include explicit anti-scope (what will NOT be built)
- Always generate user stories in Gherkin format for SDD integration
- Always version the PRD (v1.0, v1.1) with change history

## Do not use this skill when

- The task is a simple bug fix or hotfix — use `/dc:quick` instead
- The user only needs technical specs — use `/dc:specify` directly
- The requirement is already well-defined in Gherkin — skip PRD, go to plan