203 lines
7.0 KiB
Markdown
203 lines
7.0 KiB
Markdown
---
|
|
description: Implement multiple GitHub issues in parallel with dependency analysis
|
|
argument-hint: [space-separated issue numbers]
|
|
---
|
|
|
|
# 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**
|
|
```bash
|
|
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
|