{"skill":{"slug":"afrexai-prd-engine","displayName":"PRD Engine","summary":"Complete system for writing, reviewing, and approving product requirement documents (PRDs) from idea validation through shipped features.","description":"# PRD Engine — Product Requirements That Ship\n\nComplete product requirements methodology: from idea to spec to shipped feature. Not just a JSON template — a full system for writing PRDs that developers actually follow and stakeholders actually approve.\n\n## When to Use This Skill\n\n- Turning a vague idea into a buildable specification\n- Writing PRDs for new features, products, or major refactors\n- Reviewing/improving existing PRDs before sprint planning\n- Breaking epics into right-sized user stories\n- Creating technical design documents alongside product specs\n- Preparing specs for AI coding agents (Claude Code, Cursor, Copilot)\n\n---\n\n## Phase 1: Discovery Brief\n\nBefore writing a single requirement, answer these questions. Skip this and you'll rewrite the PRD 3 times.\n\n### Problem Validation Checklist\n\n```yaml\ndiscovery_brief:\n  problem:\n    statement: \"\" # One sentence. If you need two, you don't understand it yet.\n    who_has_it: \"\" # Specific persona, not \"users\"\n    frequency: \"\" # Daily? Weekly? Once? (daily problems > occasional ones)\n    current_workaround: \"\" # What do they do today? (no workaround = maybe not a real problem)\n    evidence:\n      - type: \"\" # support_ticket | user_interview | analytics | churned_user | sales_objection\n        detail: \"\"\n        date: \"\"\n\n  impact:\n    users_affected: \"\" # Number or percentage\n    revenue_impact: \"\" # $ at risk or $ opportunity\n    strategic_alignment: \"\" # Which company goal does this serve?\n\n  constraints:\n    deadline: \"\" # Hard date or flexible?\n    budget: \"\" # Engineering weeks available\n    dependencies: \"\" # What must exist first?\n    regulatory: \"\" # Any compliance requirements?\n\n  success_metrics:\n    primary: \"\" # ONE metric that defines success\n    secondary: [] # 2-3 supporting metrics\n    measurement_method: \"\" # How will you actually measure this?\n    target: \"\" # Specific number, not \"improve\"\n    timeframe: \"\" # When do you expect to see results?\n```\n\n### Problem Statement Formula\n\n**[Persona] needs [capability] because [reason], but currently [blocker], which causes [measurable impact].**\n\nExamples:\n- ❌ \"Users need better onboarding\" (vague, unmeasurable)\n- ✅ \"New free-trial users (500/month) need to reach their first 'aha moment' within 10 minutes because 73% who don't will churn within 48 hours, but currently the average time-to-value is 34 minutes due to a 12-step setup wizard, which costs us ~$18K/month in lost conversions.\"\n\n### Kill Criteria\n\nBefore proceeding, check these. If any are true, STOP and push back:\n\n| Signal | Action |\n|--------|--------|\n| No evidence of the problem (just someone's opinion) | Demand evidence. Opinions aren't requirements. |\n| Solution already decided (\"just build X\") | Rewind to the problem. Solutions without problems = features nobody uses. |\n| Success metric is unmeasurable | Define how you'll measure it or don't build it. |\n| Affects <1% of users with no revenue impact | Deprioritize. Small problems with small impact = small returns. |\n| Scope keeps expanding during discovery | Scope lock. If everything is in scope, nothing is. |\n\n---\n\n## Phase 2: PRD Document\n\n### PRD Template\n\n```markdown\n# PRD: [Feature Name]\n\n**Author:** [Name]\n**Status:** Draft | In Review | Approved | In Progress | Shipped\n**Created:** YYYY-MM-DD\n**Last Updated:** YYYY-MM-DD\n**Approvers:** [Names + roles]\n\n## 1. Problem & Opportunity\n\n[Problem statement from discovery brief — one paragraph max]\n\n### Evidence\n- [Evidence point 1 — with data]\n- [Evidence point 2 — with data]\n\n### Impact\n- Users affected: [number]\n- Revenue impact: [$ amount or % change]\n- Strategic goal: [which one]\n\n## 2. Solution Overview\n\n[2-3 paragraphs max. What are we building and why this approach?]\n\n### What This Is\n- [Bullet list of what's in scope]\n\n### What This Is NOT\n- [Explicit exclusions — this prevents scope creep]\n\n### Key Decisions Made\n| Decision | Options Considered | Chosen | Rationale |\n|----------|-------------------|--------|-----------|\n| [Decision 1] | A, B, C | B | [Why] |\n\n## 3. User Stories\n\n[See Phase 3 below for story writing methodology]\n\n## 4. Design & UX\n\n### User Flow\n1. User [action] →\n2. System [response] →\n3. User sees [outcome]\n\n### Wireframes/Mockups\n[Link to Figma/screenshots or describe key screens]\n\n### Edge Cases\n| Scenario | Expected Behavior |\n|----------|------------------|\n| [Edge case 1] | [What happens] |\n| [Edge case 2] | [What happens] |\n| Empty state | [What user sees with no data] |\n| Error state | [What user sees on failure] |\n| Slow connection | [Loading behavior] |\n\n## 5. Technical Considerations\n\n### Architecture Notes\n- [Key technical decisions]\n- [New services/APIs needed]\n- [Database changes]\n\n### Dependencies\n- [External service X]\n- [Team Y's API]\n- [Library Z]\n\n### Performance Requirements\n- Page load: <[X]ms\n- API response: <[X]ms\n- Concurrent users: [X]\n\n### Security & Privacy\n- [Data handling requirements]\n- [Auth/permissions needed]\n- [PII considerations]\n\n## 6. Release Plan\n\n### Rollout Strategy\n- [ ] Feature flag: [flag name]\n- [ ] Beta group: [who]\n- [ ] % rollout: [10% → 50% → 100%]\n- [ ] Rollback plan: [how]\n\n### Launch Checklist\n- [ ] QA sign-off\n- [ ] Analytics events implemented\n- [ ] Monitoring/alerts configured\n- [ ] Documentation updated\n- [ ] Support team briefed\n- [ ] Stakeholders notified\n\n## 7. Success Criteria\n\n| Metric | Current | Target | Timeframe |\n|--------|---------|--------|-----------|\n| [Primary metric] | [X] | [Y] | [Z weeks] |\n| [Secondary metric] | [X] | [Y] | [Z weeks] |\n\n### Post-Launch Review\n- **1-week check:** [What to look at]\n- **1-month review:** [What to measure]\n- **Kill/iterate decision:** [Criteria for each]\n```\n\n### PRD Quality Rubric (score before sharing)\n\n| Dimension | 0-2 (Weak) | 3-4 (Adequate) | 5 (Strong) | Weight |\n|-----------|-----------|----------------|------------|--------|\n| **Problem clarity** | Vague, no data | Clear but thin evidence | Sharp statement + multiple evidence points | x4 |\n| **Scope discipline** | Everything in scope | Some boundaries | Explicit in/out + \"what this is NOT\" | x3 |\n| **Story quality** | Vague tasks | Stories with some criteria | INVEST stories + verifiable acceptance criteria | x4 |\n| **Edge cases** | None listed | Happy path + 1-2 edges | Comprehensive: empty, error, slow, permissions, concurrent | x3 |\n| **Success metrics** | \"Improve X\" | Metric + target | Metric + baseline + target + timeframe + measurement method | x3 |\n| **Technical feasibility** | No tech section | Architecture notes | Dependencies, performance, security, migration plan | x2 |\n| **Release plan** | None | \"Ship it\" | Feature flag + rollout % + rollback + launch checklist | x1 |\n\n**Scoring:** Sum (score × weight). Max = 100.\n- **80-100:** Ship-ready. Get approvals.\n- **60-79:** Solid but missing pieces. Fill gaps before review.\n- **40-59:** Needs work. Major sections incomplete.\n- **<40:** Start over or go back to discovery.\n\n---\n\n## Phase 3: User Story Methodology\n\n### Story Format\n\n```yaml\nstory:\n  id: \"US-001\"\n  title: \"\" # Action-oriented: \"Add priority field to tasks table\"\n  persona: \"\" # Who benefits\n  narrative: \"As a [persona], I want [capability] so that [benefit]\"\n  acceptance_criteria:\n    - criterion: \"\" # Verifiable statement\n      type: \"functional\" # functional | performance | security | ux\n  priority: 1 # Execution order (dependencies first)\n  size: \"\" # XS | S | M | L | XL\n  status: \"todo\" # todo | in_progress | review | done\n  notes: \"\" # Runtime observations\n  depends_on: [] # Story IDs this depends on\n  blocked_by: [] # External blockers\n```\n\n### INVEST Checklist (every story must pass)\n\n| Letter | Criterion | Test |\n|--------|-----------|------|\n| **I** — Independent | Can be built without other incomplete stories | No circular dependencies |\n| **N** — Negotiable | Details can flex (the \"what\" is fixed, the \"how\" is flexible) | Multiple implementation approaches exist |\n| **V** — Valuable | Delivers user or business value on its own | Would a user/stakeholder care if only this shipped? |\n| **E** — Estimable | Team can size it | No major unknowns (if unknowns exist, add a spike first) |\n| **S** — Small | Completable in one sprint (or one context window for AI agents) | 1-3 days of work max |\n| **T** — Testable | Has verifiable acceptance criteria | Can write a test for each criterion |\n\n### Acceptance Criteria Rules\n\n**Good criteria are:**\n- Binary (pass/fail, not subjective)\n- Specific (numbers, not adjectives)\n- Independent (testable in isolation)\n\n| ❌ Bad | ✅ Good |\n|--------|---------|\n| \"Works correctly\" | \"Returns 200 with JSON body containing `id`, `name`, `status` fields\" |\n| \"Fast enough\" | \"API responds in <200ms at p95 with 100 concurrent users\" |\n| \"User-friendly\" | \"Form shows inline validation errors within 100ms of field blur\" |\n| \"Secure\" | \"Endpoint returns 403 for users without `admin` role\" |\n| \"Handles errors\" | \"On network timeout, shows retry button + cached data if available\" |\n\n**Always include these universal criteria:**\n- `Typecheck passes (tsc --noEmit --strict)` (for TypeScript projects)\n- `All existing tests still pass`\n- `New functionality has test coverage`\n\n### Story Sizing Guide\n\n| Size | Scope | Time | Example |\n|------|-------|------|---------|\n| **XS** | Config change, copy update, env var | <2 hours | \"Update error message text\" |\n| **S** | Single component/function, no new deps | 2-4 hours | \"Add date picker to form\" |\n| **M** | Feature slice: DB + API + UI | 1-2 days | \"Add task priority with filter\" |\n| **L** | Multi-component feature, new patterns | 2-3 days | \"Add real-time notifications\" |\n| **XL** | **Too big. Split it.** | — | — |\n\n### Story Ordering: The Dependency Pyramid\n\nAlways order stories bottom-up:\n\n```\nLevel 1: Schema & Data (migrations, models, seed data)\n    ↑\nLevel 2: Backend Logic (services, APIs, business rules)\n    ↑\nLevel 3: Integration (API routes, auth, middleware)\n    ↑\nLevel 4: UI Components (forms, tables, modals)\n    ↑\nLevel 5: UX Polish (animations, empty states, loading)\n    ↑\nLevel 6: Analytics & Monitoring (events, dashboards)\n```\n\nEach level depends ONLY on levels below it. Never build UI before the API exists.\n\n### Splitting Strategies\n\nWhen a story is too big, split using one of these patterns:\n\n| Strategy | When to Use | Example |\n|----------|------------|---------|\n| **By layer** | Full-stack feature | \"Add schema\" → \"Add API\" → \"Add UI\" |\n| **By operation** | CRUD feature | \"Create task\" → \"Read/list tasks\" → \"Update task\" → \"Delete task\" |\n| **By persona** | Multi-role feature | \"Admin creates template\" → \"User fills template\" → \"Viewer sees results\" |\n| **By happy/sad path** | Complex flows | \"Successful payment\" → \"Payment declined\" → \"Payment timeout\" |\n| **By platform** | Cross-platform | \"iOS support\" → \"Android support\" → \"Web support\" |\n| **Spike + implement** | High uncertainty | \"Spike: evaluate auth libraries (2h)\" → \"Implement auth with chosen library\" |\n\n---\n\n## Phase 4: PRD for AI Coding Agents\n\nWhen the PRD will be executed by AI agents (Claude Code, Cursor, Copilot Workspace, etc.), add these adaptations:\n\n### Agent-Optimized Story Format\n\n```yaml\nagent_story:\n  id: \"US-001\"\n  title: \"Add priority field to tasks table\"\n  context: |\n    The tasks table is in src/db/schema.ts using Drizzle ORM.\n    Priority values should be: high, medium, low (default: medium).\n    See existing fields for naming conventions.\n  acceptance_criteria:\n    - \"Add `priority` column to `tasks` table in src/db/schema.ts\"\n    - \"Type: enum('high', 'medium', 'low'), default 'medium', not null\"\n    - \"Generate migration: `npx drizzle-kit generate`\"\n    - \"Run migration: `npx drizzle-kit push`\"\n    - \"Verify: `tsc --noEmit --strict` passes\"\n    - \"Verify: existing tests pass (`npm test`)\"\n  files_to_touch:\n    - src/db/schema.ts\n    - drizzle/ (generated migration)\n  commands_to_run:\n    - \"npx drizzle-kit generate\"\n    - \"npx drizzle-kit push\"\n    - \"tsc --noEmit --strict\"\n    - \"npm test\"\n  done_when: \"All verify commands pass with exit code 0\"\n```\n\n### Agent-Specific Rules\n\n1. **Be explicit about file paths.** Agents can't guess your project structure.\n2. **Include verification commands.** Agents need a \"definition of done\" they can check.\n3. **One context window per story.** If a story needs the agent to remember more than ~50 files, it's too big.\n4. **List files to touch.** Reduces agent exploration time and prevents hallucination.\n5. **Order matters even more.** Agents execute sequentially — wrong order = compounding errors.\n6. **Include the commands.** Don't say \"run the migration\" — say `npx drizzle-kit push`.\n\n### Project Context File\n\nFor AI agent execution, create a `PROJECT_CONTEXT.md` alongside the PRD:\n\n```markdown\n# Project Context\n\n## Stack\n- Framework: [Next.js 14 / Express / etc.]\n- Language: [TypeScript strict mode]\n- Database: [PostgreSQL via Drizzle ORM]\n- Testing: [Vitest + Testing Library]\n- Styling: [Tailwind CSS]\n\n## Key Directories\n- src/db/ — Database schema and migrations\n- src/api/ — API routes\n- src/components/ — React components\n- src/lib/ — Shared utilities\n- tests/ — Test files (mirror src/ structure)\n\n## Conventions\n- File naming: kebab-case\n- Component naming: PascalCase\n- Max file length: 300 lines\n- Max function length: 50 lines\n- All exports typed, no `any`\n\n## Commands\n- `npm run dev` — Start dev server\n- `npm test` — Run tests\n- `npm run build` — Production build\n- `tsc --noEmit --strict` — Type check\n- `npx drizzle-kit generate` — Generate migration\n- `npx drizzle-kit push` — Apply migration\n\n## Current State\n- [What exists today relevant to the PRD]\n- [Any tech debt or gotchas the agent should know]\n```\n\n---\n\n## Phase 5: Review & Approval\n\n### Review Checklist (before sharing the PRD)\n\n**Completeness:**\n- [ ] Problem statement has evidence (not just opinion)\n- [ ] \"What this is NOT\" section exists and is specific\n- [ ] Every story has ≥3 acceptance criteria\n- [ ] Edge cases table covers: empty state, error state, permissions, concurrent access\n- [ ] Success metrics have baseline + target + timeframe\n- [ ] Technical section addresses: performance, security, dependencies\n\n**Quality:**\n- [ ] No story larger than \"L\" (split XL stories)\n- [ ] All acceptance criteria are binary (pass/fail)\n- [ ] No circular dependencies between stories\n- [ ] Dependency pyramid ordering is correct\n- [ ] Release plan includes rollback strategy\n\n**Readability:**\n- [ ] Executive summary is <3 sentences\n- [ ] Non-engineers can understand the problem section\n- [ ] Engineers can start building from the stories section alone\n- [ ] No jargon without definition\n\n### Approval Flow\n\n```\nAuthor writes PRD\n    ↓\nSelf-review (score with rubric — must be ≥60)\n    ↓\nPeer review (another PM or tech lead)\n    ↓\nEngineering review (feasibility + sizing)\n    ↓\nStakeholder approval (PM lead or product director)\n    ↓\nStatus → Approved\n    ↓\nSprint planning (stories → backlog)\n```\n\n### Common Review Feedback (and how to fix it)\n\n| Feedback | Fix |\n|----------|-----|\n| \"What problem does this solve?\" | Your problem statement is weak. Add evidence. |\n| \"This is too big\" | Split into phases. Ship the smallest valuable slice first (MVP). |\n| \"How do we know it worked?\" | Your success metrics are vague. Add numbers + timeframe. |\n| \"What about [edge case]?\" | Your edge case table is incomplete. Add it. |\n| \"When does this ship?\" | Add timeline with milestones, not just a deadline. |\n| \"Who approved this?\" | Add approvers field and get explicit sign-offs. |\n\n---\n\n## Phase 6: Tracking & Iteration\n\n### PRD Status Lifecycle\n\n```\nDraft → In Review → Approved → In Progress → Shipped → Post-Launch Review\n                ↓                                              ↓\n            Rejected                                    Iterate / Kill\n```\n\n### Progress Tracking\n\nTrack story completion in the PRD itself or a linked tracker:\n\n```yaml\nprogress:\n  total_stories: 12\n  done: 7\n  in_progress: 2\n  blocked: 1\n  todo: 2\n  completion: \"58%\"\n  \n  blocked_items:\n    - story: \"US-008\"\n      blocker: \"Waiting for payments API access from finance team\"\n      since: \"2025-01-15\"\n      escalation: \"Pinged finance lead, follow up Friday\"\n\n  velocity:\n    stories_per_week: 3.5\n    estimated_completion: \"2025-02-01\"\n```\n\n### Post-Launch Review Template\n\n```yaml\npost_launch:\n  shipped_date: \"\"\n  review_date: \"\" # 2-4 weeks after ship\n\n  metrics:\n    primary:\n      metric: \"\"\n      baseline: \"\"\n      target: \"\"\n      actual: \"\"\n      verdict: \"\" # hit | miss | exceeded\n\n    secondary:\n      - metric: \"\"\n        actual: \"\"\n        verdict: \"\"\n\n  qualitative:\n    user_feedback: []\n    support_tickets: \"\" # count related to this feature\n    unexpected_outcomes: []\n\n  process_retro:\n    what_went_well: []\n    what_didnt: []\n    estimation_accuracy: \"\" # actual vs estimated effort\n    scope_changes: \"\" # what changed after approval\n\n  decision: \"\" # iterate | maintain | deprecate | expand\n  next_actions: []\n```\n\n---\n\n## Quick Commands\n\n| Command | What It Does |\n|---------|-------------|\n| \"Write a PRD for [feature]\" | Full PRD from discovery through stories |\n| \"Break this into stories\" | Takes a feature description → user stories |\n| \"Review this PRD\" | Scores against quality rubric + gives specific feedback |\n| \"Make this agent-ready\" | Converts PRD stories to agent-optimized format |\n| \"What's missing from this PRD?\" | Gap analysis against the template |\n| \"Split this story\" | Takes a large story → smaller INVEST-compliant stories |\n| \"Score this PRD\" | Quality rubric scoring with dimension breakdown |\n| \"Create project context for [project]\" | Generates PROJECT_CONTEXT.md for AI agent execution |\n| \"Post-launch review for [feature]\" | Generates review template with metrics |\n| \"Track progress\" | Updates completion stats from story statuses |\n","tags":{"agile":"1.0.0","latest":"1.0.0","planning":"1.0.0","prd":"1.0.0","product":"1.0.0","requirements":"1.0.0","specification":"1.0.0","sprint":"1.0.0","user-stories":"1.0.0"},"stats":{"comments":0,"downloads":1179,"installsAllTime":0,"installsCurrent":0,"stars":0,"versions":1},"createdAt":1771155779390,"updatedAt":1778990697872},"latestVersion":{"version":"1.0.0","createdAt":1771155779390,"changelog":"Initial release — a comprehensive system for shipping high-quality Product Requirements Documents (PRDs).\n\n- Introduces a structured three-phase methodology: Discovery Brief, PRD Document, and User Story development.\n- Covers problem validation, impact assessment, success metrics, constraints, and kill criteria before writing requirements.\n- Provides detailed PRD templates including evidence, impact, architecture, rollout, and metric tracking.\n- Includes a PRD quality rubric for self-assessment before review.\n- Defines an INVEST-driven user story format with acceptance criteria, prioritization, and dependencies.\n- Designed for both human teams and AI coding agents to produce actionable specs.","license":null},"metadata":null,"owner":{"handle":"1kalin","userId":"s17e1q0nx23qnh4n429zzqc05x83hvsw","displayName":"1kalin","image":"https://avatars.githubusercontent.com/u/15705344?v=4"},"moderation":null}