gh-laird-agents-plugins-autofix/commands/fix-github.md

# Start Autonomous Fix of GitHub Issues

Analyze all open GitHub issues, prioritize them, and begin systematically fixing or implementing them starting with the highest priority.

## What This Does

1. Creates priority labels (P0, P1, P2, P3) if they don't exist
2. Fetches all open GitHub issues with priority labels
3. Identifies the highest priority issue (P0 > P1 > P2 > P3)
4. Displays the issue details and prompt for you to fix
5. **For simple issues**: Directly troubleshoot and fix
6. **For complex issues**: Use superpowers skills to plan and execute
7. After fixing, moves to the next issue
8. Continues until all issues are resolved
9. **If there are no priority issues**: Run full regression test suite
10. Analyze regression test results and create GitHub issues for failures
11. Propose improvements (test coverage, robustness, simplicity)

Never stop, just keep looking for issues to address.

**Note**: This command uses GitHub labels (P0, P1, P2, P3) exclusively for priority detection. Issues without priority labels will not be processed by this workflow.

## Issue Complexity Detection

**Simple Issues** (direct fix):
- Single file changes
- Configuration tweaks
- Small bug fixes
- UI visibility issues
- Test timeout adjustments
- Removing deprecated code

**Complex Issues** (use superpowers):
- Multiple failing tests (>10 failures)
- Feature implementations
- Architecture changes
- Multi-file refactoring
- New functionality requiring design
- System integration issues

## Model Selection (Opus 4.5)

When spawning agents or using the Task tool during issue resolution, select the model based on task complexity:

### Issue Complexity → Model Mapping

| Issue Type | Model | Rationale |
|------------|-------|-----------|
| Simple (P2/P3, clear fix) | Sonnet | Known patterns, documented solutions |
| Complex (P0/P1, architectural) | Opus | Deep analysis, trade-off decisions |
| Regression test analysis | Sonnet | Standard test interpretation |
| Root cause investigation | Opus | Multi-factor analysis |
| Improvement proposals | Opus | Creative problem-solving |
| Labeling & formatting | Haiku | Mechanical operations |

### Escalation Triggers

**Start with Sonnet, escalate to Opus when:**
- Fix attempt fails after 2 tries with same approach
- Issue involves 5+ files requiring coordinated changes
- Root cause is unclear after initial investigation
- Multiple test failures share non-obvious common cause
- Issue requires architectural decision (new patterns, dependencies)

**Stay with Sonnet when:**
- Error messages clearly indicate the fix
- Issue matches known patterns from previous fixes
- Single file change with isolated impact
- Test failures have obvious cause (typo, missing import)

**Drop to Haiku for:**
- Adding/updating priority labels
- Posting status comments to GitHub
- Formatting commit messages
- Simple file cleanup (delete, rename)

### Model Usage by Workflow Phase

| Phase | Recommended Model |
|-------|-------------------|
| Initial complexity assessment | Sonnet |
| Simple issue: direct fix | Sonnet |
| Complex issue: systematic-debugging skill | Opus |
| Complex issue: brainstorming skill | Opus |
| Complex issue: writing-plans skill | Opus |
| Complex issue: executing-plans skill | Sonnet |
| Verification before completion | Sonnet |
| Regression test execution | Sonnet |
| Regression test analysis | Sonnet → Opus if patterns unclear |
| Improvement proposals | Opus |
| Issue creation from failures | Haiku |

### Example Task Tool Usage

```javascript
// Initial assessment - start with Sonnet
Task("analyst", "Assess complexity of issue #${ISSUE_NUM}...", model="sonnet")

// Complex root cause - use Opus
Task("debugger", "Investigate why 15 tests fail with timeout...", model="opus")

// Standard fix - use Sonnet
Task("coder", "Update package.json to fix dependency conflict...", model="sonnet")

// Label management - use Haiku
Task("labeler", "Add P2 label to issue #${ISSUE_NUM}...", model="haiku")
```

## Instructions

Start working on GitHub issues now:

