Purpose
The prp-generator skill provides structured templates and methods for creating comprehensive Product Requirements Prompt (PRP) documents. PRPs serve as the primary input for Phase 3 (Implementation), containing all design information, library documentation, dependencies, implementation plans, testing strategies, and success criteria needed to implement features.
When to Use
This skill auto-activates when you:
-
Generate PRP documents from synthesized design
-
Create implementation guidance from architectural design
-
Structure design information for implementation phase
-
Define implementation plans with step-by-step guidance
-
Specify testing strategies and success criteria
-
Document architecture, libraries, and dependencies for implementers
Provided Capabilities
- Structured PRP Generation
-
Standard Template: Consistent PRP structure across all features
-
Section Templates: Pre-defined templates for each PRP section
-
Completeness Checking: Ensure all required sections present
-
Format Validation: Validate markdown structure and linking
- Implementation Planning
-
Phased Approach: Break implementation into logical phases
-
Step-by-Step Guidance: Detailed steps within each phase
-
Dependency Ordering: Ensure dependencies installed before use
-
Validation Checkpoints: Define validation at each phase
- Testing Strategy Documentation
-
Test Types: Unit, integration, end-to-end testing approaches
-
Test Coverage: Specify coverage targets per component
-
Mock Strategies: Document how to mock library dependencies
-
Test Data: Provide test data and fixture guidance
- Success Criteria Definition
-
Acceptance Criteria: Map from requirements analysis
-
Implementation Criteria: Code-level success criteria
-
Testing Criteria: Test coverage and passing requirements
-
Documentation Criteria: Required documentation artifacts
- Architecture Documentation
-
Component Diagrams: Visual architecture representations
-
Data Models: Pydantic schemas with validations
-
API Contracts: Endpoint specifications with examples
-
Data Flow: How data moves through system
Usage Guide
Step 1: Load Inputs
Load all required inputs for PRP generation:
Required Inputs:
Analysis Document: /docs/implementation/analysis/feature-{issue-number}-analysis.md
-
Requirements (functional and non-functional)
-
Security considerations
-
Technical stack requirements
-
Dependencies
-
Scope definition
-
Identified risks
Synthesized Design: Output from design-synthesizer skill
-
Component architecture with library mappings
-
Data models with library validation patterns
-
API contracts with library integration
-
Library integration strategies
-
Dependency resolution
-
Implementation path
-
Design decisions
-
Identified issues/gaps
Loading Pattern:
Read analysis document
analysis = read_document("/docs/implementation/analysis/feature-{issue-number}-analysis.md")
Parse synthesized design (from synthesis step)
design = parse_synthesized_design()
Extract key information
requirements = extract_requirements(analysis) architecture = extract_architecture(design) libraries = extract_libraries(design) dependencies = extract_dependencies(design) implementation_plan = extract_implementation_plan(design)
Step 2: Create PRP Header
Use prp-template.md header section:
Product Requirements Prompt: [Feature Name] (Issue #{issue-number})
Date: [YYYY-MM-DD] Designer: Design Orchestrator (Claude Code) Issue: #{issue-number} - [Issue Title] Analysis Document: /docs/implementation/analysis/feature-{issue-number}-analysis.md
Status: Ready for Implementation (Phase 3) Complexity: [Low / Medium / High] Estimated Effort: [Hours/Days] Priority: [P0 / P1 / P2 / P3]
Complexity Guidelines:
-
Low: Single component, <3 files, well-documented libraries
-
Medium: Multiple components, 3-10 files, some custom logic
-
High: Complex architecture, >10 files, custom integrations
Step 3: Write Executive Summary
Provide 2-3 paragraph overview of the design:
Executive Summary Template:
Executive Summary
This document provides comprehensive implementation guidance for [feature name], which [high-level description of what feature does and why it's valuable].
Architectural Approach: [Brief description of architecture - e.g., "Service layer pattern with FastAPI endpoints, SQLAlchemy ORM, and Redis caching"]
Key Libraries: [List 3-5 primary libraries - e.g., "FastAPI 0.95.0 for API framework, SQLAlchemy 2.0.0 for ORM, PassLib 1.7.4 for password hashing"]
Implementation Strategy: [Brief description of implementation phases - e.g., "4-phase approach: (1) Data models and repository, (2) Service layer business logic, (3) API endpoints, (4) Testing and validation"]
Key Considerations: [1-2 important considerations - e.g., "Security-first approach with OWASP compliance, performance target of <200ms API response time"]
Example:
Executive Summary
This document provides comprehensive implementation guidance for user authentication system, which enables secure user login, session management, and access control for the application.
Architectural Approach: Service layer pattern with FastAPI RESTful API endpoints, SQLAlchemy ORM for user persistence, PassLib for secure password hashing, and JWT tokens for session management.
Key Libraries: FastAPI 0.95.0 (API framework), SQLAlchemy 2.0.0 (ORM), PassLib 1.7.4 (password hashing), python-jose 3.3.0 (JWT tokens), pydantic 1.10.7 (validation).
Implementation Strategy: 4-phase approach: (1) User data model and repository with SQLAlchemy, (2) Authentication service with PassLib and JWT, (3) FastAPI endpoints with pydantic validation, (4) Comprehensive testing with pytest and mocks.
Key Considerations: OWASP Top 10 compliance for authentication vulnerabilities, bcrypt with cost factor 12 for password hashing, rate limiting for brute force protection, secure session token management with expiration.
Step 4: Document Requirements Reference
Link to analysis document and summarize key requirements:
Requirements Reference Template:
Requirements Reference
Source: [Link to analysis document]
Functional Requirements (Summary)
- [FR-001]: [Brief description]
- [FR-002]: [Brief description] ...
Non-Functional Requirements (Summary)
- Performance: [Key performance requirements]
- Security: [Key security requirements]
- Usability: [Key usability requirements]
- Scalability: [Key scalability requirements]
Acceptance Criteria (Key Points)
- [Top acceptance criterion 1]
- [Top acceptance criterion 2]
- [Top acceptance criterion 3]
Full Requirements: See analysis document for complete requirements, security assessment, and risk analysis.
Step 5: Document Architecture Design
Use synthesized architecture design:
Architecture Design Template:
Architecture Design
Component Overview
[ASCII diagram or description of component architecture]
Components
Component: [ComponentName]
Purpose: [What this component does] Responsibilities:
- [Responsibility 1]
- [Responsibility 2]
Library Integration:
- Primary Library: [LibraryName] v[Version]
- APIs Used: [Specific library APIs/classes]
- Pattern: [Integration pattern from design-patterns.md]
- Dependencies: [Required dependencies]
Implementation Notes:
- [Important implementation detail 1]
- [Important implementation detail 2]
Code Example:
# Example from library documentation (libraries-{issue-number}.md, Example X.Y)
[Code snippet showing library usage pattern]
[Repeat for each component]
Data Models
Model: [ModelName]
Purpose: [What this model represents]
Fields:
from pydantic import BaseModel, Field
from [library] import [ValidationMixin]
class [ModelName](BaseModel):
field1: type = Field(..., description="...") # Validation
field2: type = Field(default=..., ge=..., le=...) # Range validation
# ... more fields
Validation Rules:
- [Field1]: [Validation description]
- [Field2]: [Validation description]
Relationships:
- [Related Model]: [Relationship type and description]
Library Integration:
- Validation: [Library providing validation - e.g., Pydantic validators]
- Serialization: [How model is serialized - e.g., Pydantic .dict()]
- Storage: [ORM pattern - e.g., SQLAlchemy declarative base]
[Repeat for each model]
API Contracts
Endpoint: [METHOD] [/path]
Purpose: [What this endpoint does]
Request:
class [RequestModel](BaseModel):
field1: type
field2: type
Response:
class [ResponseModel](BaseModel):
field1: type
field2: type
Status Codes:
- 200
: Success - [Description]
- 400
: Bad Request - [Description]
- 401
: Unauthorized - [Description]
- 404
: Not Found - [Description]
- 500
: Internal Server Error - [Description]
Implementation:
# FastAPI endpoint pattern from library docs
@app.[method]("/path", response_model=[ResponseModel])
def endpoint([params: RequestModel]):
# Implementation using service layer
...
[Repeat for each endpoint]
Data Flow
[Describe how data flows through system]
Example Flow: User Authentication
1. Client sends POST /auth/login with email/password
2. FastAPI endpoint validates request (Pydantic)
3. AuthenticationService.authenticate() called
4. UserRepository.get_by_email() queries database (SQLAlchemy)
5. PassLib.verify() checks password hash
6. JWT token generated (python-jose)
7. Token returned to client
Error Handling Strategy
Library Exception Mapping:
Library Exception
Architectural Exception
HTTP Status
User Message
[LibraryException]
[AppException]
[Code]
[Message]
Error Handling Pattern:
try:
# Library operation
except LibraryException as e:
# Map to architectural exception
raise AppException(...) from e
### Step 6: Document Library Documentation
Use library information from Documentation Researcher:
**Library Documentation Template**:
```markdown
## Library Documentation
### Library: [LibraryName] v[Version]
**Purpose**: [What library does]
**Documentation**: [Link to official docs]
**Repository**: [Link to GitHub/source]
**Installation**:
```bash
pip install [library-name]==[version]
Key APIs Used:
- [API1]
: [Description and purpose]
- [API2]
: [Description and purpose]
Integration Pattern:
# Example from library documentation
[Code example showing how to use library in this project]
Configuration:
# Configuration required for this library
[Configuration code or settings]
Best Practices (from library docs):
- [Best practice 1]
- [Best practice 2]
Known Issues:
- [Issue 1 and workaround]
- [Issue 2 and workaround]
Testing Notes:
- Mocking: [How to mock this library in tests]
- Test Containers: [If integration tests need real library instance]
[Repeat for each library]
Library Comparison (if alternatives considered)
Library
Version
Pros
Cons
Decision
[Lib A]
[Ver]
[Pros]
[Cons]
✅ Chosen
[Lib B]
[Ver]
[Pros]
[Cons]
❌ Not chosen
Selection Rationale: [Why chosen library was selected]
### Step 7: Document Dependencies
Use dependency information from Dependency Manager:
**Dependencies Template**:
```markdown
## Dependencies
### Dependency Tree
[Full dependency tree with versions]
[library-a]==[version]
├── [dep-1]==[version]
│ └── [sub-dep]==[version]
├── [dep-2]==[version]
└── [optional-dep] (optional)
### Installation Commands
**Install all dependencies**:
```bash
# Install using pip
pip install -r requirements.txt
# Or using uv (faster)
uv pip install -r requirements.txt
Install in order (if order matters):
# Step 1: Install base dependencies
pip install [base-deps]
# Step 2: Install main libraries
pip install [main-libs]
# Step 3: Install optional dependencies
pip install [optional-deps]
Dependency Details
Dependency: [dep-name] v[version]
Purpose: [What this dependency provides]
Required By: [Libraries that need this dependency]
Version Constraint: [Why this specific version]
Alternatives: [Alternative versions/libraries considered]
[Repeat for key dependencies]
Compatibility Notes
Python Version: [Required Python version]
Operating System: [OS compatibility notes]
Database: [Database version requirements]
Other System Dependencies: [System-level requirements]
Dependency Conflicts and Resolutions
[If any conflicts were found and resolved]
Conflict: [Description]
- Library A needs: [Constraint A]
- Library B needs: [Constraint B]
- Resolution: [How conflict was resolved]
- Pinned Version: [Final version chosen]
### Step 8: Create Implementation Plan
Use `prp-template.md` implementation plan section:
**Implementation Plan Template**:
```markdown
## Implementation Plan
### Overview
This implementation follows a [N]-phase approach, progressing from foundation
(data models) to core functionality to integration to testing. Each phase builds
on the previous phase and has validation checkpoints.
### Phase 1: Foundation ([Estimated Time])
**Goal**: Create data models, repositories, and core utilities
**Tasks**:
1. **Data Models** ([Time])
- [ ] Create [Model1] Pydantic schema with validations
- [ ] Create [Model2] Pydantic schema with validations
- [ ] Add [Library]-specific validators
- [ ] Write unit tests for model validation
2. **Repository Layer** ([Time])
- [ ] Create [Repository1] with CRUD operations
- [ ] Implement [Library] ORM mappings
- [ ] Add query methods for common operations
- [ ] Write repository unit tests with mocks
3. **Configuration** ([Time])
- [ ] Create configuration classes (Pydantic BaseSettings)
- [ ] Add environment variable loading
- [ ] Configure [Library1], [Library2]
- [ ] Write configuration validation tests
**Validation Checkpoint**:
- [ ] All data models validate correctly
- [ ] All repository operations work with test database
- [ ] Configuration loads from environment
- [ ] Phase 1 tests pass (pytest)
### Phase 2: Core Implementation ([Estimated Time])
**Goal**: Implement business logic services using libraries
**Tasks**:
1. **Service Layer** ([Time])
- [ ] Create [Service1] with business logic
- [ ] Integrate [Library1] for [functionality]
- [ ] Implement error handling and exception mapping
- [ ] Add logging and monitoring
- [ ] Write service unit tests with mocked dependencies
2. **Library Integration** ([Time])
- [ ] Set up [Library2] client/connection
- [ ] Implement [Library2] operations
- [ ] Add retry logic for transient failures
- [ ] Write integration tests with test containers
**Validation Checkpoint**:
- [ ] All service methods work correctly
- [ ] Library integrations functioning
- [ ] Error handling covers all cases
- [ ] Phase 2 tests pass (pytest)
### Phase 3: Integration ([Estimated Time])
**Goal**: Connect components and create API endpoints
**Tasks**:
1. **API Endpoints** ([Time])
- [ ] Create [Endpoint1] with [Method] [/path]
- [ ] Add request/response validation (Pydantic)
- [ ] Integrate with service layer
- [ ] Add authentication/authorization
- [ ] Write endpoint integration tests
2. **Component Integration** ([Time])
- [ ] Connect [Component A] to [Component B]
- [ ] Implement data flow [Flow description]
- [ ] Add transaction handling
- [ ] Write integration tests for full flows
3. **Error Handling** ([Time])
- [ ] Add global exception handlers
- [ ] Map library exceptions to HTTP status codes
- [ ] Implement error response formatting
- [ ] Test error scenarios
**Validation Checkpoint**:
- [ ] All API endpoints respond correctly
- [ ] End-to-end flows work
- [ ] Error handling covers all endpoints
- [ ] Phase 3 tests pass (pytest)
### Phase 4: Testing & Validation ([Estimated Time])
**Goal**: Comprehensive testing and final validation
**Tasks**:
1. **Unit Test Coverage** ([Time])
- [ ] Achieve [X]% unit test coverage
- [ ] All components have isolated unit tests
- [ ] All edge cases covered
- [ ] Mock all external dependencies
2. **Integration Testing** ([Time])
- [ ] Test all API endpoints (end-to-end)
- [ ] Test library integrations with real instances
- [ ] Test error scenarios and recovery
- [ ] Performance testing ([targets])
3. **Security Validation** ([Time])
- [ ] OWASP Top 10 verification
- [ ] Input validation testing
- [ ] Authentication/authorization testing
- [ ] Secrets management verification
4. **Documentation** ([Time])
- [ ] Update API documentation
- [ ] Add code comments for complex logic
- [ ] Create user guide (if needed)
- [ ] Update README with new feature
**Final Validation**:
- [ ] All acceptance criteria met
- [ ] All tests pass (pytest)
- [ ] Coverage targets achieved
- [ ] Security validation complete
- [ ] Documentation complete
- [ ] Code review passed
### Phase 5: Deployment ([Estimated Time])
**Goal**: Deploy to production environment
**Tasks**:
1. **Pre-Deployment** ([Time])
- [ ] Review deployment checklist
- [ ] Verify environment configuration
- [ ] Database migrations tested
- [ ] Rollback plan documented
2. **Deployment** ([Time])
- [ ] Deploy to staging environment
- [ ] Run smoke tests in staging
- [ ] Deploy to production
- [ ] Monitor for errors
3. **Post-Deployment** ([Time])
- [ ] Verify production functionality
- [ ] Monitor performance metrics
- [ ] Check logs for errors
- [ ] Update documentation
**Deployment Validation**:
- [ ] Feature working in production
- [ ] No critical errors in logs
- [ ] Performance meets targets
- [ ] Monitoring dashboards updated
Step 9: Define Testing Strategy
Use prp-template.md
testing section:
Testing Strategy Template:
## Testing Strategy
### Overview
Comprehensive testing approach with [X]% code coverage target, including unit tests
(with mocks), integration tests (with test containers), and end-to-end tests (full
API flow).
### Unit Testing
**Scope**: Individual functions, classes, methods in isolation
**Framework**: pytest
**Coverage Target**: [X]% for all modules
**Mocking Strategy**:
- Mock [Library1] using unittest.mock
- Mock [Library2] using [library-specific test fixtures]
- Mock database using SQLAlchemy in-memory database
**Test Structure**:
tests/
├── unit/
│ ├── test_models.py # Data model validation tests
│ ├── test_repositories.py # Repository logic tests (mocked DB)
│ ├── test_services.py # Service logic tests (mocked deps)
│ └── test_validators.py # Custom validator tests
**Example Unit Test**:
```python
# Test with mocked library
from unittest.mock import Mock
import pytest
def test_service_method():
# Mock library dependency
mock_lib = Mock()
mock_lib.method.return_value = "expected"
# Test service with mock
service = MyService(mock_lib)
result = service.do_something()
assert result == "processed_expected"
mock_lib.method.assert_called_once()
Key Test Cases:
- [Component1]: Test [key functionality]
- [Component2]: Test [error handling]
- [Model1]: Test [validation rules]
Integration Testing
Scope: Components working together with real library instances
Framework: pytest with testcontainers
Test Containers Used:
- PostgreSQL: testcontainers.postgres.PostgresContainer
- Redis: testcontainers.redis.RedisContainer
Test Structure:
tests/
├── integration/
│ ├── test_database_operations.py # Real DB tests
│ ├── test_cache_operations.py # Real Redis tests
│ └── test_library_integrations.py # Real library usage
Example Integration Test:
from testcontainers.postgres import PostgresContainer
def test_repository_integration():
with PostgresContainer("postgres:15") as postgres:
# Create real database engine
engine = create_engine(postgres.get_connection_url())
# Test with real database
...
Key Test Cases:
- [Integration1]: Test [data flow]
- [Integration2]: Test [library interaction]
End-to-End Testing
Scope: Complete API flows from request to response
Framework: pytest with TestClient (FastAPI) or requests
Test Structure:
tests/
├── e2e/
│ ├── test_api_flows.py # Complete API workflows
│ ├── test_authentication.py # Auth flows
│ └── test_error_scenarios.py # Error handling
Example E2E Test:
from fastapi.testclient import TestClient
def test_user_creation_flow():
client = TestClient(app)
# Full flow test
response = client.post("/users", json={"email": "test@example.com"})
assert response.status_code == 201
user_id = response.json()["id"]
get_response = client.get(f"/users/{user_id}")
assert get_response.status_code == 200
Key Test Cases:
- [Flow1]: Test [complete user journey]
- [Flow2]: Test [error recovery]
Performance Testing
Scope: Verify performance meets non-functional requirements
Tools: pytest-benchmark, locust
Target Metrics:
- API response time: [target] (95th percentile)
- Database query time: [target]
- Cache hit rate: [target]
Test Cases:
- Benchmark [operation] performance
- Load test [endpoint] with [N] concurrent requests
Security Testing
Scope: Verify security controls and OWASP compliance
Test Cases:
- SQL injection prevention (parameterized queries)
- XSS prevention (output sanitization)
- CSRF protection (tokens)
- Authentication bypass attempts
- Authorization boundary testing
- Secrets not in logs or responses
Test Data Management
Test Fixtures:
# Shared test fixtures
@pytest.fixture
def sample_user():
return User(id=1, email="test@example.com", name="Test User")
@pytest.fixture
def mock_database():
# Create in-memory database for testing
...
Test Data Location: tests/fixtures/
Running Tests
All Tests:
pytest
Unit Tests Only:
pytest tests/unit/
Integration Tests Only:
pytest tests/integration/
With Coverage:
pytest --cov=src --cov-report=html
Coverage Report: htmlcov/index.html
Continuous Integration
CI Pipeline (GitHub Actions / GitLab CI):
- Run linting (black, mypy)
- Run unit tests
- Run integration tests (with test containers)
- Generate coverage report
- Fail if coverage < [X]%
### Step 10: Document Success Criteria
Use acceptance criteria from analysis and implementation-specific criteria:
**Success Criteria Template**:
```markdown
## Success Criteria
### Acceptance Criteria (from Requirements)
From analysis document (feature-{issue-number}-analysis.md):
- [ ] **AC-001**: [Acceptance criterion from analysis]
- [ ] **AC-002**: [Acceptance criterion from analysis]
- [ ] **AC-003**: [Acceptance criterion from analysis]
### Implementation Criteria
- [ ] **IC-001**: All data models defined with Pydantic validation
- [ ] **IC-002**: All repository CRUD operations implemented with [ORM]
- [ ] **IC-003**: All service methods implemented with error handling
- [ ] **IC-004**: All API endpoints implemented with [Framework]
- [ ] **IC-005**: All library integrations working ([Library1], [Library2])
### Testing Criteria
- [ ] **TC-001**: Unit test coverage ≥ [X]%
- [ ] **TC-002**: All integration tests passing
- [ ] **TC-003**: All end-to-end API tests passing
- [ ] **TC-004**: Performance tests meet targets ([metric] < [target])
- [ ] **TC-005**: Security tests passing (OWASP compliance)
### Code Quality Criteria
- [ ] **QC-001**: Linting passes (black, mypy)
- [ ] **QC-002**: No critical security vulnerabilities (bandit/safety)
- [ ] **QC-003**: Code review approved
- [ ] **QC-004**: All functions have docstrings
- [ ] **QC-005**: Complex logic has explanatory comments
### Documentation Criteria
- [ ] **DC-001**: API endpoints documented (OpenAPI/Swagger)
- [ ] **DC-002**: README updated with new feature
- [ ] **DC-003**: User guide created (if user-facing)
- [ ] **DC-004**: Code comments for complex logic
- [ ] **DC-005**: CHANGELOG updated
### Deployment Criteria
- [ ] **DEP-001**: Feature deployed to staging
- [ ] **DEP-002**: Smoke tests passing in staging
- [ ] **DEP-003**: Feature deployed to production
- [ ] **DEP-004**: Production monitoring dashboards updated
- [ ] **DEP-005**: No critical errors in first 24 hours
### Definition of Done
All of the following must be true:
- ✅ All acceptance criteria met
- ✅ All implementation criteria met
- ✅ All testing criteria met
- ✅ All code quality criteria met
- ✅ All documentation criteria met
- ✅ All deployment criteria met
- ✅ Feature reviewed and approved
- ✅ Feature in production and stable
Step 11: Validate PRP Completeness
Use prp-template.md validation checklist:
PRP Completeness Checklist:
- Header with metadata (date, designer, issue, analysis link)
- Executive summary (2-3 paragraphs)
- Requirements reference with key points
- Architecture design (components, data models, APIs, data flow, error handling)
- Library documentation (all libraries with examples and best practices)
- Dependencies (tree, installation, compatibility)
- Implementation plan (phased with tasks and validation checkpoints)
- Testing strategy (unit, integration, e2e, performance, security)
- Documentation requirements (what docs to create)
- Success criteria (acceptance, implementation, testing, quality, docs, deployment)
- Risks & mitigations (from synthesis)
Step 12: Write PRP to File
Save PRP to designated location:
File Path: /docs/implementation/prp/feature-{issue-number}-prp.md
Final PRP Structure:
# Product Requirements Prompt: [Feature Name] (Issue #{issue-number})
[Header with metadata]
## Executive Summary
[2-3 paragraphs]
## Requirements Reference
[Key requirements from analysis]
## Architecture Design
[Components, models, APIs, data flow, error handling]
## Library Documentation
[All libraries with examples]
## Dependencies
[Tree, installation, compatibility]
## Implementation Plan
[Phases with tasks and validation]
## Testing Strategy
[Unit, integration, e2e, performance, security]
## Documentation Requirements
[What to document]
## Success Criteria
[Acceptance, implementation, testing, quality, docs, deployment]
## Risks & Mitigations
[From synthesis and analysis]
---
**PRP Complete**: [Date/Time]
**Ready for Phase 3**: Implementation
Best Practices
1. Be Comprehensive But Concise
- Include all necessary information
- Avoid redundancy
- Link to other documents for details
- Use examples liberally
2. Make It Actionable
- Every section should guide implementer
- Provide code examples
- Specify exact commands
- Define clear validation checkpoints
3. Ensure Traceability
- Link requirements to design elements
- Link design to implementation tasks
- Link tasks to test cases
- Link tests to acceptance criteria
4. Validate Completeness
- Use prp-template.md checklist
- Verify all required sections present
- Check all links work
- Ensure all code examples valid
5. Consider the Implementer
- Write for someone unfamiliar with design discussions
- Provide context and rationale
- Explain trade-offs and decisions
- Anticipate questions
Resources
prp-template.md
Complete PRP template with:
- Standard structure
- Section templates
- Markdown formatting
- Validation checklist
prp-examples.md
Example PRPs showing:
- Simple feature PRP
- Complex feature PRP
- Multi-component PRP
- API-focused PRP
- Data-focused PRP
Example Usage
See prp-examples.md
for complete PRP examples.
Integration
This skill is used by:
- design-orchestrator agent during Phase 2: Design & Planning
- Activates automatically when generating PRP from synthesized design
- Output feeds into Phase 3: Implementation (Implementation Specialist)
Version: 2.0.0
Auto-Activation: Yes (when generating PRP documents)
Phase: 2 (Design & Planning)
Created: 2025-10-29