prp-generator

name	prp-generator
description	Generate comprehensive Product Requirement Plans (PRPs) for feature implementation with thorough codebase analysis and external research. Use when the user requests a PRP, PRD, or detailed implementation plan for a new feature. Conducts systematic research, identifies patterns, and creates executable validation gates for one-pass implementation success.

PRP Generator

Overview

This skill generates comprehensive Product Requirement Plans (PRPs) that enable AI agents to implement features in a single pass with high success rates. The skill combines systematic codebase analysis with external research to create detailed, context-rich implementation blueprints.

When to Use This Skill

Invoke this skill when:

• User requests a PRP or PRD (Product Requirement Plan/Document)
• User wants a detailed implementation plan for a new feature
• User asks to "plan out" or "design" a complex feature
• Beginning a significant feature development that would benefit from structured planning
• User provides a feature description file and asks for implementation guidance

Core Principle

Context is Everything: The AI agent implementing your PRP only receives:

1. The PRP content you create
2. Training data knowledge
3. Access to the codebase
4. WebSearch capabilities

Therefore, your PRP must be self-contained with all necessary context, specific references, and executable validation gates.

Workflow

Phase 1: Understanding the Feature

1. Read the Feature Request

   • If user provides a feature file path, read it completely
   • If user provides verbal description, clarify requirements by asking:
     • What is the user trying to accomplish?
     • What are the acceptance criteria?
     • Are there any specific constraints or requirements?
   • Identify the core problem being solved

2. Clarify Ambiguities

   • Use AskUserQuestion tool for any unclear requirements
   • Confirm technology stack assumptions
   • Verify integration points
   • Ask about specific patterns to follow if not obvious

Phase 2: Codebase Analysis (Mandatory)

Goal: Understand existing patterns, conventions, and integration points

Refer to references/research_methodology.md for detailed guidance, but the core steps are:

1. Search for Similar Features

   Use Grep to search for:
   - Similar component names
   - Similar functionality keywords
   - Similar UI patterns
   - Similar API endpoints
   

   Document findings with:

   • Exact file paths and line numbers
   • Code snippets showing patterns
   • Relevance to new feature
   • Necessary adaptations

2. Identify Architectural Patterns

   • Directory structure conventions
   • Component organization patterns
   • State management approach
   • API structure patterns
   • Routing patterns (if applicable)

   Example findings:

   Pattern: Feature-based directory structure
   Location: src/features/
   Application: Create src/features/[new-feature]/
   

