Initial commit
This commit is contained in:
14
.claude-plugin/plugin.json
Normal file
14
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,14 @@
|
||||
{
|
||||
"name": "prp",
|
||||
"description": "A plugin to help you plan and execute in one shot",
|
||||
"version": "1.0.1",
|
||||
"author": {
|
||||
"name": "rajat piplewar"
|
||||
},
|
||||
"agents": [
|
||||
"./agents"
|
||||
],
|
||||
"commands": [
|
||||
"./commands"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# prp
|
||||
|
||||
A plugin to help you plan and execute in one shot
|
||||
114
agents/codebase-analyst.md
Normal file
114
agents/codebase-analyst.md
Normal file
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: "codebase-analyst"
|
||||
description: "Use proactively to find codebase patterns, coding style and team standards. Specialized agent for deep codebase pattern analysis and convention discovery"
|
||||
model: "sonnet"
|
||||
---
|
||||
|
||||
You are a specialized codebase analysis agent focused on discovering patterns, conventions, and implementation approaches.
|
||||
|
||||
## Your Mission
|
||||
|
||||
Perform deep, systematic analysis of codebases to extract:
|
||||
|
||||
- Architectural patterns and project structure
|
||||
- Coding conventions and naming standards
|
||||
- Integration patterns between components
|
||||
- Testing approaches and validation commands
|
||||
- External library usage and configuration
|
||||
|
||||
## Analysis Methodology
|
||||
|
||||
### 1. Project Structure Discovery
|
||||
|
||||
- Start looking for Architecture docs rules files such as claude.md, agents.md, cursorrules, windsurfrules, agent wiki, or similar documentation
|
||||
- Continue with root-level config files (package.json, pyproject.toml, go.mod, etc.)
|
||||
- Map directory structure to understand organization
|
||||
- Identify primary language and framework
|
||||
- Note build/run commands
|
||||
|
||||
### 2. Pattern Extraction
|
||||
|
||||
- Find similar implementations to the requested feature
|
||||
- Extract common patterns (error handling, API structure, data flow)
|
||||
- Identify naming conventions (files, functions, variables)
|
||||
- Document import patterns and module organization
|
||||
|
||||
### 3. Integration Analysis
|
||||
|
||||
- How are new features typically added?
|
||||
- Where do routes/endpoints get registered?
|
||||
- How are services/components wired together?
|
||||
- What's the typical file creation pattern?
|
||||
|
||||
### 4. Testing Patterns
|
||||
|
||||
- What test framework is used?
|
||||
- How are tests structured?
|
||||
- What are common test patterns?
|
||||
- Extract validation command examples
|
||||
|
||||
### 5. Documentation Discovery
|
||||
|
||||
- Check for README files
|
||||
- Find API documentation
|
||||
- Look for inline code comments with patterns
|
||||
- Check PRPs/ai_docs/ for curated documentation
|
||||
|
||||
## Output Format
|
||||
|
||||
Provide findings in structured format:
|
||||
|
||||
```yaml
|
||||
project:
|
||||
language: [detected language]
|
||||
framework: [main framework]
|
||||
structure: [brief description]
|
||||
|
||||
patterns:
|
||||
naming:
|
||||
files: [pattern description]
|
||||
functions: [pattern description]
|
||||
classes: [pattern description]
|
||||
|
||||
architecture:
|
||||
services: [how services are structured]
|
||||
models: [data model patterns]
|
||||
api: [API patterns]
|
||||
|
||||
testing:
|
||||
framework: [test framework]
|
||||
structure: [test file organization]
|
||||
commands: [common test commands]
|
||||
|
||||
similar_implementations:
|
||||
- file: [path]
|
||||
relevance: [why relevant]
|
||||
pattern: [what to learn from it]
|
||||
|
||||
libraries:
|
||||
- name: [library]
|
||||
usage: [how it's used]
|
||||
patterns: [integration patterns]
|
||||
|
||||
validation_commands:
|
||||
syntax: [linting/formatting commands]
|
||||
test: [test commands]
|
||||
run: [run/serve commands]
|
||||
```
|
||||
|
||||
## Key Principles
|
||||
|
||||
- Be specific - point to exact files and line numbers
|
||||
- Extract executable commands, not abstract descriptions
|
||||
- Focus on patterns that repeat across the codebase
|
||||
- Note both good patterns to follow and anti-patterns to avoid
|
||||
- Prioritize relevance to the requested feature/story
|
||||
|
||||
## Search Strategy
|
||||
|
||||
1. Start broad (project structure) then narrow (specific patterns)
|
||||
2. Use parallel searches when investigating multiple aspects
|
||||
3. Follow references - if a file imports something, investigate it
|
||||
4. Look for "similar" not "same" - patterns often repeat with variations
|
||||
|
||||
Remember: Your analysis directly determines implementation success. Be thorough, specific, and actionable.
|
||||
108
agents/library-researcher.md
Normal file
108
agents/library-researcher.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
name: "library-researcher"
|
||||
description: "Use proactivley to research external libraries and fetch relevant documentation for implementation"
|
||||
model: "sonnet"
|
||||
---
|
||||
|
||||
You are a specialized library research agent focused on gathering implementation-critical documentation.
|
||||
|
||||
## Your Mission
|
||||
|
||||
Research external libraries and APIs to provide:
|
||||
|
||||
- Specific implementation examples
|
||||
- API method signatures and patterns
|
||||
- Common pitfalls and best practices
|
||||
- Version-specific considerations
|
||||
|
||||
## Research Strategy
|
||||
|
||||
### 1. Official Documentation
|
||||
|
||||
- Start with Archon MCP tools and check if we have relevant docs in the database
|
||||
- Use the RAG tools to search for relevant documentation, use specific keywords and context in your queries
|
||||
- Use websearch and webfetch to search official docs (check package registry for links)
|
||||
- Find quickstart guides and API references
|
||||
- Identify code examples specific to the use case
|
||||
- Note version-specific features or breaking changes
|
||||
|
||||
### 2. Implementation Examples
|
||||
|
||||
- Search GitHub for real-world usage
|
||||
- Find Stack Overflow solutions for common patterns
|
||||
- Look for blog posts with practical examples
|
||||
- Check the library's test files for usage patterns
|
||||
|
||||
### 3. Integration Patterns
|
||||
|
||||
- How do others integrate this library?
|
||||
- What are common configuration patterns?
|
||||
- What helper utilities are typically created?
|
||||
- What are typical error handling patterns?
|
||||
|
||||
### 4. Known Issues
|
||||
|
||||
- Check library's GitHub issues for gotchas
|
||||
- Look for migration guides indicating breaking changes
|
||||
- Find performance considerations
|
||||
- Note security best practices
|
||||
|
||||
## Output Format
|
||||
|
||||
Structure findings for immediate use:
|
||||
|
||||
```yaml
|
||||
library: [library name]
|
||||
version: [version in use]
|
||||
documentation:
|
||||
quickstart: [URL with section anchor]
|
||||
api_reference: [specific method docs URL]
|
||||
examples: [example code URL]
|
||||
|
||||
key_patterns:
|
||||
initialization: |
|
||||
[code example]
|
||||
|
||||
common_usage: |
|
||||
[code example]
|
||||
|
||||
error_handling: |
|
||||
[code example]
|
||||
|
||||
gotchas:
|
||||
- issue: [description]
|
||||
solution: [how to handle]
|
||||
|
||||
best_practices:
|
||||
- [specific recommendation]
|
||||
|
||||
save_to_ai_docs: [yes/no - if complex enough to warrant local documentation]
|
||||
```
|
||||
|
||||
## Documentation Curation
|
||||
|
||||
When documentation is complex or critical:
|
||||
|
||||
1. Create condensed version in PRPs/ai_docs/{library}\_patterns.md
|
||||
2. Focus on implementation-relevant sections
|
||||
3. Include working code examples
|
||||
4. Add project-specific integration notes
|
||||
|
||||
## Search Queries
|
||||
|
||||
Effective search patterns:
|
||||
|
||||
- "{library} {feature} example"
|
||||
- "{library} TypeError site:stackoverflow.com"
|
||||
- "{library} best practices {language}"
|
||||
- "github {library} {feature} language:{language}"
|
||||
|
||||
## Key Principles
|
||||
|
||||
- Prefer official docs but verify with real implementations
|
||||
- Focus on the specific features needed for the story
|
||||
- Provide executable code examples, not abstract descriptions
|
||||
- Note version differences if relevant
|
||||
- Save complex findings to ai_docs for future reference
|
||||
|
||||
Remember: Good library research prevents implementation blockers and reduces debugging time.
|
||||
129
commands/api-contract-define.md
Normal file
129
commands/api-contract-define.md
Normal file
@@ -0,0 +1,129 @@
|
||||
# Define API Contract Between Backend and Frontend
|
||||
|
||||
Feature: $ARGUMENTS
|
||||
|
||||
## Task: Create detailed API contract specification for backend/frontend coordination
|
||||
|
||||
1. **Define RESTful endpoints**:
|
||||
|
||||
```yaml
|
||||
Base URL: /api/v1/{feature}
|
||||
|
||||
Endpoints:
|
||||
- GET /api/v1/{features}
|
||||
Query params: page, size, sort, filter
|
||||
Response: Page<{Feature}Response>
|
||||
|
||||
- GET /api/v1/{features}/{id}
|
||||
Path param: id (Long)
|
||||
Response: {Feature}Response
|
||||
|
||||
- POST /api/v1/{features}
|
||||
Body: {Feature}Request
|
||||
Response: {Feature}Response (201 Created)
|
||||
|
||||
- PUT /api/v1/{features}/{id}
|
||||
Path param: id (Long)
|
||||
Body: {Feature}Request
|
||||
Response: {Feature}Response
|
||||
|
||||
- DELETE /api/v1/{features}/{id}
|
||||
Path param: id (Long)
|
||||
Response: 204 No Content
|
||||
```
|
||||
|
||||
2. **Define request/response DTOs**:
|
||||
|
||||
```typescript
|
||||
// Request DTO (for POST/PUT)
|
||||
interface {Feature}Request {
|
||||
name: string; // min: 2, max: 100
|
||||
description?: string; // max: 1000
|
||||
// Add domain-specific fields
|
||||
}
|
||||
|
||||
// Response DTO (for GET)
|
||||
interface {Feature}Response {
|
||||
id: number;
|
||||
name: string;
|
||||
description?: string;
|
||||
createdAt: string; // ISO 8601
|
||||
updatedAt: string; // ISO 8601
|
||||
// Add computed fields
|
||||
}
|
||||
|
||||
// Page response wrapper
|
||||
interface Page<T> {
|
||||
content: T[];
|
||||
totalElements: number;
|
||||
totalPages: number;
|
||||
size: number;
|
||||
number: number;
|
||||
}
|
||||
```
|
||||
|
||||
3. **Define error responses**:
|
||||
|
||||
```json
|
||||
{
|
||||
"timestamp": "2024-01-20T10:30:00Z",
|
||||
"status": 400,
|
||||
"error": "Bad Request",
|
||||
"message": "Validation failed",
|
||||
"path": "/api/v1/{features}",
|
||||
"errors": [
|
||||
{
|
||||
"field": "name",
|
||||
"message": "Name is required"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
4. **Define validation rules**:
|
||||
- Backend: Bean Validation annotations
|
||||
- Frontend: Matching Zod schemas
|
||||
|
||||
```
|
||||
name: required, 2-100 chars
|
||||
description: optional, max 1000 chars
|
||||
email: valid email format
|
||||
date: ISO 8601 format
|
||||
```
|
||||
|
||||
5. **Define status codes**:
|
||||
- 200: OK (GET, PUT)
|
||||
- 201: Created (POST)
|
||||
- 204: No Content (DELETE)
|
||||
- 400: Bad Request (validation)
|
||||
- 404: Not Found
|
||||
- 409: Conflict (duplicate)
|
||||
- 500: Internal Server Error
|
||||
|
||||
6. **Integration requirements**:
|
||||
- CORS: Allow frontend origin
|
||||
- Content-Type: application/json
|
||||
- Authentication: Bearer token (if needed)
|
||||
- Pagination: Spring Pageable format
|
||||
- Sorting: field,direction (e.g., "name,asc")
|
||||
|
||||
7. **Backend implementation notes**:
|
||||
|
||||
```java
|
||||
// Entity fields match response DTO
|
||||
// Use MapStruct for DTO mapping
|
||||
// Repository method naming conventions
|
||||
// Service layer validation
|
||||
```
|
||||
|
||||
8. **Frontend implementation notes**:
|
||||
```typescript
|
||||
// Zod schemas match validation rules
|
||||
// API client with base configuration
|
||||
// TanStack Query hooks
|
||||
// Error handling utilities
|
||||
```
|
||||
|
||||
Save this contract as: `PRPs/working-memory/{feature-name}/contracts/{feature}-api-contract.md`
|
||||
|
||||
Share this file between backend and frontend teams for alignment.
|
||||
113
commands/prp-base-create.md
Normal file
113
commands/prp-base-create.md
Normal file
@@ -0,0 +1,113 @@
|
||||
# Create BASE PRP
|
||||
|
||||
## Feature: $ARGUMENTS
|
||||
|
||||
## PRP Creation Mission
|
||||
|
||||
Create a comprehensive PRP that enables **one-pass implementation success** through systematic research and context curation.
|
||||
|
||||
**Critical Understanding**: The executing AI agent only receives:
|
||||
|
||||
- Start by reading and understanding the prp concepts PRPs/README.md
|
||||
- The PRP content you create
|
||||
- Its training data knowledge
|
||||
- Access to codebase files (but needs guidance on which ones)
|
||||
|
||||
**Therefore**: Your research and context curation directly determines implementation success. Incomplete context = implementation failure.
|
||||
|
||||
## Research Process
|
||||
|
||||
> During the research process, create clear tasks and spawn as many agents and subagents as needed using the batch tools. The deeper research we do here the better the PRP will be. we optminize for chance of success and not for speed.
|
||||
|
||||
1. **User Clarification**
|
||||
- Breakdown the ask into clear steps
|
||||
- List all assumptions as you make them
|
||||
- Clarify your assumptions from user before proceeding
|
||||
|
||||
2. **Codebase Analysis in depth**
|
||||
- Create clear todos and spawn subagents to search the codebase for similar features/patterns Think hard and plan your approach
|
||||
- Identify all the necessary files to reference in the PRP
|
||||
- Note all existing conventions to follow
|
||||
- Check existing test patterns for validation approach
|
||||
- Use the batch tools to spawn subagents to search the codebase for similar features/patterns
|
||||
|
||||
3. **External Research at scale**
|
||||
- Create clear todos and spawn with instructions subagents to do deep research for similar features/patterns online and include urls to documentation and examples
|
||||
- Library documentation (include specific URLs)
|
||||
- For critical pieces of documentation add a .md file to PRPs/ai_docs and reference it in the PRP with clear reasoning and instructions
|
||||
- Implementation examples (GitHub/StackOverflow/blogs)
|
||||
- Best practices and common pitfalls found during research
|
||||
- Use the batch tools to spawn subagents to search for similar features/patterns online and include urls to documentation and examples
|
||||
|
||||
3. **User Clarification**
|
||||
- Ask for clarification if you need it
|
||||
|
||||
## PRP Generation Process
|
||||
|
||||
### Step 1: Choose Template
|
||||
|
||||
Use `PRPs/templates/prp_base.md` as your template structure - it contains all necessary sections and formatting.
|
||||
|
||||
### Step 2: Context Completeness Validation
|
||||
|
||||
Before writing, apply the **"No Prior Knowledge" test** from the template:
|
||||
_"If someone knew nothing about this codebase, would they have everything needed to implement this successfully?"_
|
||||
|
||||
### Step 3: Research Integration
|
||||
|
||||
Transform your research findings into the template sections:
|
||||
|
||||
**Goal Section**: Use research to define specific, measurable Feature Goal and concrete Deliverable
|
||||
**Context Section**: Populate YAML structure with your research findings - specific URLs, file patterns, gotchas
|
||||
**Implementation Tasks**: Create dependency-ordered tasks using information-dense keywords from codebase analysis
|
||||
**Validation Gates**: Use project-specific validation commands that you've verified work in this codebase
|
||||
|
||||
### Step 4: Information Density Standards
|
||||
|
||||
Ensure every reference is **specific and actionable**:
|
||||
|
||||
- URLs include section anchors, not just domain names
|
||||
- File references include specific patterns to follow, not generic mentions
|
||||
- Task specifications include exact naming conventions and placement
|
||||
- Validation commands are project-specific and executable
|
||||
|
||||
### Step 5: ULTRATHINK Before Writing
|
||||
|
||||
After research completion, create comprehensive PRP writing plan using TodoWrite tool:
|
||||
|
||||
- Plan how to structure each template section with your research findings
|
||||
- Identify gaps that need additional research
|
||||
- Create systematic approach to filling template with actionable context
|
||||
|
||||
## Output
|
||||
|
||||
Save as: `PRPs/working-memory/{feature-name}/.plan`
|
||||
|
||||
## PRP Quality Gates
|
||||
|
||||
### Context Completeness Check
|
||||
|
||||
- [ ] Passes "No Prior Knowledge" test from template
|
||||
- [ ] All YAML references are specific and accessible
|
||||
- [ ] Implementation tasks include exact naming and placement guidance
|
||||
- [ ] Validation commands are project-specific and verified working
|
||||
|
||||
### Template Structure Compliance
|
||||
|
||||
- [ ] All required template sections completed
|
||||
- [ ] Goal section has specific Feature Goal, Deliverable, Success Definition
|
||||
- [ ] Implementation Tasks follow dependency ordering
|
||||
- [ ] Final Validation Checklist is comprehensive
|
||||
|
||||
### Information Density Standards
|
||||
|
||||
- [ ] No generic references - all are specific and actionable
|
||||
- [ ] File patterns point at specific examples to follow
|
||||
- [ ] URLs include section anchors for exact guidance
|
||||
- [ ] Task specifications use information-dense keywords from codebase
|
||||
|
||||
## Success Metrics
|
||||
|
||||
**Confidence Score**: Rate 1-10 for one-pass implementation success likelihood
|
||||
|
||||
**Validation**: The completed PRP should enable an AI agent unfamiliar with the codebase to implement the feature successfully using only the PRP content and codebase access.
|
||||
55
commands/prp-base-execute.md
Normal file
55
commands/prp-base-execute.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# Execute BASE PRP
|
||||
|
||||
## PRP File: $ARGUMENTS
|
||||
|
||||
## Mission: One-Pass Implementation Success
|
||||
|
||||
PRPs enable working code on the first attempt through:
|
||||
|
||||
- **Context Completeness**: Everything needed, nothing guessed
|
||||
- **Progressive Validation**: 4-level gates catch errors early
|
||||
- **Pattern Consistency**: Follow existing codebase approaches
|
||||
- Read PRPs/README.md to understand PRP concepts
|
||||
|
||||
**Your Goal**: Transform the PRP into working code that passes all validation gates.
|
||||
|
||||
## Execution Process
|
||||
|
||||
1. **Load PRP**
|
||||
- Read the specified PRP file completely
|
||||
- Absorb all context, patterns, requirements and gather codebase intelligence
|
||||
- Use the provided documentation references and file patterns, consume the right documentation before the appropriate todo/task
|
||||
- Trust the PRP's context and guidance - it's designed for one-pass success
|
||||
- If needed do additional codebase exploration and research as needed
|
||||
|
||||
2. **ULTRATHINK & Plan**
|
||||
- Create comprehensive implementation plan following the PRP's task order
|
||||
- Break down into clear todos using TodoWrite tool
|
||||
- Use subagents for parallel work when beneficial (always create prp inspired prompts for subagents when used)
|
||||
- Follow the patterns referenced in the PRP
|
||||
- Use specific file paths, class names, and method signatures from PRP context
|
||||
- Never guess - always verify the codebase patterns and examples referenced in the PRP yourself
|
||||
|
||||
3. **Execute Implementation**
|
||||
- Follow the PRP's Implementation Tasks sequence, add more detail as needed, especially when using subagents
|
||||
- Use the patterns and examples referenced in the PRP
|
||||
- Create files in locations specified by the desired codebase tree
|
||||
- Apply naming conventions from the task specifications and CLAUDE.md
|
||||
|
||||
4. **Progressive Validation**
|
||||
|
||||
**Execute the level validation system from the PRP:**
|
||||
- **Level 1**: Run syntax & style validation commands from PRP
|
||||
- **Level 2**: Execute unit test validation from PRP
|
||||
- **Level 3**: Run integration testing commands from PRP
|
||||
- **Level 4**: Execute specified validation from PRP
|
||||
|
||||
**Each level must pass before proceeding to the next.**
|
||||
|
||||
5. **Completion Verification**
|
||||
- Work through the Final Validation Checklist in the PRP
|
||||
- Verify all Success Criteria from the "What" section are met
|
||||
- Confirm all Anti-Patterns were avoided
|
||||
- Implementation is ready and working
|
||||
|
||||
**Failure Protocol**: When validation fails, use the patterns and gotchas from the PRP to fix issues, then re-run validation until passing.
|
||||
142
commands/prp-planning-create.md
Normal file
142
commands/prp-planning-create.md
Normal file
@@ -0,0 +1,142 @@
|
||||
# Create PLANNING PRP (Advanced)
|
||||
|
||||
Transform rough ideas into comprehensive PRDs with rich visual documentation.
|
||||
|
||||
## Idea: $ARGUMENTS
|
||||
|
||||
## Discovery Process
|
||||
|
||||
1. **Concept Expansion**
|
||||
- Break down the core idea
|
||||
- Define success criteria
|
||||
- Map to business goals if provided
|
||||
|
||||
2. **Market & Technical Research**
|
||||
- Do deep web search for the following:
|
||||
- Market analysis
|
||||
- Competitor analysis
|
||||
- Technical feasibility study
|
||||
- Best practice examples
|
||||
- Integration possibilities
|
||||
|
||||
3. **User Research & Clarification**
|
||||
- Ask user for the following if not provided:
|
||||
- Target user personas?
|
||||
- Key pain points?
|
||||
- Success metrics?
|
||||
- Constraints/requirements?
|
||||
|
||||
## PRD Generation
|
||||
|
||||
Using /PRPs/templates/prp_planning_base.md:
|
||||
|
||||
### Visual Documentation Plan
|
||||
```yaml
|
||||
diagrams_needed:
|
||||
user_flows:
|
||||
- Happy path journey
|
||||
- Error scenarios
|
||||
- Edge cases
|
||||
|
||||
architecture:
|
||||
- System components
|
||||
- Data flow
|
||||
- Integration points
|
||||
|
||||
sequences:
|
||||
- API interactions
|
||||
- Event flows
|
||||
- State changes
|
||||
|
||||
data_models:
|
||||
- Entity relationships
|
||||
- Schema design
|
||||
- State machines
|
||||
```
|
||||
|
||||
### Research Integration
|
||||
- **Market Analysis**: Include findings in PRD
|
||||
- **Technical Options**: Compare approaches
|
||||
- **Risk Assessment**: With mitigation strategies
|
||||
- **Success Metrics**: Specific, measurable
|
||||
|
||||
### User Story Development
|
||||
```markdown
|
||||
## Epic: [High-level feature]
|
||||
|
||||
### Story 1: [User need]
|
||||
**As a** [user type]
|
||||
**I want** [capability]
|
||||
**So that** [benefit]
|
||||
|
||||
**Acceptance Criteria:**
|
||||
- [ ] Specific behavior
|
||||
- [ ] Edge case handling
|
||||
- [ ] Performance requirement
|
||||
|
||||
**Technical Notes:**
|
||||
- Implementation approach
|
||||
- API implications
|
||||
- Data requirements
|
||||
```
|
||||
|
||||
### Implementation Strategy
|
||||
- Phases with dependencies (no dates)
|
||||
- Priority ordering
|
||||
- MVP vs enhanced features
|
||||
- Technical prerequisites
|
||||
|
||||
## User Interaction Points
|
||||
|
||||
1. **Idea Validation**
|
||||
- Confirm understanding
|
||||
- Clarify ambiguities
|
||||
- Set boundaries
|
||||
|
||||
2. **Research Review**
|
||||
- Share findings
|
||||
- Validate assumptions
|
||||
- Adjust direction
|
||||
|
||||
3. **PRD Draft Review**
|
||||
- Architecture approval
|
||||
- Risk acknowledgment
|
||||
- Success metric agreement
|
||||
|
||||
## Diagram Guidelines
|
||||
- Use Mermaid for all diagrams
|
||||
- Include legends where needed
|
||||
- Show error paths
|
||||
- Annotate complex flows
|
||||
|
||||
## Output Structure
|
||||
```markdown
|
||||
1. Executive Summary
|
||||
2. Problem & Solution
|
||||
3. User Stories (with diagrams)
|
||||
4. Technical Architecture (with diagrams)
|
||||
5. API Specifications
|
||||
6. Data Models
|
||||
7. Implementation Phases
|
||||
8. Risks & Mitigations
|
||||
9. Success Metrics
|
||||
10. Appendices
|
||||
```
|
||||
|
||||
Save as: `PRPs/working-memory/{feature-name}/{feature-name}-prd.md`
|
||||
|
||||
## Quality Checklist
|
||||
- [ ] Problem clearly articulated
|
||||
- [ ] Solution addresses problem
|
||||
- [ ] All user flows diagrammed
|
||||
- [ ] Wireframes included if needed
|
||||
- [ ] Architecture visualized
|
||||
- [ ] APIs fully specified with examples
|
||||
- [ ] Data models included
|
||||
- [ ] Dependencies identified
|
||||
- [ ] Risks identified and mitigated
|
||||
- [ ] Success metrics measurable
|
||||
- [ ] Implementation phases logical
|
||||
- [ ] Ready for implementation PRP
|
||||
|
||||
Remember: Great PRDs prevent implementation confusion.
|
||||
259
commands/prp-poc-create-parallel.md
Normal file
259
commands/prp-poc-create-parallel.md
Normal file
@@ -0,0 +1,259 @@
|
||||
# Create Parallel React POCs
|
||||
|
||||
## Request: $ARGUMENTS
|
||||
|
||||
Usage: `/prp-poc-create-parallel [number_of_demos] "[problem_statement]"`
|
||||
Example: `/prp-poc-create-parallel 5 "create a dashboard for tracking team productivity with real-time metrics"`
|
||||
|
||||
## Parallel POC Creation Mission
|
||||
|
||||
Create multiple React POC variations simultaneously to **maximize concept validation** through diverse implementation approaches. This command generates PRPs for parallel execution using specialized UI/UX and User Journey agents.
|
||||
|
||||
**Critical Understanding**: Each POC targets different aspects of the same problem:
|
||||
- Different UI/UX approaches (minimal, polished, experimental)
|
||||
- Different user journey focuses (power user, casual user, admin)
|
||||
- Different technical approaches (component-heavy, page-based, single-file)
|
||||
- Different fidelity levels (wireframe, demo, MVP)
|
||||
|
||||
## Parallel Creation Strategy
|
||||
|
||||
### Agent Specialization Pattern
|
||||
|
||||
For **N demos** requested, create **N pairs** of specialized agents:
|
||||
- **N UI-UX Agents**: Each focusing on different design approaches
|
||||
- **N User Journey Agents**: Each targeting different user personas/flows
|
||||
|
||||
**Agent Assignment Matrix:**
|
||||
```yaml
|
||||
Demo 1: @ui-ux-agent (Minimal/Clean) + @user-journey-agent (Power User)
|
||||
Demo 2: @ui-ux-agent (Polished/Professional) + @user-journey-agent (Casual User)
|
||||
Demo 3: @ui-ux-agent (Experimental/Modern) + @user-journey-agent (Admin User)
|
||||
Demo 4: @ui-ux-agent (Dashboard-Heavy) + @user-journey-agent (Mobile-First)
|
||||
Demo 5: @ui-ux-agent (Component-Library) + @user-journey-agent (Accessibility-First)
|
||||
```
|
||||
|
||||
### POC Variation Strategy
|
||||
|
||||
Each POC should explore different aspects:
|
||||
|
||||
**Design Variations:**
|
||||
- **Minimal**: Clean, simple, content-focused
|
||||
- **Polished**: Professional, brand-aligned, stakeholder-ready
|
||||
- **Experimental**: Modern patterns, micro-interactions, innovative UI
|
||||
- **Dashboard-Heavy**: Data visualization focused, charts/graphs
|
||||
- **Component-Library**: Showcases reusable design system components
|
||||
|
||||
**User Journey Variations:**
|
||||
- **Power User**: Feature-rich, keyboard shortcuts, advanced workflows
|
||||
- **Casual User**: Simplified navigation, guided experiences, fewer options
|
||||
- **Admin User**: Management interfaces, bulk actions, system controls
|
||||
- **Mobile-First**: Touch-optimized, responsive, gesture-based
|
||||
- **Accessibility-First**: Screen reader optimized, keyboard navigation, high contrast
|
||||
|
||||
## Implementation Process
|
||||
|
||||
### Step 1: Problem Analysis & POC Strategy
|
||||
|
||||
Analyze the problem statement and create a **parallel execution plan**:
|
||||
|
||||
1. **Parse Request Arguments**
|
||||
- Extract number of demos requested (default: 5)
|
||||
- Analyze problem statement for key concepts and requirements
|
||||
- Identify core user personas and interaction patterns
|
||||
|
||||
2. **Design POC Matrix**
|
||||
- Create unique combination of UI approach + User journey for each demo
|
||||
- Ensure each POC validates different aspects of the problem
|
||||
- Plan directory structure: `poc-{problem-slug}-{variant-number}`
|
||||
|
||||
### Step 2: Parallel Agent Research
|
||||
|
||||
**Execute all research agents in PARALLEL using Task tool:**
|
||||
|
||||
```yaml
|
||||
# Spawn N pairs of agents simultaneously
|
||||
Task 1 - @ui-ux-agent for Demo 1:
|
||||
"Analyze the problem: '{problem_statement}' and design a MINIMAL/CLEAN UI approach.
|
||||
Focus on: Clean typography, generous whitespace, content-first design.
|
||||
Research component patterns and create UI specifications for a React POC.
|
||||
Target: Stakeholder presentations requiring clear concept demonstration.
|
||||
Return: UI component architecture, styling approach, and design specifications."
|
||||
|
||||
Task 2 - @user-journey-agent for Demo 1:
|
||||
"Analyze the problem: '{problem_statement}' and design a POWER USER journey.
|
||||
Focus on: Advanced features, keyboard shortcuts, efficient workflows.
|
||||
Research user patterns and create journey specifications for React POC.
|
||||
Target: Users who need maximum functionality and control.
|
||||
Return: User flow architecture, interaction patterns, and journey specifications."
|
||||
|
||||
Task 3 - @ui-ux-agent for Demo 2:
|
||||
"Analyze the problem: '{problem_statement}' and design a POLISHED/PROFESSIONAL UI approach.
|
||||
Focus on: Brand alignment, professional aesthetics, stakeholder-ready presentation.
|
||||
Research premium component patterns and create UI specifications for React POC.
|
||||
Target: Executive demos and client presentations.
|
||||
Return: UI component architecture, styling approach, and design specifications."
|
||||
|
||||
Task 4 - @user-journey-agent for Demo 2:
|
||||
"Analyze the problem: '{problem_statement}' and design a CASUAL USER journey.
|
||||
Focus on: Simplified navigation, guided experiences, progressive disclosure.
|
||||
Research beginner-friendly patterns and create journey specifications for React POC.
|
||||
Target: Users new to the system who need guidance and simplicity.
|
||||
Return: User flow architecture, interaction patterns, and journey specifications."
|
||||
|
||||
# Continue pattern for remaining demos...
|
||||
```
|
||||
|
||||
### Step 3: PRP Generation from Research
|
||||
|
||||
After all research agents complete, **synthesize results into POC PRPs**:
|
||||
|
||||
1. **Use prp_poc_react.md template** for each POC
|
||||
2. **Incorporate agent research** into context sections
|
||||
3. **Customize each PRP** based on UI/UX + User Journey specifications
|
||||
4. **Create unique identifiers** for parallel development
|
||||
|
||||
### Step 4: POC Specification Matrix
|
||||
|
||||
Generate **N PRPs** with these variations:
|
||||
|
||||
**POC 1: Minimal Power User**
|
||||
```yaml
|
||||
poc_name: "poc-{problem-slug}-minimal-power"
|
||||
ui_approach: "Clean, typography-focused, content-first design"
|
||||
user_journey: "Advanced features, keyboard shortcuts, efficient workflows"
|
||||
fidelity: "Demo"
|
||||
unique_aspects: "Focuses on functionality over aesthetics, rapid interaction patterns"
|
||||
```
|
||||
|
||||
**POC 2: Polished Casual User**
|
||||
```yaml
|
||||
poc_name: "poc-{problem-slug}-polished-casual"
|
||||
ui_approach: "Professional aesthetics, brand-aligned, premium components"
|
||||
user_journey: "Guided experience, progressive disclosure, help tooltips"
|
||||
fidelity: "MVP"
|
||||
unique_aspects: "Executive-ready presentation with beginner-friendly flows"
|
||||
```
|
||||
|
||||
**POC 3: Experimental Admin**
|
||||
```yaml
|
||||
poc_name: "poc-{problem-slug}-experimental-admin"
|
||||
ui_approach: "Modern patterns, micro-interactions, innovative UI elements"
|
||||
user_journey: "Management interfaces, bulk actions, system administration"
|
||||
fidelity: "Demo"
|
||||
unique_aspects: "Cutting-edge design patterns with administrative power features"
|
||||
```
|
||||
|
||||
**POC 4: Dashboard Mobile-First**
|
||||
```yaml
|
||||
poc_name: "poc-{problem-slug}-dashboard-mobile"
|
||||
ui_approach: "Data visualization heavy, charts and metrics focused"
|
||||
user_journey: "Touch-optimized interactions, responsive design, gesture-based"
|
||||
fidelity: "Demo"
|
||||
unique_aspects: "Analytics dashboard optimized for mobile devices"
|
||||
```
|
||||
|
||||
**POC 5: Component-Library Accessible**
|
||||
```yaml
|
||||
poc_name: "poc-{problem-slug}-components-a11y"
|
||||
ui_approach: "Design system showcase, reusable component patterns"
|
||||
user_journey: "Screen reader optimized, keyboard navigation, inclusive design"
|
||||
fidelity: "MVP"
|
||||
unique_aspects: "Accessibility-first design with component library demonstration"
|
||||
```
|
||||
|
||||
## PRP Output Structure
|
||||
|
||||
For each POC, generate a complete PRP file:
|
||||
|
||||
**File:** `PRPs/working-memory/{feature-name}/poc-{problem-slug}-{variant}.md`
|
||||
|
||||
**Content Structure:**
|
||||
1. **Goal Section**: Specific to UI approach + User journey combination
|
||||
2. **POC Scope**: Tailored to the variation's unique focus
|
||||
3. **Context**: Incorporates both UI-UX and User Journey agent research
|
||||
4. **Implementation Blueprint**: Customized task sequence for the variant
|
||||
5. **Validation Loop**: POC-appropriate validation for the specific approach
|
||||
|
||||
## Parallel Execution Preparation
|
||||
|
||||
### Project Structure Setup
|
||||
|
||||
```
|
||||
react-poc-project/
|
||||
├── public/
|
||||
├── src/
|
||||
│ ├── poc-{problem-slug}-minimal-power/
|
||||
│ ├── poc-{problem-slug}-polished-casual/
|
||||
│ ├── poc-{problem-slug}-experimental-admin/
|
||||
│ ├── poc-{problem-slug}-dashboard-mobile/
|
||||
│ ├── poc-{problem-slug}-components-a11y/
|
||||
│ └── App.tsx # Main navigation between POCs
|
||||
├── package.json
|
||||
└── README.md
|
||||
```
|
||||
|
||||
### Main App Navigation
|
||||
|
||||
Each POC should be accessible from a main navigation page:
|
||||
|
||||
```tsx
|
||||
// App.tsx structure
|
||||
function App() {
|
||||
return (
|
||||
<Router>
|
||||
<Routes>
|
||||
<Route path="/" element={<POCNavigationHub />} />
|
||||
<Route path="/minimal-power" element={<POCMinimalPower />} />
|
||||
<Route path="/polished-casual" element={<POCPolishedCasual />} />
|
||||
<Route path="/experimental-admin" element={<POCExperimentalAdmin />} />
|
||||
<Route path="/dashboard-mobile" element={<POCDashboardMobile />} />
|
||||
<Route path="/components-a11y" element={<POCComponentsA11y />} />
|
||||
</Routes>
|
||||
</Router>
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
### Research Quality
|
||||
- [ ] **All agent pairs completed**: N UI-UX + N User Journey agents finished successfully
|
||||
- [ ] **Diverse approaches identified**: Each POC targets different aspects of problem
|
||||
- [ ] **Research synthesis complete**: Agent findings incorporated into PRP context
|
||||
- [ ] **Unique value propositions**: Each POC validates different assumptions
|
||||
|
||||
### PRP Quality
|
||||
- [ ] **N complete PRPs generated**: One for each POC variation
|
||||
- [ ] **Context completeness**: Each PRP enables one-pass implementation
|
||||
- [ ] **Validation approaches**: POC-appropriate testing for each variant
|
||||
- [ ] **Implementation clarity**: Clear task sequences for parallel development
|
||||
|
||||
### Parallel Readiness
|
||||
- [ ] **Unique naming**: All POCs have distinct identifiers and directories
|
||||
- [ ] **Isolated development**: POCs can be developed simultaneously without conflicts
|
||||
- [ ] **Shared infrastructure**: Common mock data and routing setup defined
|
||||
- [ ] **Execution ready**: All PRPs ready for parallel execution command
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
### Research Anti-Patterns
|
||||
- ❌ **Don't create identical approaches**: Ensure each POC explores different aspects
|
||||
- ❌ **Don't skip agent specialization**: Each agent should have distinct focus
|
||||
- ❌ **Don't generalize findings**: Customize context for each POC's unique approach
|
||||
- ❌ **Don't rush parallel research**: Let all agents complete before synthesis
|
||||
|
||||
### PRP Generation Anti-Patterns
|
||||
- ❌ **Don't copy-paste PRPs**: Each should be tailored to its unique approach
|
||||
- ❌ **Don't ignore agent research**: Incorporate all findings into appropriate PRPs
|
||||
- ❌ **Don't create conflicting requirements**: Ensure POCs can coexist in same project
|
||||
- ❌ **Don't skip validation customization**: Each POC needs appropriate testing approach
|
||||
|
||||
### DO Focus On
|
||||
- ✅ **Maximum concept coverage**: Each POC validates different aspects of the problem
|
||||
- ✅ **Specialized agent research**: Leverage UI-UX and User Journey expertise fully
|
||||
- ✅ **Parallel development readiness**: Structure for simultaneous implementation
|
||||
- ✅ **Stakeholder value**: Each POC provides unique insights for decision making
|
||||
|
||||
---
|
||||
|
||||
**Remember**: The goal is **comprehensive concept validation** through **diverse parallel approaches**. Each POC should explore the problem from a different angle, maximizing the insights available to stakeholders for informed decision-making.
|
||||
326
commands/prp-poc-execute-parallel.md
Normal file
326
commands/prp-poc-execute-parallel.md
Normal file
@@ -0,0 +1,326 @@
|
||||
# Execute Parallel React POCs
|
||||
|
||||
## POC Directory: $ARGUMENTS
|
||||
|
||||
Usage: `/prp-poc-execute-parallel [poc_directory_pattern]`
|
||||
Example: `/prp-poc-execute-parallel "PRPs/poc-dashboard-*"`
|
||||
|
||||
## Mission: Parallel POC Implementation Success
|
||||
|
||||
Transform multiple React POC PRPs into working demonstrations simultaneously through **coordinated parallel execution** using specialized UI/UX and User Journey agents.
|
||||
|
||||
**Critical Understanding**: Each POC requires specialized execution:
|
||||
- **UI-focused implementation** leveraging @ui-ux-agent expertise
|
||||
- **User journey validation** using @user-journey-agent insights
|
||||
- **Parallel development** without interference between POCs
|
||||
- **Coordinated validation** ensuring all POCs demonstrate successfully
|
||||
|
||||
## Parallel Execution Strategy
|
||||
|
||||
### Agent Orchestration Pattern
|
||||
|
||||
For **N POCs** discovered, create **N execution pairs**:
|
||||
- **N UI-UX Implementation Agents**: Each building the specific UI approach
|
||||
- **N User Journey Validation Agents**: Each ensuring journey flows work correctly
|
||||
|
||||
**Execution Agent Assignment:**
|
||||
```yaml
|
||||
POC 1: @ui-ux-agent (Build minimal/clean interface) + @user-journey-agent (Validate power user flows)
|
||||
POC 2: @ui-ux-agent (Build polished/professional interface) + @user-journey-agent (Validate casual user flows)
|
||||
POC 3: @ui-ux-agent (Build experimental/modern interface) + @user-journey-agent (Validate admin user flows)
|
||||
POC 4: @ui-ux-agent (Build dashboard/data-heavy interface) + @user-journey-agent (Validate mobile-first flows)
|
||||
POC 5: @ui-ux-agent (Build component-library interface) + @user-journey-agent (Validate accessibility flows)
|
||||
```
|
||||
|
||||
## Pre-Execution Setup
|
||||
|
||||
### Step 1: Environment Preparation
|
||||
|
||||
1. **Create Fresh React Project**
|
||||
```bash
|
||||
npx create-react-app react-poc-demos --template typescript
|
||||
cd react-poc-demos
|
||||
npm install react-router-dom @faker-js/faker msw
|
||||
npm install -D @types/react-router-dom
|
||||
```
|
||||
|
||||
2. **Discover POC PRPs**
|
||||
- Scan for POC PRP files matching the pattern
|
||||
- Extract POC specifications and requirements
|
||||
- Plan directory structure and routing
|
||||
|
||||
3. **Setup Project Structure**
|
||||
```
|
||||
src/
|
||||
├── components/
|
||||
│ └── shared/ # Shared components across POCs
|
||||
├── data/
|
||||
│ └── mocks/ # Shared mock data
|
||||
├── poc-{name}-{variant}/
|
||||
│ ├── components/ # POC-specific components
|
||||
│ ├── pages/ # POC-specific pages
|
||||
│ ├── hooks/ # POC-specific hooks
|
||||
│ └── styles/ # POC-specific styles
|
||||
└── App.tsx # Main navigation hub
|
||||
```
|
||||
|
||||
## Parallel Implementation Process
|
||||
|
||||
### Step 2: Simultaneous POC Development
|
||||
|
||||
**Execute all implementation pairs in PARALLEL using Task tool:**
|
||||
|
||||
```yaml
|
||||
# For each discovered POC, spawn specialized agent pair
|
||||
Task 1 - @ui-ux-agent Implementation for POC 1:
|
||||
"Read and implement PRP: 'PRPs/working-memory/{feature-name}/poc-{name}-{variant1}.md'
|
||||
Focus on: Building the UI components and styling specified in the PRP.
|
||||
Requirements:
|
||||
- Follow the UI approach defined in the PRP context
|
||||
- Implement all components with TypeScript interfaces
|
||||
- Apply the styling approach (minimal/clean as specified)
|
||||
- Create responsive layouts following the PRP requirements
|
||||
- Use mock data integration as specified
|
||||
Directory: src/poc-{name}-{variant1}/
|
||||
Return: Complete UI implementation with all components functional"
|
||||
|
||||
Task 2 - @user-journey-agent Validation for POC 1:
|
||||
"Read and validate PRP implementation: 'PRPs/working-memory/{feature-name}/poc-{name}-{variant1}.md'
|
||||
Focus on: Ensuring user journey flows work as specified in the PRP.
|
||||
Requirements:
|
||||
- Test all user interactions defined in the PRP
|
||||
- Validate navigation flows and state management
|
||||
- Ensure mock data scenarios cover user journey requirements
|
||||
- Test user flow completion from start to finish
|
||||
- Document any journey friction points discovered
|
||||
Directory: src/poc-{name}-{variant1}/
|
||||
Return: Journey validation report and any flow improvements needed"
|
||||
|
||||
Task 3 - @ui-ux-agent Implementation for POC 2:
|
||||
"Read and implement PRP: 'PRPs/working-memory/{feature-name}/poc-{name}-{variant2}.md'
|
||||
Focus on: Building the UI components and styling specified in the PRP.
|
||||
Requirements:
|
||||
- Follow the UI approach defined in the PRP context (polished/professional)
|
||||
- Implement all components with premium aesthetics
|
||||
- Create brand-aligned styling and professional presentation
|
||||
- Build stakeholder-ready demonstration interface
|
||||
- Integrate realistic mock data for presentations
|
||||
Directory: src/poc-{name}-{variant2}/
|
||||
Return: Complete UI implementation with professional polish"
|
||||
|
||||
Task 4 - @user-journey-agent Validation for POC 2:
|
||||
"Read and validate PRP implementation: 'PRPs/working-memory/{feature-name}/poc-{name}-{variant2}.md'
|
||||
Focus on: Ensuring casual user journey flows work intuitively.
|
||||
Requirements:
|
||||
- Test simplified navigation and guided experiences
|
||||
- Validate progressive disclosure and help systems
|
||||
- Ensure beginner-friendly interaction patterns work
|
||||
- Test complete user onboarding and guidance flows
|
||||
- Document usability for non-expert users
|
||||
Directory: src/poc-{name}-{variant2}/
|
||||
Return: Casual user validation report and usability assessment"
|
||||
|
||||
# Continue pattern for all discovered POCs...
|
||||
```
|
||||
|
||||
### Step 3: Main Navigation Implementation
|
||||
|
||||
**After all POCs are built, create navigation hub:**
|
||||
|
||||
```typescript
|
||||
// App.tsx - Main navigation between POCs
|
||||
import React from 'react'
|
||||
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom'
|
||||
import POCNavigationHub from './components/POCNavigationHub'
|
||||
|
||||
// Import all POC entry points (generated dynamically based on discovered POCs)
|
||||
const pocRoutes = [
|
||||
{ path: '/poc-1', component: lazy(() => import('./poc-{name}-{variant1}/pages/Demo')), title: 'Minimal Power User' },
|
||||
{ path: '/poc-2', component: lazy(() => import('./poc-{name}-{variant2}/pages/Demo')), title: 'Polished Casual User' },
|
||||
// ... additional routes for all POCs
|
||||
]
|
||||
|
||||
function App() {
|
||||
return (
|
||||
<Router>
|
||||
<Routes>
|
||||
<Route path="/" element={<POCNavigationHub pocs={pocRoutes} />} />
|
||||
{pocRoutes.map(({ path, component: Component }) => (
|
||||
<Route key={path} path={path} element={<Suspense><Component /></Suspense>} />
|
||||
))}
|
||||
</Routes>
|
||||
</Router>
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
### Step 4: Coordinated Validation
|
||||
|
||||
**Execute validation for all POCs simultaneously:**
|
||||
|
||||
1. **Technical Validation (All POCs)**
|
||||
```bash
|
||||
npm run lint # All POCs pass linting
|
||||
npm run type-check # All TypeScript errors resolved
|
||||
npm run build # Production build succeeds
|
||||
npm run test # All POC smoke tests pass
|
||||
```
|
||||
|
||||
2. **Functional Validation (Per POC)**
|
||||
- Each POC loads without errors
|
||||
- Core user journeys navigable in each POC
|
||||
- Mock data displays correctly in all variations
|
||||
- Navigation between POCs works seamlessly
|
||||
|
||||
3. **User Journey Validation (Agent-Specific)**
|
||||
- Power user flows efficient and feature-complete
|
||||
- Casual user flows intuitive and guided
|
||||
- Admin flows comprehensive and control-focused
|
||||
- Mobile flows touch-optimized and responsive
|
||||
- Accessibility flows screen reader compatible
|
||||
|
||||
## Coordination & Conflict Resolution
|
||||
|
||||
### Step 5: Integration Management
|
||||
|
||||
1. **Shared Resource Coordination**
|
||||
- Merge shared mock data without conflicts
|
||||
- Resolve common component naming conflicts
|
||||
- Integrate shared utilities and hooks
|
||||
- Coordinate routing and navigation structure
|
||||
|
||||
2. **Style Isolation**
|
||||
- Ensure POC-specific styles don't interfere
|
||||
- Use CSS modules or styled-components for isolation
|
||||
- Coordinate shared design system tokens
|
||||
- Resolve competing global styles
|
||||
|
||||
3. **Dependency Management**
|
||||
- Consolidate common dependencies
|
||||
- Resolve version conflicts between POC requirements
|
||||
- Optimize bundle size across all POCs
|
||||
- Manage shared vs POC-specific packages
|
||||
|
||||
## Final Validation & Demo Preparation
|
||||
|
||||
### Step 6: Comprehensive Testing
|
||||
|
||||
**Multi-POC Validation Checklist:**
|
||||
|
||||
**Technical Completeness:**
|
||||
- [ ] **All POCs Build Successfully**: No TypeScript or build errors across any POC
|
||||
- [ ] **Shared Infrastructure Works**: Navigation, routing, shared components functional
|
||||
- [ ] **Isolated Functionality**: Each POC operates independently without interference
|
||||
- [ ] **Performance Acceptable**: All POCs load and perform adequately for demos
|
||||
|
||||
**Feature Completeness:**
|
||||
- [ ] **All User Journeys Complete**: Each POC's primary user flow works end-to-end
|
||||
- [ ] **Specialized Approaches Visible**: Unique value propositions clear in each POC
|
||||
- [ ] **Mock Data Realistic**: All POCs display meaningful, realistic data scenarios
|
||||
- [ ] **Cross-POC Navigation**: Users can move between different POC approaches easily
|
||||
|
||||
**Business Validation:**
|
||||
- [ ] **Concept Differentiation Clear**: Each POC explores different aspects of the problem
|
||||
- [ ] **Stakeholder Demo Ready**: All POCs ready for comparative evaluation
|
||||
- [ ] **Findings Documentation**: Each POC's insights and limitations documented
|
||||
- [ ] **Next Steps Identified**: Production recommendations available for each approach
|
||||
|
||||
### Step 7: Demo Script Preparation
|
||||
|
||||
**Create demonstration script for stakeholder presentations:**
|
||||
|
||||
```markdown
|
||||
# POC Demonstration Script
|
||||
|
||||
## Introduction (2 minutes)
|
||||
- Problem statement overview
|
||||
- POC approach explanation
|
||||
- Navigation between different solutions
|
||||
|
||||
## POC 1: Minimal Power User (3 minutes)
|
||||
- Target audience: Expert users needing efficiency
|
||||
- Key features demonstration
|
||||
- Performance and workflow benefits
|
||||
|
||||
## POC 2: Polished Casual User (3 minutes)
|
||||
- Target audience: General users needing guidance
|
||||
- Guided experience demonstration
|
||||
- Ease of use and accessibility benefits
|
||||
|
||||
## POC 3: Experimental Admin (3 minutes)
|
||||
- Target audience: System administrators
|
||||
- Advanced controls demonstration
|
||||
- Management and oversight capabilities
|
||||
|
||||
## POC 4: Dashboard Mobile-First (3 minutes)
|
||||
- Target audience: Mobile-centric users
|
||||
- Data visualization demonstration
|
||||
- Touch interaction and responsive benefits
|
||||
|
||||
## POC 5: Component-Library Accessible (3 minutes)
|
||||
- Target audience: Inclusive design requirements
|
||||
- Accessibility features demonstration
|
||||
- Design system and consistency benefits
|
||||
|
||||
## Comparison & Recommendations (5 minutes)
|
||||
- Side-by-side feature comparison
|
||||
- User feedback integration
|
||||
- Production implementation recommendations
|
||||
```
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Implementation Success
|
||||
- [ ] **All POCs Functional**: Every discovered PRP implemented successfully
|
||||
- [ ] **Agent Specialization Effective**: UI-UX and User Journey agents delivered specialized results
|
||||
- [ ] **Parallel Development Efficient**: No conflicts or interference between concurrent implementations
|
||||
- [ ] **Validation Complete**: All POCs pass technical and functional validation
|
||||
|
||||
### Business Value Delivery
|
||||
- [ ] **Comprehensive Concept Coverage**: Problem explored from multiple angles successfully
|
||||
- [ ] **Clear Differentiation**: Each POC's unique value proposition demonstrated
|
||||
- [ ] **Stakeholder Ready**: All POCs ready for evaluation and feedback gathering
|
||||
- [ ] **Decision Support**: Sufficient information available for production approach selection
|
||||
|
||||
## Error Handling & Recovery
|
||||
|
||||
### Common Issues & Solutions
|
||||
|
||||
**Build Conflicts:**
|
||||
- Isolate POC-specific dependencies
|
||||
- Use namespace prefixes for shared utilities
|
||||
- Implement CSS-in-JS for style isolation
|
||||
|
||||
**Agent Coordination Issues:**
|
||||
- Re-assign failed implementations to backup agents
|
||||
- Merge partial implementations when agents complete successfully
|
||||
- Prioritize critical POCs if time constraints emerge
|
||||
|
||||
**Performance Issues:**
|
||||
- Lazy load POC components to improve initial page load
|
||||
- Optimize shared mock data generation
|
||||
- Implement code splitting at POC boundaries
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
### Execution Anti-Patterns
|
||||
- ❌ **Don't execute POCs sequentially**: Use parallel agent execution always
|
||||
- ❌ **Don't ignore agent specialization**: UI-UX and User Journey agents have distinct roles
|
||||
- ❌ **Don't rush validation**: Each POC needs proper testing and verification
|
||||
- ❌ **Don't skip integration testing**: Cross-POC navigation and shared resources need validation
|
||||
|
||||
### Coordination Anti-Patterns
|
||||
- ❌ **Don't allow POC interference**: Maintain isolation between implementations
|
||||
- ❌ **Don't duplicate shared logic**: Coordinate common utilities and mock data
|
||||
- ❌ **Don't ignore conflicts**: Resolve dependency and styling conflicts early
|
||||
- ❌ **Don't skip demo preparation**: Stakeholder presentation needs coordination
|
||||
|
||||
### DO Focus On
|
||||
- ✅ **Specialized agent utilization**: Leverage UI-UX and User Journey expertise fully
|
||||
- ✅ **Parallel execution efficiency**: Maximum development speed through coordination
|
||||
- ✅ **Cross-POC consistency**: Shared infrastructure and navigation experience
|
||||
- ✅ **Business value delivery**: Each POC provides unique insights for decision making
|
||||
|
||||
---
|
||||
|
||||
**Remember**: The goal is **successful parallel implementation** of multiple POC approaches that collectively provide **comprehensive concept validation** for stakeholder decision-making.
|
||||
121
commands/prp-spec-create.md
Normal file
121
commands/prp-spec-create.md
Normal file
@@ -0,0 +1,121 @@
|
||||
# Create SPEC PRP (Advanced)
|
||||
|
||||
Generate a comprehensive specification-driven PRP with clear transformation goals.
|
||||
|
||||
## Specification: $ARGUMENTS
|
||||
|
||||
## Analysis Process
|
||||
|
||||
1. **Current State Assessment**
|
||||
- Map existing implementation
|
||||
- Identify pain points
|
||||
- Document technical debt
|
||||
- Note integration points
|
||||
|
||||
2. **Desired State Research**
|
||||
- Best practices for target state
|
||||
- Implementation examples
|
||||
- Migration strategies
|
||||
- Risk assessment
|
||||
- Dependency mapping
|
||||
|
||||
3. **User Clarification**
|
||||
- Confirm transformation goals
|
||||
- Priority of objectives
|
||||
- Acceptable trade-offs
|
||||
|
||||
## PRP Generation
|
||||
|
||||
Using /PRPs/templates/prp_spec.md:
|
||||
|
||||
### State Documentation
|
||||
|
||||
```yaml
|
||||
current_state:
|
||||
files: [list affected files]
|
||||
behavior: [how it works now]
|
||||
issues: [specific problems]
|
||||
|
||||
desired_state:
|
||||
files: [expected structure]
|
||||
behavior: [target functionality]
|
||||
benefits: [improvements gained]
|
||||
```
|
||||
|
||||
### Hierarchical Objectives
|
||||
|
||||
1. **High-Level**: Overall transformation goal
|
||||
2. **Mid-Level**: Major milestones
|
||||
3. **Low-Level**: Specific tasks with validation
|
||||
|
||||
### Task Specification with information dense keywords
|
||||
|
||||
#### Information dense keywords:
|
||||
|
||||
- MIRROR: Mirror the state of existing code to be mirrored to another use case
|
||||
- COPY: Copy the state of existing code to be copied to another use case
|
||||
- ADD: Add new code to the codebase
|
||||
- MODIFY: Modify existing code
|
||||
- DELETE: Delete existing code
|
||||
- RENAME: Rename existing code
|
||||
- MOVE: Move existing code
|
||||
- REPLACE: Replace existing code
|
||||
- CREATE: Create new code
|
||||
|
||||
#### Example:
|
||||
|
||||
```yaml
|
||||
task_name:
|
||||
action: MODIFY/CREATE
|
||||
file: path/to/file
|
||||
changes: |
|
||||
- Specific modifications
|
||||
- Implementation details
|
||||
- With clear markers
|
||||
validation:
|
||||
- command: "test command"
|
||||
- expect: "success criteria"
|
||||
```
|
||||
|
||||
### Implementation Strategy
|
||||
|
||||
- Identify dependencies
|
||||
- Order tasks by priority and implementation order and dependencies logic
|
||||
- Include rollback plans
|
||||
- Progressive enhancement
|
||||
|
||||
## User Interaction Points
|
||||
|
||||
1. **Objective Validation**
|
||||
- Review hierarchical breakdown
|
||||
- Confirm priorities
|
||||
- Identify missing pieces
|
||||
|
||||
2. **Risk Review**
|
||||
- Document identified risks
|
||||
- Find mitigations
|
||||
- Set go/no-go criteria
|
||||
|
||||
## Context Requirements
|
||||
|
||||
- Current implementation details
|
||||
- Target architecture examples
|
||||
- Migration best practices
|
||||
- Testing strategies
|
||||
|
||||
## Output
|
||||
|
||||
Save as: `SPEC_PRP/PRPs/{spec-name}.md`
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
- [ ] Current state fully documented
|
||||
- [ ] Desired state clearly defined
|
||||
- [ ] All objectives measurable
|
||||
- [ ] Tasks ordered by dependency
|
||||
- [ ] Each task has validation that AI can run
|
||||
- [ ] Risks identified with mitigations
|
||||
- [ ] Rollback strategy included
|
||||
- [ ] Integration points noted
|
||||
|
||||
Remember: Focus on the transformation journey, not just the destination.
|
||||
30
commands/prp-spec-execute.md
Normal file
30
commands/prp-spec-execute.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Execute SPEC PRP
|
||||
|
||||
Implement a specification using an existing SPEC PRP.
|
||||
|
||||
## PRP File: $ARGUMENTS
|
||||
|
||||
## Execution Process
|
||||
|
||||
1. **Understand Spec**
|
||||
- Current state analysis
|
||||
- Desired state goals
|
||||
- Task dependencies
|
||||
|
||||
2. **ULTRATHINK**
|
||||
- Think hard before you execute the plan. Create a comprehensive plan addressing all requirements.
|
||||
- Break down complex tasks into smaller, manageable steps using your todos tools.
|
||||
- Use the TodoWrite tool to create and track your implementation plan.
|
||||
- Identify implementation patterns from existing code to follow.
|
||||
|
||||
3. **Execute Tasks**
|
||||
- Follow task order
|
||||
- Run validation after each
|
||||
- Fix failures before proceeding
|
||||
|
||||
4. **Verify Transformation**
|
||||
- Confirm desired state achieved
|
||||
- Run all validation gates
|
||||
- Test integration
|
||||
|
||||
Progress through each objective systematically.
|
||||
142
commands/prp-story-create.md
Normal file
142
commands/prp-story-create.md
Normal file
@@ -0,0 +1,142 @@
|
||||
---
|
||||
description: "Convert user story/task into executable PRP with deep codebase analysis"
|
||||
---
|
||||
|
||||
# Create Story PRP from User Story/Task
|
||||
|
||||
## Story/Task: $ARGUMENTS
|
||||
|
||||
## Mission
|
||||
|
||||
Transform a user story or task into a **tactical implementation PRP** through systematic codebase analysis and task decomposition.
|
||||
|
||||
We do not write any code in this step, the goal is to create a detailed context engineered implementation plan for the implementation agent.
|
||||
|
||||
**Key Principle**: We must first gather the context about the story/task before proceeding with the analysis.
|
||||
|
||||
When we understand the story/task, we can proceed with the codebase analysis. We systematically dig deep into the codebase to gather intelligence and identify patterns and implementation points. We then use this information to create a PRP that can be executed by a coding agent.
|
||||
|
||||
The contents of the created PRP should encapsulate all the information the agent needs to complete the story/task in one pass.
|
||||
|
||||
Remember that subagents will only receive their details from you, the user has no way of interacting with the subagents. so you need to share all the relevant context to the subagent in the subagent prompt and in the TODO that is shared with the particular agent.
|
||||
|
||||
Create detailed todos and spawn parallel subagents to analyze (Use specialized subagents when apropriate):
|
||||
|
||||
## Analysis Process
|
||||
|
||||
### Phase 1: Story Decomposition
|
||||
|
||||
Analyze the story to determine:
|
||||
|
||||
- **Story/Task Type**: Feature/Bug/Enhancement/Refactor
|
||||
- **Complexity**: Low, Medium, High
|
||||
- **Affected Systems**: Which components/services need changes
|
||||
|
||||
Get a deep understanding about the story/task before proceeding so that you can effectively guide the rest of the process.
|
||||
|
||||
### Phase 2: Codebase Intelligence Gathering
|
||||
|
||||
**1. Project Structure Analysis**
|
||||
|
||||
- Detect primary language(s) and frameworks
|
||||
- Map directory structure and conventions to identify integration points for the story/task
|
||||
- Identify service/component boundaries
|
||||
- Find configuration files and environment setup
|
||||
|
||||
**2. Pattern Recognition**
|
||||
|
||||
- Search for similar implementations in codebase
|
||||
- Identify coding conventions (naming, structure, error handling) start in CLAUDE.md AGENTS.md or relevant rules files such as .cursorrules
|
||||
- Extract common patterns for the story's domain that should be added to the PRP as context for the implementation agent.
|
||||
- Note anti-patterns to avoid
|
||||
|
||||
**3. Dependency Analysis**
|
||||
|
||||
- Catalog external libraries used if relevant to the story/task (check package.json, pyproject.toml, go.mod, etc.)
|
||||
- Understand how libraries are integrated
|
||||
- Find relevant documentation in PRPs/ai_docs/ if shared, ai_docs directory is used by the user to paste in relevant additional context that may be relevant to our story/task
|
||||
|
||||
**4. Testing Patterns**
|
||||
|
||||
- Identify test framework and structure
|
||||
- Find similar test examples and test setup
|
||||
- Suggest test cases and scenarios
|
||||
|
||||
**5. Integration Points**
|
||||
|
||||
- Identify files that will need updates
|
||||
- Identify if new files needs to be created and where to create them
|
||||
- Find router/API registration patterns
|
||||
- Understand database/model patterns if relevant
|
||||
|
||||
### Phase 3: Think harder about the story and its components.
|
||||
|
||||
Really think hard about everything you just learned during the research phases.
|
||||
|
||||
### Phase 4: PRP Task Generation
|
||||
|
||||
Transform analysis into concrete tasks:
|
||||
|
||||
Read and understand the template @PRPs/templates/prp_story_task.md
|
||||
|
||||
**Task Rules**:
|
||||
|
||||
1. Each task is atomic and independently testable
|
||||
2. Tasks are ordered by dependency
|
||||
3. Use action verbs that are information dense: CREATE, UPDATE, ADD, REMOVE, REFACTOR, MIRROR
|
||||
4. Include specific implementation details from codebase analysis
|
||||
5. Every task has an executable validation command
|
||||
|
||||
**Task Action Types**:
|
||||
|
||||
We use the concept of information dense keywords to describe the action to be taken, below is a guidance.
|
||||
But you can use your own words to describe the action to be taken as long as you follow this same principle.
|
||||
|
||||
Examples:
|
||||
|
||||
- **CREATE**: New files/components
|
||||
- **UPDATE**: Modify existing files
|
||||
- **ADD**: Insert new functionality into existing code
|
||||
- **REMOVE**: Delete deprecated code
|
||||
- **REFACTOR**: Restructure without changing behavior
|
||||
- **MIRROR**: Mirror existing pattern or functionality that exists elsewhere in the codebase
|
||||
|
||||
### Phase 5: Validation Design
|
||||
|
||||
For each task, design validation that:
|
||||
|
||||
- Can run immediately after task completion
|
||||
- Provides clear pass/fail feedback
|
||||
- Uses project-specific commands discovered in analysis
|
||||
|
||||
## Quality Criteria
|
||||
|
||||
### Task Clarity
|
||||
|
||||
- [ ] The PRP is clear and concise and follows KISS principle
|
||||
- [ ] Each task has clear action and target
|
||||
- [ ] Implementation details reference specific patterns
|
||||
- [ ] Validation commands are executable
|
||||
|
||||
### Context Completeness
|
||||
|
||||
- [ ] All necessary patterns identified
|
||||
- [ ] External library usage documented
|
||||
- [ ] Integration points mapped
|
||||
- [ ] External context references populated
|
||||
|
||||
### Story Coverage
|
||||
|
||||
- [ ] All acceptance criteria addressed
|
||||
- [ ] Edge cases considered
|
||||
- [ ] Error handling included where needed
|
||||
|
||||
## Output
|
||||
|
||||
Save as: `PRPs/working-memory/{feature-name}/story_{kebab-case-summary}.md`
|
||||
|
||||
## Success Metrics
|
||||
|
||||
**Implementation Ready**: Another developer could execute these tasks without additional context
|
||||
**Validation Complete**: Every task has atleast one working validation command
|
||||
**Pattern Consistent**: Tasks follow existing codebase conventions
|
||||
95
commands/prp-story-execute.md
Normal file
95
commands/prp-story-execute.md
Normal file
@@ -0,0 +1,95 @@
|
||||
---
|
||||
description: "Execute a Story PRP with focused task implementation"
|
||||
---
|
||||
|
||||
# Execute Story PRP
|
||||
|
||||
## PRP File: $ARGUMENTS
|
||||
|
||||
## Mission
|
||||
|
||||
Execute a story/task PRP through **sequential task completion** with immediate validation.
|
||||
|
||||
**Execution Philosophy**: Complete one task, validate it, then move to the next. No task left behind.
|
||||
|
||||
## Execution Process
|
||||
|
||||
### 1. Load Story PRP
|
||||
|
||||
- Read the specified story PRP file
|
||||
- Understand the original story intent
|
||||
- Review all context references
|
||||
- Note validation commands for each task
|
||||
|
||||
### 2. Pre-Implementation Check
|
||||
|
||||
- Ultrathink about the story intent and task requirements
|
||||
- Verify all referenced files exist
|
||||
- Check that patterns mentioned are accessible
|
||||
- Ensure development environment is ready
|
||||
- Run any pre-requisite setup commands
|
||||
|
||||
### 3. Task-by-Task Implementation
|
||||
|
||||
For each task in the PRP:
|
||||
|
||||
**a) Understand Task**
|
||||
|
||||
- Read task requirements completely
|
||||
- Review referenced patterns
|
||||
- Check gotchas and constraints
|
||||
|
||||
**b) Implement Task**
|
||||
|
||||
- Follow the specified pattern
|
||||
- Use the indicated naming conventions
|
||||
- Apply the documented approach
|
||||
- Handle edge cases mentioned
|
||||
|
||||
**c) Validate Immediately**
|
||||
|
||||
- Run the task's validation command
|
||||
- If validation fails, fix and re-validate
|
||||
- Don't proceed until current task passes
|
||||
|
||||
**d) Mark Complete**
|
||||
|
||||
- Update todo list to track progress
|
||||
- Document any deviations if necessary
|
||||
|
||||
### 4. Full Validation
|
||||
|
||||
After all tasks complete:
|
||||
|
||||
- Run the validation gates from PRP
|
||||
- Execute comprehensive test suite
|
||||
- Verify all acceptance criteria met
|
||||
|
||||
### 5. Completion
|
||||
|
||||
- Work through completion checklist
|
||||
- Ensure story requirements satisfied
|
||||
- Move completed PRP to PRPs/completed/{feature-name}/ create the folder if it does not exist
|
||||
|
||||
## Execution Rules
|
||||
|
||||
**Validation Gates**: Each task must pass validation, iterate until passed
|
||||
**Pattern Adherence**: Follow existing patterns, don't create new ones
|
||||
**No Shortcuts**: Complete all validation steps
|
||||
|
||||
## Failure Handling
|
||||
|
||||
When a task fails validation:
|
||||
|
||||
1. Read the error message carefully
|
||||
2. Check the pattern reference again
|
||||
3. Validate it by investigating the codebase
|
||||
4. Fix and re-validate
|
||||
5. If stuck, check similar implementations
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- Every validation command passes
|
||||
- Full test suite green
|
||||
- Story acceptance criteria met
|
||||
- Code follows project conventions
|
||||
108
commands/prp-task-create.md
Normal file
108
commands/prp-task-create.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# Create TASK PRP (Advanced)
|
||||
|
||||
Generate a comprehensive task list for focused changes with validation.
|
||||
|
||||
## Task: $ARGUMENTS
|
||||
|
||||
## Analysis Process
|
||||
|
||||
1. **Scope Definition**
|
||||
- Identify all affected files
|
||||
- Map dependencies
|
||||
- Check for side effects
|
||||
- Note test coverage
|
||||
|
||||
2. **Pattern Research**
|
||||
- Find similar changes in history
|
||||
- Identify conventions to follow
|
||||
- Check for helper functions
|
||||
- Review test patterns
|
||||
|
||||
3. **User Clarification**
|
||||
- Confirm change scope
|
||||
- Verify acceptance criteria
|
||||
- Check deployment considerations
|
||||
- Identify blockers
|
||||
|
||||
## PRP Generation
|
||||
|
||||
**READ**
|
||||
Using TASK_PRP/PRPs/prp_task.md format:
|
||||
|
||||
### Context Section
|
||||
|
||||
```yaml
|
||||
context:
|
||||
docs:
|
||||
- url: [API documentation]
|
||||
focus: [specific methods]
|
||||
|
||||
patterns:
|
||||
- file: existing/example.py
|
||||
copy: [pattern to follow]
|
||||
|
||||
gotchas:
|
||||
- issue: "Library requires X"
|
||||
fix: "Always do Y first"
|
||||
```
|
||||
|
||||
### Task Structure
|
||||
|
||||
```
|
||||
ACTION path/to/file:
|
||||
- OPERATION: [specific change]
|
||||
- VALIDATE: [test command]
|
||||
- IF_FAIL: [debug strategy]
|
||||
- ROLLBACK: [undo approach]
|
||||
```
|
||||
|
||||
### Task Sequencing
|
||||
|
||||
1. **Setup Tasks**: Prerequisites
|
||||
2. **Core Changes**: Main modifications
|
||||
3. **Integration**: Connect components
|
||||
4. **Validation**: Comprehensive tests
|
||||
5. **Cleanup**: Remove temp code
|
||||
|
||||
### Validation Strategy
|
||||
|
||||
- Unit test after each change
|
||||
- Integration test after groups
|
||||
- Performance check if relevant
|
||||
- Security scan for sensitive areas
|
||||
|
||||
## User Interaction Points
|
||||
|
||||
1. **Task Review**
|
||||
- Confirm task breakdown
|
||||
- Validate sequencing
|
||||
- Check completeness
|
||||
|
||||
2. **Risk Assessment**
|
||||
- Review potential impacts
|
||||
- Confirm rollback approach
|
||||
- Set success criteria
|
||||
|
||||
## Critical Elements
|
||||
|
||||
- Include debug patterns
|
||||
- Add performance checks
|
||||
- Note security concerns
|
||||
- Document assumptions
|
||||
|
||||
## Output
|
||||
|
||||
Save as: `TASK_PRP/PRPs/working-memory/{feature-name}/{task-name}.md`
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
- [ ] All changes identified
|
||||
- [ ] Dependencies mapped
|
||||
- [ ] Each task has validation
|
||||
- [ ] Rollback steps included
|
||||
- [ ] Debug strategies provided
|
||||
- [ ] Performance impact noted
|
||||
- [ ] Security checked
|
||||
- [ ] No missing edge cases
|
||||
|
||||
Remember: Small, focused changes with immediate validation.
|
||||
23
commands/prp-task-execute.md
Normal file
23
commands/prp-task-execute.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Execute TASK PRP
|
||||
|
||||
Run through a task list from an existing TASK PRP.
|
||||
|
||||
## PRP File: $ARGUMENTS
|
||||
|
||||
## Execution Process
|
||||
|
||||
1. **Load Tasks**
|
||||
- Read task list
|
||||
- Understand context
|
||||
|
||||
2. **Execute Each Task**
|
||||
- Perform ACTION
|
||||
- Run VALIDATE
|
||||
- Fix IF_FAIL issues
|
||||
|
||||
3. **Complete Checklist**
|
||||
- Verify all tasks done
|
||||
- Run final validation
|
||||
- Check no regressions
|
||||
|
||||
Work through tasks sequentially, validating each.
|
||||
117
commands/prp-ts-create.md
Normal file
117
commands/prp-ts-create.md
Normal file
@@ -0,0 +1,117 @@
|
||||
# Create TypeScript PRP
|
||||
|
||||
## Feature: $ARGUMENTS
|
||||
|
||||
## PRP Creation Mission
|
||||
|
||||
Create a comprehensive TypeScript PRP that enables **one-pass implementation success** through systematic research and context curation.
|
||||
|
||||
**Critical Understanding**: The executing AI agent only receives:
|
||||
|
||||
- Start by reading and understanding the prp concepts PRPs/README.md
|
||||
- The PRP content you create
|
||||
- Its training data knowledge
|
||||
- Access to codebase files (but needs guidance on which ones)
|
||||
|
||||
**Therefore**: Your research and context curation directly determines implementation success. Incomplete context = implementation failure.
|
||||
|
||||
## Research Process
|
||||
|
||||
> During the research process, create clear tasks and spawn as many agents and subagents as needed using the batch tools. The deeper research we do here the better the PRP will be. we optminize for chance of success and not for speed.
|
||||
|
||||
1. **TypeScript/React Codebase Analysis in depth**
|
||||
- Create clear todos and spawn subagents to search the codebase for similar features/patterns Think hard and plan your approach
|
||||
- Identify all the necessary TypeScript files to reference in the PRP
|
||||
- Note all existing TypeScript/React conventions to follow
|
||||
- Check existing component patterns, hook patterns, and API route patterns
|
||||
- Analyze TypeScript interface definitions and type usage patterns
|
||||
- Check existing test patterns for React components and TypeScript code validation approach
|
||||
- Use the batch tools to spawn subagents to search the codebase for similar features/patterns
|
||||
|
||||
2. **TypeScript/React External Research at scale**
|
||||
- Create clear todos and spawn with instructions subagents to do deep research for similar features/patterns online and include urls to documentation and examples
|
||||
- TypeScript documentation (include specific URLs with version compatibility)
|
||||
- React/Next.js documentation (include specific URLs for App Router, Server Components, etc.)
|
||||
- For critical pieces of documentation add a .md file to PRPs/ai_docs and reference it in the PRP with clear reasoning and instructions
|
||||
- Implementation examples (GitHub/StackOverflow/blogs) specific to TypeScript/React/Next.js
|
||||
- Best practices and common pitfalls found during research (TypeScript compilation issues, React hydration, Next.js gotchas)
|
||||
- Use the batch tools to spawn subagents to search for similar features/patterns online and include urls to documentation and examples
|
||||
|
||||
3. **User Clarification**
|
||||
- Ask for clarification if you need it
|
||||
|
||||
## PRP Generation Process
|
||||
|
||||
### Step 1: Choose Template
|
||||
|
||||
Use `PRPs/templates/prp_base_typescript.md` as your template structure - it contains all necessary sections and formatting specific to TypeScript/React development.
|
||||
|
||||
### Step 2: Context Completeness Validation
|
||||
|
||||
Before writing, apply the **"No Prior Knowledge" test** from the template:
|
||||
_"If someone knew nothing about this TypeScript/React codebase, would they have everything needed to implement this successfully?"_
|
||||
|
||||
### Step 3: Research Integration
|
||||
|
||||
Transform your research findings into the template sections:
|
||||
|
||||
**Goal Section**: Use research to define specific, measurable Feature Goal and concrete Deliverable (component, API route, integration, etc.)
|
||||
**Context Section**: Populate YAML structure with your research findings - specific TypeScript/React URLs, file patterns, gotchas
|
||||
**Implementation Tasks**: Create dependency-ordered tasks using information-dense keywords from TypeScript/React codebase analysis
|
||||
**Validation Gates**: Use TypeScript/React-specific validation commands that you've verified work in this codebase
|
||||
|
||||
### Step 4: TypeScript/React Information Density Standards
|
||||
|
||||
Ensure every reference is **specific and actionable** for TypeScript development:
|
||||
|
||||
- URLs include section anchors, not just domain names (React docs, TypeScript handbook, Next.js docs)
|
||||
- File references include specific TypeScript patterns to follow (interfaces, component props, hook patterns)
|
||||
- Task specifications include exact TypeScript naming conventions and placement (PascalCase components, camelCase props, etc.)
|
||||
- Validation commands are TypeScript/React-specific and executable (tsc, eslint with TypeScript rules, React Testing Library)
|
||||
|
||||
### Step 5: ULTRATHINK Before Writing
|
||||
|
||||
After research completion, create comprehensive PRP writing plan using TodoWrite tool:
|
||||
|
||||
- Plan how to structure each template section with your TypeScript/React research findings
|
||||
- Identify gaps that need additional TypeScript/React research
|
||||
- Create systematic approach to filling template with actionable TypeScript context
|
||||
- Consider TypeScript compilation dependencies and React component hierarchies
|
||||
|
||||
## Output
|
||||
|
||||
Save as: `PRPs/{feature-name}.md`
|
||||
|
||||
## TypeScript PRP Quality Gates
|
||||
|
||||
### Context Completeness Check
|
||||
|
||||
- [ ] Passes "No Prior Knowledge" test from TypeScript template
|
||||
- [ ] All YAML references are specific and accessible (TypeScript/React docs, component examples)
|
||||
- [ ] Implementation tasks include exact TypeScript naming and placement guidance
|
||||
- [ ] Validation commands are TypeScript/React-specific and verified working
|
||||
- [ ] TypeScript interface definitions and component prop types are specified
|
||||
|
||||
### Template Structure Compliance
|
||||
|
||||
- [ ] All required TypeScript template sections completed
|
||||
- [ ] Goal section has specific Feature Goal, Deliverable, Success Definition
|
||||
- [ ] Implementation Tasks follow TypeScript dependency ordering (types → components → pages → tests)
|
||||
- [ ] Final Validation Checklist includes TypeScript/React-specific validation
|
||||
|
||||
### TypeScript/React Information Density Standards
|
||||
|
||||
- [ ] No generic references - all are specific to TypeScript/React patterns
|
||||
- [ ] File patterns include specific TypeScript examples to follow (interfaces, components, hooks)
|
||||
- [ ] URLs include section anchors for exact TypeScript/React guidance
|
||||
- [ ] Task specifications use information-dense keywords from TypeScript/React codebase
|
||||
- [ ] Component patterns specify Server vs Client component usage
|
||||
- [ ] Type definitions are comprehensive and follow existing patterns
|
||||
|
||||
## Success Metrics
|
||||
|
||||
**Confidence Score**: Rate 1-10 for one-pass TypeScript implementation success likelihood
|
||||
|
||||
**Quality Standard**: Minimum 8/10 required before PRP approval
|
||||
|
||||
**Validation**: The completed PRP should enable an AI agent unfamiliar with the TypeScript/React codebase to implement the feature successfully using only the PRP content and codebase access, with full type safety and React best practices.
|
||||
66
commands/prp-ts-execute.md
Normal file
66
commands/prp-ts-execute.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# Execute TypeScript PRP
|
||||
|
||||
## PRP File: $ARGUMENTS
|
||||
|
||||
## Mission: One-Pass TypeScript Implementation Success
|
||||
|
||||
PRPs enable working TypeScript/React code on the first attempt through:
|
||||
|
||||
- **Context Completeness**: Everything needed, nothing guessed
|
||||
- **Progressive Validation**: 4-level gates catch errors early
|
||||
- **Pattern Consistency**: Follow existing TypeScript/React codebase approaches
|
||||
- **Type Safety**: Leverage TypeScript's compile-time error detection
|
||||
- Read PRPs/README.md to understand PRP concepts
|
||||
|
||||
**Your Goal**: Transform the PRP into working TypeScript code that passes all validation gates and maintains type safety.
|
||||
|
||||
## Execution Process
|
||||
|
||||
1. **Load PRP**
|
||||
- Read the specified TypeScript PRP file completely
|
||||
- Absorb all context, patterns, requirements and gather codebase intelligence
|
||||
- Use the provided documentation references and file patterns, consume the right documentation before the appropriate todo/task
|
||||
- Trust the PRP's context and guidance - it's designed for one-pass success
|
||||
- If needed do additional codebase exploration and research as needed
|
||||
- Pay special attention to TypeScript interfaces, component patterns, and Next.js App Router structure
|
||||
|
||||
2. **ULTRATHINK & Plan**
|
||||
- Create comprehensive implementation plan following the PRP's task order
|
||||
- Break down into clear todos using TodoWrite tool
|
||||
- Use subagents for parallel work when beneficial (always create prp inspired prompts for subagents when used)
|
||||
- Follow the TypeScript/React patterns referenced in the PRP
|
||||
- Use specific file paths, interface names, component names, and type definitions from PRP context
|
||||
- Never guess - always verify the codebase patterns and examples referenced in the PRP yourself
|
||||
- Consider TypeScript compilation dependencies (types before components, components before pages)
|
||||
|
||||
3. **Execute Implementation**
|
||||
- Follow the PRP's Implementation Tasks sequence, add more detail as needed, especially when using subagents
|
||||
- Use the TypeScript/React patterns and examples referenced in the PRP
|
||||
- Create files in locations specified by the desired codebase tree
|
||||
- Apply TypeScript naming conventions from the task specifications and CLAUDE.md
|
||||
- Ensure proper TypeScript typing throughout (interfaces, props, return types)
|
||||
- Follow Next.js App Router patterns for file-based routing
|
||||
|
||||
4. **Progressive Validation**
|
||||
|
||||
**Execute the 4-level validation system from the TypeScript PRP:**
|
||||
- **Level 1**: Run TypeScript syntax & style validation commands from PRP (ESLint, tsc, Prettier)
|
||||
- **Level 2**: Execute component and hook unit test validation from PRP
|
||||
- **Level 3**: Run Next.js integration testing commands from PRP (dev server, API routes, production build)
|
||||
- **Level 4**: Execute TypeScript/React-specific validation from PRP (E2E, performance, accessibility)
|
||||
|
||||
**Each level must pass before proceeding to the next.**
|
||||
|
||||
5. **Completion Verification**
|
||||
- Work through the Final Validation Checklist in the PRP
|
||||
- Verify all Success Criteria from the "What" section are met
|
||||
- Confirm all Anti-Patterns were avoided (especially TypeScript/React-specific ones)
|
||||
- Verify TypeScript compilation is successful with no errors
|
||||
- Ensure proper Server/Client component separation if using Next.js
|
||||
- Implementation is ready and working with full type safety
|
||||
|
||||
**Failure Protocol**: When validation fails, use the TypeScript/React patterns and gotchas from the PRP to fix issues, then re-run validation until passing. Pay special attention to:
|
||||
- TypeScript compilation errors and type mismatches
|
||||
- React hydration issues between server and client
|
||||
- Next.js App Router specific requirements
|
||||
- Component prop interface violations
|
||||
36
commands/task-list-init.md
Normal file
36
commands/task-list-init.md
Normal file
@@ -0,0 +1,36 @@
|
||||
claude
|
||||
\*\* Create a comprehensive task list in PRPs/checklist.md for PRP $ARGIMENTS
|
||||
|
||||
Ingest the infomration then dig deep into our existing codebase and PRP, When done ->
|
||||
|
||||
ULTRATHINK about the PRP task and create the plan based adhering to claude.md and extract and refine detailed tasks following this principle:
|
||||
|
||||
### list of tasks to be completed to fullfill the PRP in the order they should be completed using infomration dense keywords
|
||||
|
||||
- Infomration dense keyword examples:
|
||||
ADD, CREATE, MODIFY, MIRROR, FIND, EXECUTE, KEEP, PRESERVE etc
|
||||
|
||||
Mark done tasks with: STATUS [DONE], if not done leave empty
|
||||
|
||||
```yaml
|
||||
Task 1:
|
||||
STATUS [ ]
|
||||
MODIFY src/existing_module.py:
|
||||
- FIND pattern: "class OldImplementation"
|
||||
- INJECT after line containing "def __init__"
|
||||
- PRESERVE existing method signatures
|
||||
|
||||
STATUS [ ]
|
||||
CREATE src/new_feature.py:
|
||||
- MIRROR pattern from: src/similar_feature.py
|
||||
- MODIFY class name and core logic
|
||||
- KEEP error handling pattern identical
|
||||
|
||||
...(...)
|
||||
|
||||
Task N:
|
||||
...
|
||||
|
||||
```
|
||||
|
||||
Each task should have unit test coverage, make tests pass on each task
|
||||
109
plugin.lock.json
Normal file
109
plugin.lock.json
Normal file
@@ -0,0 +1,109 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:rpiplewar/shipfaster:prp",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "954076a061ce15a28d40db5cc17f0fd854146c46",
|
||||
"treeHash": "c2bf9d2c8820af5fb4549dbb27fbac78981e0a818da8be0e92501865114abbca",
|
||||
"generatedAt": "2025-11-28T10:28:02.999702Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "prp",
|
||||
"description": "A plugin to help you plan and execute in one shot",
|
||||
"version": "1.0.1"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "81b0bde63b2b2111076fc3715c74950216b189f7627d1eb6c24596a1f9d48562"
|
||||
},
|
||||
{
|
||||
"path": "agents/codebase-analyst.md",
|
||||
"sha256": "6dabc573de1a9c7265a9b1c5226c889b0f76497e134df19f9d695830255b26f6"
|
||||
},
|
||||
{
|
||||
"path": "agents/library-researcher.md",
|
||||
"sha256": "0b10ef636739c4d56a2053cfe3a3b11eef44481446a4119c63fb6dd1a010d71d"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "24a4872de6f6a1a8ac753f26836953707fcf2e78d0e311246c24c5531fc8a523"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-spec-create.md",
|
||||
"sha256": "32683bd279bc2d5326586da2e7776704dd66b2d9fdd7c8d2dee28767cb1b1cdc"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-poc-create-parallel.md",
|
||||
"sha256": "0b204b06b2f34a149864919fd8692406c89fe3f7aaa0020801c70dbf94394c63"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-ts-execute.md",
|
||||
"sha256": "72391be95f8676d11f53d4e2b29cfef98d95284e0bf201cd61d00b21760a464c"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-planning-create.md",
|
||||
"sha256": "831b9122b3eddb71c1bd8d6b71161efadb90d2de213693a7212cd5af12ecf34a"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-story-create.md",
|
||||
"sha256": "45200c4607294f4495e690ebdff967be1dff503ad0359018e19e32d283eda6ac"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-task-execute.md",
|
||||
"sha256": "abb35b791497bd27c8ad34079fb2101bc6ff32c3305ff92119668a19c5ef5a68"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-task-create.md",
|
||||
"sha256": "75a98d1f8889c817bc1de5729a7fe6c6d6bda1d4073465105417c15cd4670275"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-base-create.md",
|
||||
"sha256": "425f764f7cf575dcc9c15614b2a6c5fdcdd95d6eff28653d3c5c848bcc11e584"
|
||||
},
|
||||
{
|
||||
"path": "commands/task-list-init.md",
|
||||
"sha256": "4676d8d3d7e347173500b4a2c63a61d62b50f3a2e3d309f0cf59beb643041f40"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-spec-execute.md",
|
||||
"sha256": "2f6ea6010acb12fc82ec9ad7c0595c45c069e29f158ba207d736b40a437bd96e"
|
||||
},
|
||||
{
|
||||
"path": "commands/api-contract-define.md",
|
||||
"sha256": "58578d9e38c8d8b13609c12c83971d6d191d6f6fbaaf1a3b9f13a1594e5ae17e"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-poc-execute-parallel.md",
|
||||
"sha256": "8adc7e59c306f23c24870e637c4b98d0707a435f32187bda3c7805ba98b5b37d"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-story-execute.md",
|
||||
"sha256": "350dca83ede865640acc26511e4930c5c6c37b2b4604831b666992a8701b952f"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-ts-create.md",
|
||||
"sha256": "e9de3564956648e3d9c9f947a73f5ebf510e858991cac35a9a2791b82d26d684"
|
||||
},
|
||||
{
|
||||
"path": "commands/prp-base-execute.md",
|
||||
"sha256": "55ffb5838b890fac8b9620b56fb68e3ae18d1bc9c24d9be8d3d31bbf031be127"
|
||||
}
|
||||
],
|
||||
"dirSha256": "c2bf9d2c8820af5fb4549dbb27fbac78981e0a818da8be0e92501865114abbca"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user