```bash
# Load project-specific configuration from CLAUDE.md
if [ -f "CLAUDE.md" ]; then
  echo "📋 Reading project configuration from CLAUDE.md"

  # Check if autofix configuration exists
  if ! grep -q "## Automated Testing & Issue Management" CLAUDE.md; then
    echo "⚠️  No autofix configuration found in CLAUDE.md"
    echo "📝 Adding autofix configuration section to CLAUDE.md..."

    # Append autofix configuration to CLAUDE.md
    cat >> CLAUDE.md << 'AUTOFIX_CONFIG'

## Automated Testing & Issue Management

This section configures the `/fix-github` command for autonomous issue resolution.

### Regression Test Suite
```bash
npm test
```

### Build Verification
```bash
npm run build
```

### Test Framework Details

**Unit Tests**:
- Framework: (Configure your test framework)
- Location: (Configure test file locations)

**E2E Tests**:
- Framework: (Configure E2E test framework)
- Location: (Configure E2E test locations)

**Test Reports**:
- Location: `docs/test/regression-reports/`

AUTOFIX_CONFIG

    echo "✅ Added autofix configuration to CLAUDE.md - please update with project-specific details"
  fi

  # Extract test command
  if grep -q "### Regression Test Suite" CLAUDE.md; then
    TEST_COMMAND=$(sed -n "/### Regression Test Suite/,/^###/{/^\`\`\`bash$/n;p;}" CLAUDE.md | grep -v "^#" | grep -v "^\`\`\`" | grep -v "^$" | head -1)
    echo "✅ Regression test command: $TEST_COMMAND"
  else
    TEST_COMMAND="npm test"
    echo "⚠️  No regression test command found, using default: $TEST_COMMAND"
  fi

  # Extract build command
  if grep -q "### Build Verification" CLAUDE.md; then
    BUILD_COMMAND=$(sed -n "/### Build Verification/,/^###/{/^\`\`\`bash$/n;p;}" CLAUDE.md | grep -v "^#" | grep -v "^\`\`\`" | grep -v "^$" | head -1)
    echo "✅ Build command: $BUILD_COMMAND"
  else
    BUILD_COMMAND="npm run build"
    echo "⚠️  No build command found, using default: $BUILD_COMMAND"
  fi
else
  echo "⚠️  No CLAUDE.md found in project, using defaults"
  TEST_COMMAND="npm test"
  BUILD_COMMAND="npm run build"
fi

# Ensure priority labels exist (one-time setup per project)
if [ ! -f ".github/.priority-labels-configured" ]; then
  echo "🏷️  Checking priority labels (one-time setup)..."
  EXISTING_LABELS=$(gh label list --json name --jq '.[].name' 2>/dev/null || echo "")

  for label in "P0:Critical priority issue:d73a4a" "P1:High priority issue:ff9800" "P2:Medium priority issue:ffeb3b" "P3:Low priority issue:4caf50"; do
    IFS=':' read -r name desc color <<< "$label"
    if ! echo "$EXISTING_LABELS" | grep -qFx "$name"; then
      echo "Creating label: $name"
      gh label create "$name" --description "$desc" --color "$color" 2>/dev/null || true
    fi
  done

  # Mark labels as configured
  mkdir -p .github
  echo "# Priority labels configured on $(date -I)" > .github/.priority-labels-configured
  echo "✅ Priority labels configured"
fi

# Get highest priority issue (using labels only)
gh issue list --state open --json number,title,body,labels --limit 100 > /tmp/all-issues.json

cat /tmp/all-issues.json | jq -r '
  .[] |
  select(
    (.labels | map(.name) | any(. == "P0" or . == "P1" or . == "P2" or . == "P3"))
  ) |
  {
    number: .number,
    title: .title,
    body: (.body // ""),
    priority: (
      if (.labels | map(.name) | any(. == "P0")) then 0
      elif (.labels | map(.name) | any(. == "P1")) then 1
      elif (.labels | map(.name) | any(. == "P2")) then 2
      elif (.labels | map(.name) | any(. == "P3")) then 3
      else 4
      end
    )
  }
' | jq -s 'sort_by(.priority) | .[0]' > /tmp/top-issue.json

# Display the top issue
ISSUE_NUM=$(cat /tmp/top-issue.json | jq -r '.number')
ISSUE_TITLE=$(cat /tmp/top-issue.json | jq -r '.title')
ISSUE_BODY=$(cat /tmp/top-issue.json | jq -r '.body')
ISSUE_PRIORITY=$(cat /tmp/top-issue.json | jq -r '.priority')

echo ""
echo "🎯 Highest Priority Issue to Fix"
echo "════════════════════════════════════════"
echo "Issue: #$ISSUE_NUM"
echo "Priority: P$ISSUE_PRIORITY"
echo "Title: $ISSUE_TITLE"
echo ""
echo "Description:"
echo "$ISSUE_BODY" | head -20
echo ""
echo "════════════════════════════════════════"
echo ""
echo "📋 Starting work on issue #$ISSUE_NUM..."
echo ""

# Create fix branch
git checkout -b "fix/issue-${ISSUE_NUM}-auto" 2>/dev/null || git checkout "fix/issue-${ISSUE_NUM}-auto"

# Post comment that work started
gh issue comment "$ISSUE_NUM" --body "🤖 **Automated Fix Started**

Starting automated fix for this issue.

**Branch**: \`fix/issue-${ISSUE_NUM}-auto\`
**Started**: $(date)

Fix in progress..." 2>/dev/null || true

echo "✅ Created branch: fix/issue-${ISSUE_NUM}-auto"
echo "✅ Posted GitHub comment"
echo ""
```

