/plan

description: Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.

Plan Command

This command creates 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

This command should:

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

Assistant:
# 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.py
- Implement notification queue using Celery/Redis
- Add retry logic for failed deliveries
- Create notification templates (Jinja2)

### 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: API/Frontend
- Create notification endpoints (GET /api/notifications, POST /api/notifications/read)
- WebSocket support for real-time updates
- Frontend notification bell component
- Notification preferences page

## Dependencies
- Redis (for Celery queue)
- Celery (task queue)
- Email service (SendGrid/Resend/SMTP)
- WebSocket server (channels/websocket)

## Risks
- HIGH: Email deliverability (SPF/DKIM required)
- MEDIUM: Performance with 1000+ users per market
- MEDIUM: Notification spam if markets resolve frequently
- LOW: WebSocket connection overhead

## Estimated Complexity: MEDIUM
- Backend: 4-6 hours
- API/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**: Do **NOT** write any code until the user explicitly confirms the plan with "yes" or "proceed" or a 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-and-fix` if build errors occur
• Use `/code-review` to review completed implementation

Related Skills

• `architecture-design` (when structural design is needed)