# /copilot — Full Structured Development Workflow

Complete planning-to-execution workflow for complex or ambiguous tasks. Includes task intake, assumptions, planning, ticket generation, risk assessment, then execution.

## Usage

```
/copilot <task description>
```

**Examples:**
- `/copilot Add invoice generation for subscription billing`
- `/copilot Implement multi-tenant organization management`
- `/copilot Build real-time WhatsApp conversation dashboard`

## Workflow

### Phase 1: Task Intake
1. Parse the task description
2. Ask clarifying questions about:
   - Scope boundaries (what's in/out)
   - Edge cases to handle
   - User-facing vs internal
   - Priority and timeline constraints
   - Integration points with existing features
3. Document answers

### Phase 2: Assumptions & Context
1. Read relevant domain files from `.claude/domains/`:
   - Frontend → `.claude/domains/frontend.md`
   - Backend → `.claude/domains/backend.md`
   - Infrastructure → `.claude/domains/infrastructure.md`
   - Testing → `.claude/domains/testing.md`
2. Explore existing codebase patterns related to the task
3. List explicit assumptions being made
4. Identify unknowns and risks

### Phase 3: Architecture Plan
1. Create a detailed technical plan:
   - System design / data flow
   - Database schema changes (Prisma models)
   - API endpoints needed
   - UI components to build
   - Auth/permissions requirements
   - i18n considerations (Arabic/English, RTL)
2. **Present plan to user for approval**

### Phase 4: Ticket Breakdown
1. Break the plan into discrete, implementable tickets:
   ```
   Ticket 1: [DB] Add Prisma models for <feature>
   Ticket 2: [API] Create /api/<resource> CRUD endpoints
   Ticket 3: [UI] Build <Component> dashboard panel
   Ticket 4: [Test] Write unit + e2e tests
   Ticket 5: [i18n] Add Arabic translations
   ```
2. Each ticket includes:
   - Title
   - Description with acceptance criteria
   - Files to touch
   - Dependencies (blocked-by relationships)
   - Estimated complexity (S/M/L)
3. **Present tickets to user for approval**

### Phase 5: Risk Assessment
1. Identify risks:
   - Breaking existing functionality
   - Performance implications
   - Security concerns (OWASP top 10)
   - Migration risks (Prisma schema changes)
   - i18n/RTL edge cases
2. Propose mitigations for each risk

### Phase 6: Execution
1. Create a worktree for the feature:
   ```bash
   git worktree add ../mawidi-<branch> -b feature/<branch>
   ```
2. Execute tickets in dependency order
3. Use parallel Task agents for independent tickets
4. After each ticket:
   - Run `npx tsc --noEmit`
   - Commit with conventional message
5. After all tickets:
   - Run full verification (`/verify` workflow)
   - Push and create PR

### Phase 7: Wrap-up
1. Summarize what was built
2. List any follow-up tasks or tech debt
3. Report PR URL

## Key Rules
- ALWAYS ask clarifying questions before planning
- ALWAYS get user approval at Phase 3 (plan) and Phase 4 (tickets)
- Execute tickets in dependency order
- Parallelize independent work with Task agents
- Commit after every ticket completion
- Write tests alongside implementation (TDD)
