Initial commit
This commit is contained in:
400
skills/prp-generator/SKILL.md
Normal file
400
skills/prp-generator/SKILL.md
Normal file
@@ -0,0 +1,400 @@
|
||||
---
|
||||
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:
|
||||
```bash
|
||||
# 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:
|
||||
```bash
|
||||
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
|
||||
Reference in New Issue
Block a user