3. Document Coding Conventions

   • TypeScript usage patterns (interfaces vs types, strict mode)
   • Component patterns (FC vs function, default vs named exports)
   • Styling approach (CSS modules, styled-components, Tailwind)
   • Import ordering and organization
   • Function and variable naming
   • Comment style

   Example:

   Convention: Named exports for all components
   Example: export function UserProfile() { ... }
   Found in: src/components/*.tsx
   

4. Study Test Patterns

   • Test framework and version
   • Test file naming and location
   • Mock strategies
   • Coverage expectations
   • Example test to mirror

   Document:

   Framework: Vitest + @testing-library/react
   Pattern: Co-located tests with *.test.tsx
   Example: src/components/Button/Button.test.tsx
   Mock Strategy: Use vi.fn() for functions, MSW for HTTP
   

5. Check Project Configuration

   • Review package.json for dependencies and scripts
   • Check tsconfig.json for TypeScript settings
   • Review build configuration (vite.config.ts, etc.)
   • Note path aliases and special configurations

   Document:

   Build Tool: Vite 5.x
   Path Aliases: '@/' → 'src/', '@components/' → 'src/components/'
   TypeScript: Strict mode enabled
   

Phase 3: External Research (Mandatory)

Goal: Find best practices, documentation, examples, and gotchas

Refer to references/research_methodology.md for detailed guidance, but the core steps are:

1. Search for Library Documentation

   • Go to official documentation for any libraries being used
   • Find the SPECIFIC version in package.json
   • Document exact URLs to relevant sections
   • Note version-specific features or changes

   Example output:

   Library: @tanstack/react-query
   Version: 5.28.0 (from package.json)
   Docs: https://tanstack.com/query/latest/docs/react/overview
   Key Sections:
     - Queries: https://tanstack.com/query/latest/docs/react/guides/queries
     - Mutations: https://tanstack.com/query/latest/docs/react/guides/mutations
   Gotchas:
     - Query keys must be arrays
     - Automatic refetching on window focus
     - Default staleTime is 0
   

2. Find Implementation Examples

   • Search GitHub for similar implementations
   • Look for StackOverflow solutions (recent, highly-voted)
   • Find blog posts from reputable sources
   • Check official example repositories

   Document:

   Example: Form validation with React Hook Form + Zod
   Source: https://github.com/react-hook-form/react-hook-form/tree/master/examples/V7/zodResolver
   Relevance: Shows exact integration pattern needed
   Key Takeaway: Use zodResolver from @hookform/resolvers
   

3. Research Best Practices

   • Search for "[technology] best practices [current year]"
   • Look for common pitfalls and gotchas
   • Research performance considerations
   • Check security implications (OWASP guidelines)

   Document:

   Practice: Input sanitization for user content
   Why: Prevent XSS attacks
   How: Use DOMPurify before rendering HTML
   Reference: https://owasp.org/www-community/attacks/xss/
   Warning: NEVER use dangerouslySetInnerHTML without sanitization
   

4. Performance & Security Research

   • Bundle size implications of new dependencies
   • Runtime performance patterns
   • Security vulnerabilities to avoid
   • Accessibility considerations

   Document specific URLs and recommendations

Phase 4: Ultra-Thinking (Critical)

STOP AND THINK DEEPLY BEFORE WRITING THE PRP

This is the most important phase. Spend significant time analyzing:

1. Integration Analysis

   • How does the new feature connect to existing code?
   • What existing patterns should be followed?
   • Where might conflicts arise?
   • What files will need to be created vs modified?

2. Implementation Path Planning

   • What is the logical order of implementation steps?
   • What are the dependencies between steps?
   • Where are the potential roadblocks?
   • What edge cases need handling?

3. Validation Strategy

   • What can be validated automatically?
   • What requires manual testing?
   • How can the implementer verify each step?
   • What are the success criteria?

4. Context Completeness Check Ask yourself:

   • Could an AI agent implement this without asking questions?
   • Are all integration points documented?
   • Are all necessary examples included?
   • Are gotchas and warnings clearly stated?
   • Are validation gates executable?
   • Is the implementation path clear and logical?

5. Quality Assessment

   • Is this PRP comprehensive enough for one-pass implementation?
   • What could cause the implementation to fail?
   • What additional context would be helpful?
   • Are all assumptions documented?

Phase 5: Generate the PRP

Use the template from assets/prp_template.md as the base structure, and populate it with:

1. Metadata Section

   • Feature name
   • Timeline estimate
   • Confidence score (1-10)
   • Creation date

2. Executive Summary

   • 2-3 sentences describing the feature
   • Core value proposition

3. Research Findings

   • Codebase analysis results (with file:line references)
   • External research (with specific URLs and sections)
   • Document EVERYTHING discovered in Phase 2 and 3

4. Technical Specification

   • Architecture overview
   • Component breakdown
   • Data models
   • API endpoints (if applicable)

5. Implementation Blueprint

   • Prerequisites
   • Step-by-step implementation (with pseudocode)
   • File-by-file changes
   • Reference patterns from codebase
   • Error handling strategy
   • Edge cases

6. Testing Strategy

   • Unit test approach
   • Integration test approach
   • Manual testing checklist

7. Validation Gates Must be EXECUTABLE commands:

   # Type checking
   npm run type-check
   
   # Linting
   npm run lint
   
   # Tests
   npm run test
   
   # Build
   npm run build
   

8. Success Criteria

   • Clear, measurable completion criteria
   • Checklist format

Phase 6: Quality Scoring

Score the PRP on a scale of 1-10 for one-pass implementation success:

Scoring Criteria:

• 9-10: Exceptionally detailed, all context included, clear path, executable gates
• 7-8: Very good, minor gaps, mostly clear implementation path
• 5-6: Adequate, some ambiguity, may require clarification
• 3-4: Incomplete research, missing context, unclear path
• 1-2: Insufficient for implementation

If score is below 7: Go back and improve the PRP before delivering it.

Phase 7: Save and Deliver

1. Determine Feature Name

   • Use kebab-case
   • Be descriptive but concise
   • Example: "user-authentication", "dark-mode-toggle", "data-export"

2. Save the PRP

   Save to: PRPs/[feature-name].md
   

   If PRPs directory doesn't exist, create it:

   mkdir -p PRPs
   

3. Deliver Summary to User Provide:

   • Brief summary of the feature
   • Location of saved PRP
   • Confidence score and rationale
   • Next steps recommendation

Quality Checklist

Before delivering the PRP, verify:

• Feature requirements fully understood
• Codebase analysis completed with specific file references
• External research completed with URLs and versions
• All similar patterns identified and documented
• Coding conventions documented
• Test patterns identified
• Implementation steps clearly defined
• Validation gates are executable (not pseudo-code)
• Error handling strategy documented
• Edge cases identified
• Success criteria defined
• Confidence score 7+ (if not, improve the PRP)
• No assumptions left undocumented
• Integration points clearly identified
• PRP saved to correct location

Common Pitfalls to Avoid

1. Vague References

   • ❌ "There's a similar component somewhere"
   • ✅ "See UserProfile at src/components/UserProfile.tsx:45-67"

2. Missing Version Information

   • ❌ "Use React Query"
   • ✅ "Use @tanstack/react-query v5.28.0"

3. Non-Executable Validation Gates

   • ❌ "Run tests and make sure they pass"
   • ✅ "npm run test && npm run build"

4. Generic Best Practices

   • ❌ "Follow React best practices"
   • ✅ "Use named exports (see src/components/Button.tsx:1)"

5. Incomplete Research

   • ❌ Skipping codebase analysis
   • ✅ Thoroughly document existing patterns

6. Missing Gotchas

   • ❌ Assuming smooth implementation
   • ✅ Document known issues and edge cases

Example Usage

User Request:

"Create a PRP for adding dark mode support to the application"

Your Response:

1. Clarify: "Should dark mode preference persist across sessions? Should it respect system preferences?"
2. Research codebase for theme-related code
3. Research external resources (dark mode best practices, library options)
4. Ultra-think about implementation approach
5. Generate comprehensive PRP using template
6. Score the PRP
7. Save to PRPs/dark-mode-support.md
8. Deliver summary with confidence score

Resources

Template

• assets/prp_template.md - Base template for all PRPs

References

• references/research_methodology.md - Detailed research guidance and best practices

Notes

• Research is mandatory: Never skip codebase or external research
• Be specific: Always include file paths, line numbers, URLs, versions
• Think deeply: Phase 4 (Ultra-Thinking) is critical for success
• Validate everything: All validation gates must be executable
• Score honestly: If confidence is below 7, improve the PRP
• Context is king: The implementer only has what you put in the PRP