Implement Multiple GitHub Issues in Parallel

Execute multiple GitHub issues concurrently, respecting dependencies between them.

Usage

/implement-issues-parallel 5 12 18 23

Workflow

Phase 1: Analysis & Dependency Detection

1. Fetch All Issues

   for issue in $ARGUMENTS; do
     gh issue view $issue --json title,body,labels
   done
   

2. Analyze Dependencies

   For each issue, check:

   • Does it reference other issues in the batch? (e.g., "Depends on #5", "Blocks #12")
   • Does it modify files that other issues also modify?
   • Does it require features from other issues?

3. Build Dependency Graph (ASCII)

   ┌─────────────────────────────────────────────────────────────┐
   │ EXECUTION PLAN FOR ISSUES: 5, 12, 18, 23                   │
   └─────────────────────────────────────────────────────────────┘
   
   ┌──────────┐
   │ Issue #5 │  (Database migration)
   └────┬─────┘
        │
        ├────────┐
        │        │
        ▼        ▼
   ┌──────────┐ ┌──────────┐
   │Issue #12 │ │Issue #18 │ (Both need DB changes from #5)
   └────┬─────┘ └────┬─────┘
        │            │
        └────────┬───┘
                 │
                 ▼
            ┌──────────┐
            │Issue #23 │ (Needs both #12 and #18)
            └──────────┘
   
   WAVE 1 (Parallel): #5
   WAVE 2 (Parallel): #12, #18
   WAVE 3 (Parallel): #23
   
   Total Estimated Time: ~45-60 minutes
   

4. User Confirmation

   Show the execution plan and ask:

   Execute this plan? (yes/modify/cancel)
   - yes: Start execution
   - modify: Adjust dependencies or order
   - cancel: Abort
   

Phase 2: Parallel Execution

1. Execute by Waves

   For each wave:

   • Launch issue-implementer agents in parallel
   • Wait for all agents in wave to complete
   • Verify no conflicts before proceeding to next wave

   Example for Wave 2:

   # Launch in parallel
   Task issue-implementer(12) &
   Task issue-implementer(18) &
   
   # Wait for both to complete
   wait
   

2. Conflict Detection Between Waves

   After each wave completes:

   • Check for file conflicts between branches
   • Verify no overlapping changes
   • Report any conflicts to user before continuing

3. Progress Tracking

   ┌──────────────────────────────────────────────────────┐
   │ PROGRESS: Wave 2/3                                   │
   ├──────────────────────────────────────────────────────┤
   │ ✅ Wave 1: #5 (Complete)                             │
   │ ⏳ Wave 2: #12 (in_progress) | #18 (in_progress)     │
   │ ⏸  Wave 3: #23 (pending)                             │
   └──────────────────────────────────────────────────────┘
   

Phase 3: Review & Merge Coordination

1. Sequential Review

   Even though implementation was parallel, reviews happen sequentially to avoid reviewer confusion:

   For each issue in dependency order (5, 12, 18, 23):
     - Launch review-orchestrator(issue)
     - Wait for approval
     - If approved, continue to next
     - If changes requested, pause pipeline
   

2. Coordinated Merging

   After all reviews pass:

   For each issue in dependency order:
     - Launch issue-merger(issue)
     - Verify merge successful
     - Update remaining branches if needed
   

Phase 4: Completion Report

┌────────────────────────────────────────────────────────────┐
│ PARALLEL EXECUTION COMPLETE                                │
├────────────────────────────────────────────────────────────┤
│ Issues Implemented: 4                                      │
│ Total Time: 52 minutes                                     │
│ Time Saved vs Sequential: ~78 minutes (60% faster)         │
│                                                            │
│ Results:                                                   │
│   ✅ #5  - Merged (commit: abc123)                         │
│   ✅ #12 - Merged (commit: def456)                         │
│   ✅ #18 - Merged (commit: ghi789)                         │
│   ✅ #23 - Merged (commit: jkl012)                         │
└────────────────────────────────────────────────────────────┘

Dependency Detection Rules

Explicit Dependencies (highest priority):

• Issue body contains: "Depends on #X", "Requires #X", "Blocked by #X"
• Issue references another issue with keywords: "After #X", "Needs #X"

Implicit Dependencies (inferred):

• Both modify the same database table (check for migration files)
• One adds a function, another uses it (check for new exports/imports)
• One modifies an API endpoint, another calls it

File Conflict Analysis:

• Compare files_changed from each issue's implementation manifest
• If overlap > 30%, consider creating dependency
• Ask user to confirm inferred dependencies

Error Handling

If an Issue Fails in a Wave:

1. Continue other issues in current wave
2. Mark dependent issues as "blocked"
3. Report failure to user
4. Ask: retry failed issue / skip dependent issues / abort all

If Review Requests Changes:

1. Pause pipeline
2. Show which issues are affected
3. Ask: address feedback now / continue with others / abort

If Merge Conflict:

1. Attempt automatic resolution if simple
2. If complex, pause and show conflict
3. Ask user to resolve manually or abort

Limitations

• Maximum 10 issues per batch (to avoid complexity)
• All issues must be from the same repository
• Cannot mix issues requiring different environments
• Review coordination may still take time despite parallel implementation

Success Criteria

• All issues successfully merged OR clear failure report
• No merge conflicts left unresolved
• All tracking systems updated correctly
• Worktrees cleaned up properly