Pr Review Fix Pipeline

Autonomous PR Review & Fix Pipeline

When to Use This Skill

Use this skill when:

• You want both review AND automatic fixes in one workflow
• PR has blocking issues that need immediate resolution
• You trust Claude to apply non-controversial fixes (typos, lint errors, obvious bugs)
• You want to minimize back-and-forth between review and implementation

⚠️ Important Notes

This is an autonomous workflow that will:

• Review the PR
• Apply fixes for blocking issues
• Run tests and lint
• Commit changes
• Push to the PR branch

Only use this when:

• You're comfortable with Claude modifying code without asking
• The PR is on a feature branch (not main/develop)
• You can review the resulting diff before merging

Pipeline Steps

Step 1: Fetch and Analyze

1. Get PR information

   gh pr view [NUMBER] --json headRefName,baseRefName,title,body
   

2. Fetch the diff (never cached)

   gh pr diff [NUMBER]
   

3. Checkout the PR branch

   git fetch origin [HEAD_REF]
   git checkout [HEAD_REF]
   

Step 2: Categorize Issues

Analyze every file change and categorize issues:

• [BLOCKING]: Must be fixed before merge

  • Bugs and logic errors
  • TypeScript errors
  • Breaking changes
  • Security issues
  • Missing error handling

• [RECOMMENDATION]: Should be fixed but not critical

  • Performance improvements
  • Better patterns available
  • Code style issues

• [NIT]: Nice-to-have improvements

  • Whitespace, formatting
  • Comment improvements
  • Variable naming

Step 3: Auto-Fix Blocking Issues

For each [BLOCKING] issue:

1. Create a Task sub-agent to implement the fix

   Task: Fix [specific issue]
   Context: [issue description and location]
   Constraint: Only fix this specific issue, don't refactor
   

2. Wait for sub-agent completion before proceeding to next issue

3. Track fixes with TodoWrite for visibility

Step 4: Run Validation (with Dev Server Protection)

Critical: Verify dev server status BEFORE running tests

# Check if dev server is already running
lsof -ti:3000 || echo "No dev server"

# If dev server needed but not running, start it in background
# If dev server already running, leave it alone

# Run validation suite
npm run lint
npm run type-check
npm run lint:css
npm test

Step 5: Handle Test Failures

If tests fail after fixes:

1. Apply 3-attempt limit per test (use test-fix skill principles)
2. If test fails after 3 attempts, flag it for human review
3. Continue with other tests (don't block entire pipeline)

Step 6: Commit and Push

1. Create a single commit with all fixes

   git add -u
   git commit -m "fix: auto-applied blocking issue fixes from code review
   
   - [list of fixes applied]
   
   Applied via autonomous PR review pipeline"
   

2. Push to PR branch

   git push origin [HEAD_REF]
   

Step 7: Report Results

Present this summary:

## Autonomous PR Review & Fix Pipeline Results

### Original Review Findings

#### 🔴 Blocking Issues (Auto-Fixed)
[List each blocking issue and how it was fixed]

#### 🔴 Blocking Issues (Flagged for Human Review)
[List issues that couldn't be auto-fixed]

#### 🟡 Recommendations (Not Auto-Fixed)
[List recommendations for user to consider]

#### 🟢 What Looks Good
[Positive observations]

### Fixes Applied

**Commit**: [commit hash]
**Files Modified**: [list of files]

[Detailed list of what was changed]

### Final CI Status

- **Lint**: [PASS/FAIL]
- **Type Check**: [PASS/FAIL]
- **CSS Lint**: [PASS/FAIL]
- **Tests**: [PASS/FAIL - with details on any flagged tests]

### Next Steps

- [ ] Review the auto-applied fixes: `git diff [BASE]..[HEAD]`
- [ ] Address flagged blocking issues (if any)
- [ ] Consider recommendations
- [ ] Merge when ready

Safety Guardrails

Never Auto-Fix

Do NOT automatically fix:

• Architectural decisions
• API contract changes
• Feature behavior changes
• Test expectations (unless test is clearly wrong)
• Anything that changes user-facing behavior

If in doubt, flag for human review instead of auto-fixing.

Dev Server Protection

NEVER:

• Kill or restart the dev server
• Run commands that interfere with running processes
• Assume dev server state

ALWAYS:

• Check if dev server is running before running tests
• Run tests in separate process
• Ask user if you need to start dev server

Commit Safety

Before committing:

• Verify no merge conflict markers
• Verify no debug code introduced
• Verify all auto-fixes are intentional
• Run full lint and test suite

Rollback Instructions

If the pipeline produces bad results:

# Reset to state before pipeline ran
git reset --hard origin/[HEAD_REF]

# Or revert the commit
git revert [COMMIT_HASH]
git push origin [HEAD_REF]

Example Usage

User says: "Auto-review and fix PR #123"

Pipeline:

1. Fetches PR #123 diff
2. Finds 5 blocking issues: 3 lint errors, 1 TypeScript error, 1 missing await
3. Spawns 5 Task agents to fix each issue in parallel
4. After fixes, runs lint/test suite
5. All tests pass
6. Commits: "fix: auto-applied blocking issue fixes from code review"
7. Pushes to PR branch
8. Reports what was fixed and final status

Total time: 3-5 minutes (vs. 15-30 minutes of back-and-forth)

When NOT to Use This Skill

Don't use this skill if:

• PR changes architectural patterns
• PR has controversial design decisions
• You want to review fixes before they're applied
• You're working on main/develop branch directly

In those cases, do a manual review instead.

Notes

• Uses Task tool for parallel sub-agents (Claude Code's native parallelization)
• Combines review, implementation, and CI checking into one atomic operation