## Fixing Strategy

### Step 1: Assess Complexity

Analyze the issue and determine if it's simple or complex:

**Simple Issue Indicators**:
- Description < 500 chars
- Single component/file mentioned
- Clear, specific fix described
- No test failures OR < 5 test failures
- Keywords: "hide", "timeout", "remove", "add field", "typo"

**Complex Issue Indicators**:
- Description > 1000 chars
- Multiple failing tests (>10)
- Multiple components involved
- Requires design/architecture
- Keywords: "implement", "system", "management", "integration", "~30 failures"

### Step 2A: Simple Issue - Direct Fix

For simple issues, proceed directly:

1. Read relevant code files to understand the root cause
2. Implement a complete fix (not partial)
3. Run targeted tests to verify the fix works
4. Create a git commit with the changes
5. Mark as complete

```bash
# After fixing simple issue:
git add -A
git commit -m "Fix #${ISSUE_NUM}: Brief description

Detailed explanation of what was fixed and how.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>"

# Merge to main
git checkout main
git merge "fix/issue-${ISSUE_NUM}-auto" --no-edit
git branch -d "fix/issue-${ISSUE_NUM}-auto"

# Close issue
gh issue close "$ISSUE_NUM" --comment "✅ **Issue Resolved**

[Detailed explanation of fix]

**Branch**: \`fix/issue-${ISSUE_NUM}-auto\` (merged and deleted)

🤖 Auto-resolved by autonomous fix workflow"
```

### Step 2B: Complex Issue - Use Superpowers

For complex issues requiring design and planning:

**1. Systematic Debugging (if bugs)**

If the issue involves bugs or test failures, use the systematic-debugging skill:

```
Use Skill tool: superpowers:systematic-debugging
```

This will:
- Investigate root cause thoroughly
- Analyze patterns across failures
- Test hypotheses before implementing
- Ensure understanding before solutions

**2. Brainstorming (if new features)**

If the issue requires new feature design:

```
Use Skill tool: superpowers:brainstorming
```

This will:
- Explore design alternatives
- Clarify requirements through questions
- Validate assumptions
- Refine rough ideas into concrete designs

**3. Writing Plans (for implementation)**

After design is complete, create implementation plan:

```
Use Skill tool: superpowers:writing-plans
```

This will:
- Break down into bite-sized tasks
- Specify exact file paths and changes
- Include verification steps
- Assume zero prior codebase knowledge

**4. Executing Plans**

Execute the plan in controlled batches:

```
Use Skill tool: superpowers:executing-plans
```

This will:
- Load and review the plan critically
- Execute tasks in batches
- Report progress for review between batches
- Track completion systematically

**5. Verification**

Before claiming complete, verify the fix:

```
Use Skill tool: superpowers:verification-before-completion
```

This will:
- Run verification commands
- Confirm output shows success
- Provide evidence before assertions
- Ensure tests pass before committing

### Step 3: Commit and Close

After verification passes:

```bash
# Commit changes
git add -A
git commit -m "Fix #${ISSUE_NUM}: Brief description

Detailed multi-line explanation of:
- Root cause analysis
- Solution approach
- Changes made
- Verification results

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>"

# Merge to main
git checkout main
git merge "fix/issue-${ISSUE_NUM}-auto" --no-edit
git branch -d "fix/issue-${ISSUE_NUM}-auto"

# Close issue with detailed explanation
gh issue close "$ISSUE_NUM" --comment "✅ **Issue Resolved**

## Root Cause
[Detailed analysis]

## Solution
[Approach taken]

## Changes Made
[List of changes]

## Verification
[Test results and evidence]

**Branch**: \`fix/issue-${ISSUE_NUM}-auto\` (merged and deleted)
**Commit**: [commit hash]

🤖 Auto-resolved by autonomous fix workflow with superpowers"
```

## Example Workflow

### Simple Issue Example:
```
Issue #240: TypeScript compilation errors in disabled-features
→ Direct fix: Delete broken test files
→ Verify: $BUILD_COMMAND (from CLAUDE-AUTOFIX-CONFIG.md)
→ Commit and close
```

### Complex Issue Example:
```
Issue #222: Review Management system broken (~30 test failures)
→ Complexity detected: >30 failures, multiple components
→ Use superpowers:systematic-debugging
  - Investigate root cause
  - Analyze test failure patterns
  - Identify common issues
→ Use superpowers:brainstorming
  - Design fix approach
  - Validate assumptions
→ Use superpowers:writing-plans
  - Create implementation plan
  - Break into tasks
→ Use superpowers:executing-plans
  - Execute in batches
  - Review between batches
→ Use superpowers:verification-before-completion
  - Run all tests
  - Confirm passing
→ Commit and close with evidence
```

