Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:32:48 +08:00
commit 9997176040
24 changed files with 2371 additions and 0 deletions

View 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