mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-02 07:03:28 +08:00
c02d6e9f94
* feat: add PRP workflow commands adapted from PRPs-agentic-eng
Add 5 new PRP workflow commands and extend 2 existing commands:
New commands:
- prp-prd.md: Interactive PRD generator with 8 phases
- prp-plan.md: Deep implementation planning with codebase analysis
- prp-implement.md: Plan executor with rigorous validation loops
- prp-commit.md: Quick commit with natural language file targeting
- prp-pr.md: GitHub PR creation from current branch
Extended commands:
- code-review.md: Added GitHub PR review mode alongside local review
- plan.md: Added cross-reference to /prp-plan for deeper planning
Adapted from PRPs-agentic-eng by Wirasm. Sub-agents remapped to
inline Claude instructions. ECC conventions applied throughout
(YAML frontmatter, Phase headings, tables, no XML tags).
Artifacts stored in .claude/PRPs/{prds,plans,reports,reviews}/.
* fix: address PR #848 review feedback
- Remove external URLs from all 6 command files (keep attribution text)
- Quote $ARGUMENTS in prp-implement.md to handle paths with spaces
- Fix empty git add expansion in prp-commit.md (use xargs -r)
- Rewrite sub-agent language in prp-prd.md as direct instructions
- Fix code-review.md: add full-file fetch for PR reviews, replace
|| fallback chains with project-type detection, use proper GitHub
API for inline review comments
- Fix nested backticks in prp-plan.md Plan Template (use 4-backtick fence)
- Clarify $ARGUMENTS parsing in prp-pr.md for base branch + flags
- Fix fragile integration test pattern in prp-implement.md (proper
PID tracking, wait-for-ready loop, clean shutdown)
* fix: address second-pass review feedback on PR #848
- Add required 'side' field to GitHub review comments API call (code-review.md)
- Replace GNU-only xargs -r with portable alternative (prp-commit.md)
- Add failure check after server readiness timeout (prp-implement.md)
- Fix unsafe word-splitting in file-fetch loop using read -r (code-review.md)
- Make git reset pathspec tolerant of zero matches (prp-commit.md)
- Quote PRD file path in cat command (prp-plan.md)
- Fix plan filename placeholder inconsistency (prp-plan.md)
- Add PR template directory scan before fixed-path fallbacks (prp-pr.md)
118 lines
3.8 KiB
Markdown
118 lines
3.8 KiB
Markdown
---
|
|
description: Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.
|
|
---
|
|
|
|
# Plan Command
|
|
|
|
This command invokes the **planner** agent to create a comprehensive implementation plan before writing any code.
|
|
|
|
## What This Command Does
|
|
|
|
1. **Restate Requirements** - Clarify what needs to be built
|
|
2. **Identify Risks** - Surface potential issues and blockers
|
|
3. **Create Step Plan** - Break down implementation into phases
|
|
4. **Wait for Confirmation** - MUST receive user approval before proceeding
|
|
|
|
## When to Use
|
|
|
|
Use `/plan` when:
|
|
- Starting a new feature
|
|
- Making significant architectural changes
|
|
- Working on complex refactoring
|
|
- Multiple files/components will be affected
|
|
- Requirements are unclear or ambiguous
|
|
|
|
## How It Works
|
|
|
|
The planner agent will:
|
|
|
|
1. **Analyze the request** and restate requirements in clear terms
|
|
2. **Break down into phases** with specific, actionable steps
|
|
3. **Identify dependencies** between components
|
|
4. **Assess risks** and potential blockers
|
|
5. **Estimate complexity** (High/Medium/Low)
|
|
6. **Present the plan** and WAIT for your explicit confirmation
|
|
|
|
## Example Usage
|
|
|
|
```
|
|
User: /plan I need to add real-time notifications when markets resolve
|
|
|
|
Agent (planner):
|
|
# Implementation Plan: Real-Time Market Resolution Notifications
|
|
|
|
## Requirements Restatement
|
|
- Send notifications to users when markets they're watching resolve
|
|
- Support multiple notification channels (in-app, email, webhook)
|
|
- Ensure notifications are delivered reliably
|
|
- Include market outcome and user's position result
|
|
|
|
## Implementation Phases
|
|
|
|
### Phase 1: Database Schema
|
|
- Add notifications table with columns: id, user_id, market_id, type, status, created_at
|
|
- Add user_notification_preferences table for channel preferences
|
|
- Create indexes on user_id and market_id for performance
|
|
|
|
### Phase 2: Notification Service
|
|
- Create notification service in lib/notifications.ts
|
|
- Implement notification queue using BullMQ/Redis
|
|
- Add retry logic for failed deliveries
|
|
- Create notification templates
|
|
|
|
### Phase 3: Integration Points
|
|
- Hook into market resolution logic (when status changes to "resolved")
|
|
- Query all users with positions in market
|
|
- Enqueue notifications for each user
|
|
|
|
### Phase 4: Frontend Components
|
|
- Create NotificationBell component in header
|
|
- Add NotificationList modal
|
|
- Implement real-time updates via Supabase subscriptions
|
|
- Add notification preferences page
|
|
|
|
## Dependencies
|
|
- Redis (for queue)
|
|
- Email service (SendGrid/Resend)
|
|
- Supabase real-time subscriptions
|
|
|
|
## Risks
|
|
- HIGH: Email deliverability (SPF/DKIM required)
|
|
- MEDIUM: Performance with 1000+ users per market
|
|
- MEDIUM: Notification spam if markets resolve frequently
|
|
- LOW: Real-time subscription overhead
|
|
|
|
## Estimated Complexity: MEDIUM
|
|
- Backend: 4-6 hours
|
|
- Frontend: 3-4 hours
|
|
- Testing: 2-3 hours
|
|
- Total: 9-13 hours
|
|
|
|
**WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify)
|
|
```
|
|
|
|
## Important Notes
|
|
|
|
**CRITICAL**: The planner agent will **NOT** write any code until you explicitly confirm the plan with "yes" or "proceed" or similar affirmative response.
|
|
|
|
If you want changes, respond with:
|
|
- "modify: [your changes]"
|
|
- "different approach: [alternative]"
|
|
- "skip phase 2 and do phase 3 first"
|
|
|
|
## Integration with Other Commands
|
|
|
|
After planning:
|
|
- Use `/tdd` to implement with test-driven development
|
|
- Use `/build-fix` if build errors occur
|
|
- Use `/code-review` to review completed implementation
|
|
|
|
> **Need deeper planning?** Use `/prp-plan` for artifact-producing planning with PRD integration, codebase analysis, and pattern extraction. Use `/prp-implement` to execute those plans with rigorous validation loops.
|
|
|
|
## Related Agents
|
|
|
|
This command invokes the `planner` agent provided by ECC.
|
|
|
|
For manual installs, the source file lives at:
|
|
`agents/planner.md`
|