zhongwei/gh-wirasm-prps-agentic-eng-plugins-prp-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 09:06:36 +08:00
commit b141d79342
10 changed files with 1144 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "prp-core",
"description": "Complete PRP (Product Requirement Prompt) workflow automation - create, execute, commit, and PR commands with orchestration scripts",
"version": "1.0.0",
"author": {
"name": "Wirasm",
"email": "hello@rasmuswiding.com"
},
"commands": [
"./commands/"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# prp-core
Complete PRP (Product Requirement Prompt) workflow automation - create, execute, commit, and PR commands with orchestration scripts

55
commands/prp-core-commit.md Normal file
View File

@@ -0,0 +1,55 @@
# Create Git Commit
Create an atomic git commit with a properly formatted commit message following best practices for the uncommited changes or these specific files if specified.
Specific files (skip if not specified):
- File 1: $1
- File 2: $2
- File 3: $3
- File 4: $4
- File 5: $5
## Instructions
**Commit Message Format:**
- Use conventional commits: `<type>: <description>`
- Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`
- Present tense (e.g., "add", "fix", "update", not "added", "fixed", "updated")
- 50 characters or less for the subject line
- Lowercase subject line
- No period at the end
- Be specific and descriptive
**Examples:**
- `feat: add web search tool with structured logging`
- `fix: resolve type errors in middleware`
- `test: add unit tests for config module`
- `docs: update CLAUDE.md with testing guidelines`
- `refactor: simplify logging configuration`
- `chore: update dependencies`
**Atomic Commits:**
- One logical change per commit
- If you've made multiple unrelated changes, consider splitting into separate commits
- Commit should be self-contained and not break the build
**IMPORTANT**
- NEVER mention claude code, anthropic, co authored by or anything similar in the commit messages
## Run
1. Review changes: `git diff HEAD`
2. Check status: `git status`
3. Stage changes: `git add -A`
4. Create commit: `git commit -m "<type>: <description>"`
## Report
- Output the commit message used
- Confirm commit was successful with commit hash
- List files that were committed

408
commands/prp-core-create.md Normal file
View File

@@ -0,0 +1,408 @@
---
description: "Create comprehensive feature PRP with deep codebase analysis and research"
---
# Create Feature PRP
## Feature: $ARGUMENTS
## Mission
Transform a feature request into a **comprehensive implementation PRP** through systematic codebase analysis, external research, and strategic planning.
**Core Principle**: We do NOT write code in this phase. Our goal is to create a battle-tested, context-rich implementation plan that enables one-pass implementation success.
**Key Philosophy**: Context is King. The PRP must contain ALL information needed for implementation - patterns, gotchas, documentation, validation commands - so the execution agent succeeds on the first attempt.
## Planning Process
### Phase 1: Feature Understanding
**Deep Feature Analysis:**
- Extract the core problem being solved
- Identify user value and business impact
- Determine feature type: New Capability/Enhancement/Refactor/Bug Fix
- Assess complexity: Low/Medium/High
- Map affected systems and components
**Create User Story Format:**
```
As a <type of user>
I want to <action/goal>
So that <benefit/value>
```
### Phase 2: Codebase Intelligence Gathering
**Use specialized agents and parallel analysis:**
**1. Project Structure Analysis**
- Detect primary language(s), frameworks, and runtime versions
- Map directory structure and architectural patterns
- Identify service/component boundaries and integration points
- Locate configuration files (pyproject.toml, package.json, etc.)
- Find environment setup and build processes
**2. Pattern Recognition** (Use specialized subagents when beneficial)
- Search for similar implementations in codebase
- Identify coding conventions:
- Naming patterns (CamelCase, snake_case, kebab-case)
- File organization and module structure
- Error handling approaches
- Logging patterns and standards
- Extract common patterns for the feature's domain
- Document anti-patterns to avoid
- Check CLAUDE.md for project-specific rules and conventions
**3. Dependency Analysis**
- Catalog external libraries relevant to feature
- Understand how libraries are integrated (check imports, configs)
- Find relevant documentation in PRPs/ai_docs/ if available
- Note library versions and compatibility requirements
**4. Testing Patterns**
- Identify test framework and structure (pytest, jest, etc.)
- Find similar test examples for reference
- Understand test organization (unit vs integration)
- Note coverage requirements and testing standards
**5. Integration Points**
- Identify existing files that need updates
- Determine new files that need creation and their locations
- Map router/API registration patterns
- Understand database/model patterns if applicable
- Identify authentication/authorization patterns if relevant
**Clarify Ambiguities:**
- If requirements are unclear at this point, ask the user to clarify before you continue
- Get specific implementation preferences (libraries, approaches, patterns)
- Resolve architectural decisions before proceeding
### Phase 3: External Research & Documentation
**Use specialized subagents when beneficial for external research:**
**Documentation Gathering:**
- Research latest library versions and best practices
- Find official documentation with specific section anchors
- Locate implementation examples and tutorials
- Identify common gotchas and known issues
- Check for breaking changes and migration guides
**Technology Trends:**
- Research current best practices for the technology stack
- Find relevant blog posts, guides, or case studies
- Identify performance optimization patterns
- Document security considerations
**Compile Research References:**
```markdown
## Relevant Documentation
- [Library Official Docs](https://example.com/docs#section)
- Specific feature implementation guide
- Why: Needed for X functionality
- [Framework Guide](https://example.com/guide#integration)
- Integration patterns section
- Why: Shows how to connect components
```
### Phase 4: Deep Strategic Thinking
**Think Harder About:**
- How does this feature fit into the existing architecture?
- What are the critical dependencies and order of operations?
- What could go wrong? (Edge cases, race conditions, errors)
- How will this be tested comprehensively?
- What performance implications exist?
- Are there security considerations?
- How maintainable is this approach?
**Design Decisions:**
- Choose between alternative approaches with clear rationale
- Design for extensibility and future modifications
- Plan for backward compatibility if needed
- Consider scalability implications
### Phase 5: PRP Structure Generation
**Create comprehensive PRP with the following structure:**
```markdown
# Feature: <feature-name>
## Feature Description
<Detailed description of the feature, its purpose, and value to users>
## User Story
As a <type of user>
I want to <action/goal>
So that <benefit/value>
## Problem Statement
<Clearly define the specific problem or opportunity this feature addresses>
## Solution Statement
<Describe the proposed solution approach and how it solves the problem>
## Feature Metadata
**Feature Type**: [New Capability/Enhancement/Refactor/Bug Fix]
**Estimated Complexity**: [Low/Medium/High]
**Primary Systems Affected**: [List of main components/services]
**Dependencies**: [External libraries or services required]
---
## CONTEXT REFERENCES
### Relevant Codebase Files
<List files with line numbers and relevance>
- `path/to/file.py` (lines 15-45) - Why: Contains pattern for X that we'll mirror
- `path/to/model.py` (lines 100-120) - Why: Database model structure to follow
- `path/to/test.py` - Why: Test pattern example
### New Files to Create
- `path/to/new_service.py` - Service implementation for X functionality
- `path/to/new_model.py` - Data model for Y resource
- `tests/path/to/test_new_service.py` - Unit tests for new service
### Relevant Documentation
- [Documentation Link 1](https://example.com/doc1#section)
- Specific section: Authentication setup
- Why: Required for implementing secure endpoints
- [Documentation Link 2](https://example.com/doc2#integration)
- Specific section: Database integration
- Why: Shows proper async database patterns
### Patterns to Follow
<Specific patterns extracted from codebase - include actual code examples from the project>
**Naming Conventions:** (for example)
**Error Handling:** (for example)
**Logging Pattern:** (for example)
**Other Relevant Patterns:** (for example)
---
## IMPLEMENTATION PLAN
### Phase 1: Foundation
<Describe foundational work needed before main implementation>
**Tasks:**
- Set up base structures (schemas, types, interfaces)
- Configure necessary dependencies
- Create foundational utilities or helpers
### Phase 2: Core Implementation
<Describe the main implementation work>
**Tasks:**
- Implement core business logic
- Create service layer components
- Add API endpoints or interfaces
- Implement data models
### Phase 3: Integration
<Describe how feature integrates with existing functionality>
**Tasks:**
- Connect to existing routers/handlers
- Register new components
- Update configuration files
- Add middleware or interceptors if needed
### Phase 4: Testing & Validation
<Describe testing approach>
**Tasks:**
- Implement unit tests for each component
- Create integration tests for feature workflow
- Add edge case tests
- Validate against acceptance criteria
---
## STEP-BY-STEP TASKS
IMPORTANT: Execute every task in order, top to bottom. Each task is atomic and independently testable.
### Task Format Guidelines
Use information-dense keywords for clarity:
- **CREATE**: New files or components
- **UPDATE**: Modify existing files
- **ADD**: Insert new functionality into existing code
- **REMOVE**: Delete deprecated code
- **REFACTOR**: Restructure without changing behavior
- **MIRROR**: Copy pattern from elsewhere in codebase
### {ACTION} {target_file}
- **IMPLEMENT**: {Specific implementation detail}
- **PATTERN**: {Reference to existing pattern - file:line}
- **IMPORTS**: {Required imports and dependencies}
- **GOTCHA**: {Known issues or constraints to avoid}
- **VALIDATE**: `{executable validation command}`
<Continue with all tasks in dependency order...>
---
## TESTING STRATEGY
<Define testing approach based on project's test framework and patterns discovered in Phase 2>
### Unit Tests
<Scope and requirements based on project standards>
### Integration Tests
<Scope and requirements based on project standards>
### Edge Cases
<List specific edge cases that must be tested for this feature>
---
## VALIDATION COMMANDS
<Define validation commands based on project's tools discovered in Phase 2>
Execute every command to ensure zero regressions and 100% feature correctness.
### Level 1: Syntax & Style
<Project-specific linting and formatting commands>
### Level 2: Unit Tests
<Project-specific unit test commands>
### Level 3: Integration Tests
<Project-specific integration test commands>
### Level 4: Manual Validation
<Feature-specific manual testing steps - API calls, UI testing, etc.>
### Level 5: Additional Validation (Optional)
<MCP servers or additional CLI tools if available>
---
## ACCEPTANCE CRITERIA
<List specific, measurable criteria that must be met for completion>
- [ ] Feature implements all specified functionality
- [ ] All validation commands pass with zero errors
- [ ] Unit test coverage meets requirements (80%+)
- [ ] Integration tests verify end-to-end workflows
- [ ] Code follows project conventions and patterns
- [ ] No regressions in existing functionality
- [ ] Documentation is updated (if applicable)
- [ ] Performance meets requirements (if applicable)
- [ ] Security considerations addressed (if applicable)
---
## COMPLETION CHECKLIST
- [ ] All tasks completed in order
- [ ] Each task validation passed immediately
- [ ] All validation commands executed successfully
- [ ] Full test suite passes (unit + integration)
- [ ] No linting or type checking errors
- [ ] Manual testing confirms feature works
- [ ] Acceptance criteria all met
- [ ] Code reviewed for quality and maintainability
---
## NOTES
<Additional context, design decisions, trade-offs>
<!-- EOF -->
```
## Output Format
**Filename**: `.claude/PRPs/features/{kebab-case-descriptive-name}.md`
- Replace `{kebab-case-descriptive-name}` with short, descriptive feature name
- Examples: `add-user-authentication.md`, `implement-search-api.md`, `refactor-database-layer.md`
**Directory**: Create `.claude/PRPs/features/` if it doesn't exist
## Quality Criteria
### Context Completeness ✓
- [ ] All necessary patterns identified and documented
- [ ] External library usage documented with links
- [ ] Integration points clearly mapped
- [ ] Gotchas and anti-patterns captured
- [ ] Every task has executable validation command
### Implementation Ready ✓
- [ ] Another developer could execute without additional context
- [ ] Tasks ordered by dependency (can execute top-to-bottom)
- [ ] Each task is atomic and independently testable
- [ ] Pattern references include specific file:line numbers
### Pattern Consistency ✓
- [ ] Tasks follow existing codebase conventions
- [ ] New patterns justified with clear rationale
- [ ] No reinvention of existing patterns or utils
- [ ] Testing approach matches project standards
### Information Density ✓
- [ ] No generic references (all specific and actionable)
- [ ] URLs include section anchors when applicable
- [ ] Task descriptions use codebase keywords
- [ ] Validation commands are non interactive executable
## Success Metrics
**One-Pass Implementation**: Execution agent can complete feature without additional research or clarification
**Validation Complete**: Every task has at least one working validation command
**Context Rich**: PRP passes "No Prior Knowledge Test" - someone unfamiliar with codebase can implement using only PRP content
**Confidence Score**: #/10 that execution will succeed on first attempt
## Report
After creating the PRP, provide:
- Summary of feature and approach
- Full path to created PRP file
- Complexity assessment
- Key implementation risks or considerations
- Estimated confidence score for one-pass success

59
commands/prp-core-execute.md Normal file
View File

@@ -0,0 +1,59 @@
---
description: "Execute a feature PRP until fully complete"
---
# Execute Feature PRP
## PRP File: $ARGUMENTS
## Instructions
- Ingest the PRP file completely
- Think hard about the implementation approach
- Execute every task in the STEP-BY-STEP TASKS section sequentially
- Validate after each task using the task's validation command
- If validation fails, fix and re-validate before proceeding
- Run full validation suite from the PRP when all tasks complete
- **Critical**: Don't stop until the entire plan is fulfilled and all validation passes
- Use TodoWrite to track progress through tasks
- Trust the PRP's strategic direction, but verify tactical details (imports, paths, names)
- If the PRP has errors in details, fix them and note in report
## Success Criteria
- ✓ Every task completed
- ✓ All validation commands pass
- ✓ Acceptance criteria met
## Completion
Once all validation passes:
```bash
mkdir -p .claude/PRPs/features/completed
mv .claude/PRPs/features/{prp-file}.md .claude/PRPs/features/completed/
```
## Report
After completion:
**Summary:**
- Feature: {name}
- Tasks completed: {count}
- Files created/modified: {list}
**Validation:**
```bash
✓ Linting: Passed
✓ Type checking: Passed
✓ Tests: X/X passed
```
**Adjustments** (if any):
- Note any PRP details that were incorrect and how you fixed them
**Files Changed:**
```bash
git diff --stat
```

104
commands/prp-core-new-branch.md Normal file
View File

@@ -0,0 +1,104 @@
# Create Git Branch
Generate a conventional branch name based on user request and create a new git branch.
## Variables
User request: $1
## Instructions
**Step 1: Check Current Branch**
- Check current branch: `git branch --show-current`
- Check if on main/master:
```bash
CURRENT_BRANCH=$(git branch --show-current)
if [[ "$CURRENT_BRANCH" != "main" && "$CURRENT_BRANCH" != "master" ]]; then
echo "Warning: Currently on branch '$CURRENT_BRANCH', not main/master"
echo "Proceeding with branch creation from current branch"
fi
```
- Note: We proceed regardless, but log the warning
**Step 2: Generate Branch Name**
Use conventional branch naming:
**Prefixes:**
- `feat/` - New feature or enhancement
- `fix/` - Bug fix
- `chore/` - Maintenance tasks (dependencies, configs, etc.)
- `docs/` - Documentation only changes
- `refactor/` - Code refactoring (no functionality change)
- `test/` - Adding or updating tests
- `perf/` - Performance improvements
**Naming Rules:**
- Use kebab-case (lowercase with hyphens)
- Be descriptive but concise (max 50 characters)
- Remove special characters except hyphens
- No spaces, use hyphens instead
**Examples:**
- "Add user authentication system" → `feat/add-user-auth`
- "Fix login redirect bug" → `fix/login-redirect`
- "Update README documentation" → `docs/update-readme`
- "Refactor database queries" → `refactor/database-queries`
- "Add unit tests for API" → `test/api-unit-tests`
**Branch Name Generation Logic:**
1. Analyze user request to determine type (feature/fix/chore/docs/refactor/test/perf)
2. Extract key action and subject
3. Convert to kebab-case
4. Truncate if needed to keep under 50 chars
5. Validate name is descriptive and follows conventions
**Step 3: Check Branch Exists**
- Check if branch name already exists:
```bash
if git show-ref --verify --quiet refs/heads/<branch-name>; then
echo "Branch <branch-name> already exists"
# Append version suffix
COUNTER=2
while git show-ref --verify --quiet refs/heads/<branch-name>-v$COUNTER; do
COUNTER=$((COUNTER + 1))
done
BRANCH_NAME="<branch-name>-v$COUNTER"
fi
```
- If exists, append `-v2`, `-v3`, etc. until unique
**Step 4: Create and Checkout Branch**
- Create and checkout new branch: `git checkout -b <branch-name>`
- Verify creation: `git branch --show-current`
- Ensure output matches expected branch name
**Step 5: Verify Branch State**
- Confirm branch created: `git branch --list <branch-name>`
- Confirm currently on branch: `[ "$(git branch --show-current)" = "<branch-name>" ]`
- Check remote tracking: `git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null || echo "No upstream set"`
**Important Notes:**
- NEVER mention Claude Code, Anthropic, AI, or co-authoring in any output
- Branch should be created locally only (no push yet)
- Branch will be pushed later by commit.md command
- If user request is unclear, prefer `feat/` prefix as default
## Report
Output ONLY the branch name (no markdown, no explanations, no quotes):
<branch-name>
**Example outputs:**
```
feat/add-user-auth
fix/login-redirect-issue
docs/update-api-documentation
refactor/simplify-middleware
```

85
commands/prp-core-pr.md Normal file
View File

@@ -0,0 +1,85 @@
# Create Pull Request
Create a well-structured pull request with proper description and context.
## PR Title (if provided)
$ARGUMENTS
## Process
1. **Prepare Branch**
```bash
# Check current branch
git branch --show-current
# Ensure we're not on main
# If on main, create a feature branch
```
2. **Review Changes**
```bash
# See what will be included
git status
git diff main...HEAD
```
3. **Create Commits**
- Stage relevant files
- Create logical, atomic commits if not already done
- Write clear commit messages following conventional commits, do not include any reference to cluade, written by clade etc:
- `feat:` for new features
- `fix:` for bug fixes
- `docs:` for documentation
- `test:` for tests
- `refactor:` for refactoring
4. **Push to Remote**
```bash
git push -u origin HEAD
```
5. **Create PR**
```bash
gh pr create --title "$ARGUMENTS" --body "$(cat <<'EOF'
## Summary
[Brief description of what this PR does]
## Changes
- [List key changes]
- [Be specific]
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Testing
- [ ] Tests pass locally
- [ ] Added new tests
- [ ] Manual testing completed
## Checklist
- [ ] Code follows project style
- [ ] Self-reviewed
- [ ] Updated documentation
- [ ] No console.logs or debug code
## Screenshots (if applicable)
[Add screenshots for UI changes]
## Additional Context
[Any extra information reviewers should know]
EOF
)"
```
6. **Post-Creation**
- Add labels if needed: `gh pr edit --add-label "feature,needs-review"`
- Request reviewers if known
- Link to related issues
Remember to:
- Keep PRs focused and small
- Provide context for reviewers
- Test thoroughly before creating PR

93
commands/prp-core-review.md Normal file
View File

@@ -0,0 +1,93 @@
# Code Review
Please perform a comprehensive code review of the current changes or specified files.
## Review Scope
Scope for review $1
Link to must read PRP file if prp was used for implemnetaiton (skip if this is empty) $2
## Review Process
1. **Understand Changes**
- If reviewing staged changes: `git diff --staged`
- If reviewing specific files: Read the specified files
- If reviewing a PR: `gh pr view --json files,additions,deletions`
- If reviewing a local directory: `git diff`
- If reviewing the entire codebase: `git diff origin/main`
## Review Focus Areas
1. **Code Quality**
- Type hints on all functions and classes
- Pydantic v2 models for data validation
- No print() statements (use logging)
- Proper error handling
- Following PEP 8
- Docstrings following google style python docstrings
2. **Pydantic v2 Patterns**
- Using ConfigDict not class Config
- field_validator not @validator
- model_dump() not dict()
- Proper use of Annotated types
3. **Security**
- Input validation on all endpoints
- No SQL injection vulnerabilities
- Passwords properly hashed
- No hardcoded secrets
4. **Structure**
- Unit tests are co-located with the code they test in tests/ folders
- Each feature is self-contained with its own models, service, and tools
- Shared components are only things used by multiple features
- Future improvements (like multiple AI providers) would go in src/shared/ai_providers/ when implemented
- Integration tests remain at the root level in tests/integration/
5. **Linting**
- ruff check --fix
- mypy
6. **Testing**
- New code has tests
- Edge cases covered
- Mocking external dependencies
7. **Performance**
- No N+1 queries
- Efficient algorithms
- Proper async usage
8. **Documentation**
- Clear README with setup instructions
- CLAUDE.md is up to date with any new important utils, dependencies etc for future cluade code instances
## Review Output
Create a concise review report with:
```markdown
# Code Review #[number]
## Summary
[2-3 sentence overview]
## Issues Found
### 🔴 Critical (Must Fix)
- [Issue with file:line and suggested fix]
### 🟡 Important (Should Fix)
- [Issue with file:line and suggested fix]
### 🟢 Minor (Consider)
- [Improvement suggestions]
## Good Practices
- [What was done well]
## Test Coverage
Current: X% | Required: 80%
Missing tests: [list]
Save report to PRPs/code_reviews/review[#].md (check existing files first)

256
commands/prp-core-run-all.md Normal file
View File

@@ -0,0 +1,256 @@
---
description: Run all prp core commands in sequence from feature request to pr
---
# PRP Core Complete Workflow
Feature: $ARGUMENTS
## Instructions
Execute the complete PRP workflow from feature idea to GitHub PR. This workflow uses a mix of subagent delegation (via Task tool) and main agent execution to optimize context usage and performance.
**CRITICAL**: Follow the delegation strategy exactly as specified. Some steps MUST run in subagents, others MUST run in the main conversation.
---
### Step 1: Create Branch (SUBAGENT) 🌿
**Delegation Strategy**: Use Task tool to delegate to subagent.
**Why subagent**: Branch creation is a simple, isolated task that doesn't require conversation context.
**Task Tool Invocation**:
```
description: "Create conventional git branch"
prompt: "You must execute the slash command /prp-core:prp-core-new-branch with the argument: '$ARGUMENTS'
Follow ALL instructions in that command exactly:
1. Check current branch
2. Generate conventional branch name (feat/, fix/, chore/, etc.)
3. Handle conflicts with version suffixes if needed
4. Create and checkout the new branch
5. Verify creation
After completion, report ONLY the branch name that was created (no additional text).
Example output: feat/add-user-auth"
subagent_type: "general-purpose"
```
**Wait for completion**. Capture the branch name from subagent output.
**Validation**: Verify branch name follows conventional format (prefix/description).
---
### Step 2: Create PRP (SUBAGENT) 📝
**Delegation Strategy**: Use Task tool to delegate to subagent.
**Why subagent**: PRP creation is research-heavy and benefits from isolated context window for codebase analysis.
**Task Tool Invocation**:
```
description: "Generate comprehensive feature PRP"
prompt: "You must execute the slash command /prp-core:prp-core-create with the argument: '$ARGUMENTS'
This command will guide you through creating a comprehensive Product Requirement Prompt. Follow ALL phases:
Phase 1: Feature Understanding
- Analyze the feature request thoroughly
- Create user story format
- Assess complexity
Phase 2: Codebase Intelligence Gathering
- Use specialized agents for pattern recognition
- Analyze project structure
- Identify dependencies and integration points
Phase 3: External Research & Documentation
- Research relevant libraries and best practices
- Gather documentation with specific anchors
- Identify gotchas and known issues
Phase 4: Deep Strategic Thinking
- Consider edge cases and design decisions
- Plan for extensibility and maintainability
Phase 5: PRP Generation
- Output comprehensive PRP file to .claude/PRPs/features/
After completion, report the EXACT file path of the created PRP.
Example output: .claude/PRPs/features/add-user-authentication.md"
subagent_type: "general-purpose"
```
**Wait for completion**. Capture the PRP file path from subagent output.
**Validation**:
1. Verify PRP file exists at reported path
2. Verify file is not empty
3. Verify it contains required sections (STEP-BY-STEP TASKS, VALIDATION COMMANDS)
---
### Step 3: Execute PRP (MAIN AGENT) ⚙️
**Delegation Strategy**: DO NOT delegate. Execute directly in main conversation using SlashCommand tool.
**Why main agent**:
- PRP execution is complex and long-running (10-50+ tasks)
- Requires full conversation context and memory
- Needs user interaction capability for clarifications
- Must manage state across many sequential operations
- Benefits from conversation history and continuity
**Direct Execution**:
Use the SlashCommand tool to invoke:
```
/prp-core:prp-core-execute [PRP-file-path-from-step-2]
```
This will:
1. Ingest the complete PRP file
2. Execute every task in STEP-BY-STEP TASKS sequentially
3. Validate after each task
4. Fix failures and re-validate before proceeding
5. Run full validation suite on completion
6. Move completed PRP to .claude/PRPs/features/completed/
**IMPORTANT**:
- Execute this step YOURSELF in the main conversation
- DO NOT use Task tool for this step
- Track progress with TodoWrite
- Don't stop until entire PRP is complete and validated
**Wait for execution to fully complete** before proceeding to Step 4.
**Validation**:
1. All tasks completed
2. PRP moved to completed/ directory
3. All validation commands passed
---
### Step 4: Commit Changes (SUBAGENT) 💾
**Delegation Strategy**: Use Task tool to delegate to subagent.
**Why subagent**: Commit creation is isolated and only needs current git state.
**Task Tool Invocation**:
```
description: "Create conventional commit"
prompt: "You must execute the slash command /prp-core:prp-core-commit
Follow ALL instructions in that command:
1. Review uncommitted changes with git diff
2. Check git status
3. Stage all changes with git add -A
4. Create commit with conventional format: <type>: <description>
- Types: feat, fix, docs, style, refactor, test, chore
- Present tense, lowercase, ≤50 chars, no period
- NEVER mention Claude Code, Anthropic, or AI
After completion, report the commit hash and commit message.
Example output:
Commit: a1b2c3d
Message: feat: add user authentication system"
subagent_type: "general-purpose"
```
**Wait for completion**. Capture commit hash and message.
**Validation**: Verify commit exists with `git log -1 --oneline`.
---
### Step 5: Create PR (SUBAGENT) 🚀
**Delegation Strategy**: Use Task tool to delegate to subagent.
**Why subagent**: PR creation is isolated and only needs git history.
**Task Tool Invocation**:
```
description: "Push and create GitHub PR"
prompt: "You must execute the slash command /prp-core:prp-core-pr with the title generated from the feature: '$ARGUMENTS'
Follow ALL instructions in that command:
1. Check current branch
2. Review changes with git status and git diff
3. Push to remote with git push -u origin HEAD
4. Create GitHub PR using gh pr create with:
- Title: Generated from feature request
- Body: Comprehensive description with summary, changes, type, testing, checklist
After completion, report the PR URL.
Example output: https://github.com/Wirasm/PRPs-agentic-eng/pull/15"
subagent_type: "general-purpose"
```
**Wait for completion**. Capture PR URL.
**Validation**: Verify PR URL is accessible.
---
## Completion Report
After all 5 steps complete successfully, provide a comprehensive summary:
```
✅ PRP Core Workflow Complete
Branch: [branch-name-from-step-1]
PRP: [prp-file-path-from-step-2] → completed/
Commit: [commit-hash-from-step-4] - [commit-message]
PR: [pr-url-from-step-5]
Summary:
- Created conventional git branch
- Generated comprehensive PRP with deep codebase analysis
- Executed all [X] tasks with validation
- Committed changes with conventional format
- Pushed and created GitHub pull request
The feature is now ready for review!
```
---
## Error Handling
If any step fails:
1. **STOP immediately** - do not proceed to next step
2. Report which step failed and the error message
3. Provide actionable guidance for fixing the issue
4. Do NOT attempt automatic retry without user confirmation
---
## Design Rationale
**Subagent Delegation (Steps 1, 2, 4, 5)**:
- Simple, isolated tasks
- Don't need conversation context
- Benefit from fresh context windows
- Can run independently
**Main Agent Execution (Step 3)**:
- Complex, multi-task execution
- Requires conversation continuity
- Needs full context and state management
- May require user interaction
- Long-running operation (10-50+ sequential tasks)
This hybrid approach optimizes:
- **Context window usage**: Subagents for simple tasks don't pollute main context
- **Performance**: Isolated tasks complete faster in dedicated contexts
- **Reliability**: Complex execution stays in main agent with full capabilities
- **User experience**: Main agent maintains conversation for complex work

69
plugin.lock.json Normal file
View File

@@ -0,0 +1,69 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:Wirasm/PRPs-agentic-eng:plugins/prp-core",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "4538637d8dc5466039295a1d56a53be1b44f65ac",
"treeHash": "062c712fed37e1254c668eaf52c4fca67a0524a862ed2f3369fba3a4ed5dc48d",
"generatedAt": "2025-11-28T10:12:58.266325Z",
"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-core",
"description": "Complete PRP (Product Requirement Prompt) workflow automation - create, execute, commit, and PR commands with orchestration scripts",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "125916693ac135a959e788cea99a508d40b5e28e13b4ec76e90f812fc939a437"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "af736329efe37ead512720c0300e37ba20c84ef74562803737c484d37c40dee0"
},
{
"path": "commands/prp-core-execute.md",
"sha256": "fb8888da4483581c911ef0f69c28858b3942280979ae09f9b4516aaefec87192"
},
{
"path": "commands/prp-core-run-all.md",
"sha256": "1297fb940e71a61fbca7dd567fb1f64bdcfec8949380421b3ec54e24df0ce397"
},
{
"path": "commands/prp-core-create.md",
"sha256": "5ae07fca0c0422164606c956a12fc98ffec3b66ecf5f6adb044c3fa94abd3554"
},
{
"path": "commands/prp-core-review.md",
"sha256": "872a3e5f8b5bb583e9f0d942b817d868718c850e3702a536f94af87025d8d8c8"
},
{
"path": "commands/prp-core-commit.md",
"sha256": "90a97a5bd8cbb24ec4ea7f487729912be9cde0d57e54ccd579f2809597903c50"
},
{
"path": "commands/prp-core-new-branch.md",
"sha256": "45f32ed02c80a4dc6cb99f0a6b145d639bf9056dcf54ff88b0e6e3f23563e1ff"
},
{
"path": "commands/prp-core-pr.md",
"sha256": "d17c7ebf2353ac6574d9b9bb3c7135c4571d11e61790cbaf499256bba6abe885"
}
],
"dirSha256": "062c712fed37e1254c668eaf52c4fca67a0524a862ed2f3369fba3a4ed5dc48d"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}