## Skip Criteria

Skip to next issue if:
- Issue requires external dependencies (API keys, services)
- Issue is blocked by another issue
- Issue requires user input/decision
- Issue is too large even for superpowers (>100 test failures, major architecture change)

Post a comment explaining why skipped:

```bash
gh issue comment "$ISSUE_NUM" --body "⏭️ **Skipped for Manual Review**

This issue requires [reason] and cannot be automatically resolved.

**Recommendation**: [Suggested approach]

Moving to next priority issue.

🤖 Autonomous fix workflow"
```

## No Priority Issues Found

If no issues with P0-P3 labels exist, run full regression testing:

### Step 1: Run Regression Test Suite

```bash
# Run complete regression test suite (uses command from CLAUDE-AUTOFIX-CONFIG.md)
$TEST_COMMAND

# This command is configured in the project's CLAUDE-AUTOFIX-CONFIG.md
# It should run all tests and generate a report with GitHub issue integration
```

### Step 2: Analyze Regression Results

The regression test suite automatically:
- Creates GitHub issues for new test failures
- Updates existing issues with regression data
- Applies priority labels (P0-P3) based on severity

**Priority Assignment**:
- **P0 - Critical**: Auth, security, crashes, data loss
- **P1 - High**: Major features broken, CRUD operations failing
- **P2 - Medium**: Filtering, sorting, search, display issues
- **P3 - Low**: UI issues, validation, edge cases

### Step 3: Review Generated Issues

Check newly created issues:

```bash
# View issues created by regression test
gh issue list --label "test-failure" --state open --json number,title,labels --limit 20
```

### Step 4: Restart /fix-github Workflow

After regression testing creates new issues, restart the workflow:

```bash
# Refresh issue list and continue
/fix-github
```

The workflow will now pick up the newly created issues and begin fixing them.

### Step 5: If All Tests Pass

If regression tests pass completely (no issues created):

**Propose Improvements**:

1. **Test Coverage Analysis**
   - Identify untested code paths
   - Add missing E2E scenarios
   - Improve edge case coverage

2. **Code Quality Improvements**
   - Refactor complex functions
   - Reduce code duplication
   - Improve type safety

3. **Performance Optimizations**
   - Identify slow queries
   - Add caching where needed
   - Optimize bundle size

4. **Documentation Updates**
   - Update API docs
   - Add code examples
   - Document best practices

**Create Improvement Issues**:

```bash
# Create issues for proposed improvements
gh issue create \
  --label "enhancement,proposed" \
  --title "P3-Improvement: [Brief description]" \
  --body "## Proposed Improvement

[Detailed description]

## Rationale
[Why this improvement is valuable]

## Implementation
[How to implement]

## Impact
[Expected benefits]

🤖 Proposed by autonomous improvement workflow"
```

---

## MANDATORY: Continuous Loop

**THIS WORKFLOW RUNS FOREVER UNTIL MANUALLY STOPPED.**

After completing ANY of these actions, you MUST immediately continue:

1. **After fixing and closing an issue** → Fetch next priority issue
2. **After skipping an issue** → Fetch next priority issue
3. **After running regression tests** → Check for new issues created
4. **After proposing improvements** → Fetch next priority issue
5. **If no issues found** → Run regression tests, then check again

### Loop Implementation

After every issue is resolved, skipped, or when checking for work:

```bash
# Fetch next highest priority issue
gh issue list --state open --json number,title,body,labels --limit 100 > /tmp/all-issues.json

PRIORITY_ISSUES=$(cat /tmp/all-issues.json | jq '[.[] | select(.labels | map(.name) | any(. == "P0" or . == "P1" or . == "P2" or . == "P3"))] | length')

if [ "$PRIORITY_ISSUES" -gt 0 ]; then
  echo "🔄 Found $PRIORITY_ISSUES priority issues. Continuing..."
  # Process next issue (repeat from "Get highest priority issue" section)
else
  echo "✅ No priority issues. Running regression tests..."
  # Run regression tests, then loop back
fi
```

### Never Stop

- **DO NOT** wait for user input between issues
- **DO NOT** stop after fixing one issue
- **DO NOT** ask "should I continue?"
- **DO** keep processing issues until the queue is empty
- **DO** run regression tests when queue is empty
- **DO** process any new issues created by regression tests
- **DO** propose improvements only when everything passes
- **DO** loop back and check for new issues after proposing improvements

**The only way this workflow stops is if the user manually interrupts it.**

---

🤖 **Ready to fix issue #$ISSUE_NUM! Start working on it now, then IMMEDIATELY continue to the next issue.**