PR Review & Fix

Systematically analyze open pull requests for CI failures, code review feedback, and code quality issues — then fix them efficiently.

When to use this skill

Use this skill when you need to:

• Check the status of all open PRs (CI, reviews, conflicts)
• Triage and fix CI build/test failures on PR branches
• Address code review feedback (reviewer comments, requested changes)
• Run a scheduled health check across all open PRs
• Fix multiple PRs in a single session without losing context

Do NOT use for:

• Creating new PRs or new features
• Merging PRs (that's a manual decision)
• General code refactoring unrelated to PR feedback
• Reviewing code as a reviewer (this skill is for responding to reviews)

Workflow

Phase 1 — Discovery

1. Read references/discovery.md for the full discovery procedure.
2. Fetch the list of open PRs from GitHub:

``bash gh pr list --state open --json number,title,headRefName,statusCheckRollup,reviewDecision,mergeable --limit 30 ``

1. For each PR, classify its health status:

- 🔴 CI Failed — at least one required check failed - 🟡 Changes Requested — reviewer left requested changes - 🟢 Healthy — CI passing + approved or no review yet - ⚪ Conflict — merge conflicts detected

Phase 2 — Triage

1. Read references/triage.md for prioritization rules.
2. Prioritize by severity: CI failures > review changes > conflicts.
3. For each failing PR, identify root cause category:

- Build error — TypeScript/webpack compilation failure - Test failure — vitest/jest test assertion or timeout - Lint/type error — ESLint, type-check, or format issues - Review feedback — code style, logic, security, or design concerns

1. Present a summary table to the user before proceeding to fixes.

Phase 3 — Fix

1. Read references/fix-workflow.md for the fix procedure.
2. For each PR to fix (in priority order):

a. Stash current work: git stash b. Check out the PR branch: git checkout -B <branch> github/<branch> c. Reproduce the issue locally (build, test, or lint) d. Apply the fix e. Verify locally: build → test → lint f. Commit with conventional-changelog format: fix(<scope>): 🔧 <description> g. Push: git push github <branch> h. Return to original branch: git checkout <original> && git stash pop

1. After all fixes, present a completion summary.

Phase 4 — Verify

1. After pushing fixes, wait 1-2 minutes for CI to trigger.
2. Check CI status for each fixed PR:

``bash gh pr checks <number> ``

1. If CI still fails, loop back to Phase 3 for that PR.

Routing

Git safety rules

• Never force-push to a PR branch unless explicitly asked.
• Never amend commits that are already pushed.
• Always stash before switching branches.
• Always verify build + test locally before pushing.
• One commit per fix session — keep the diff reviewable.

Commit conventions

Follow the project's conventional-changelog format:

fix(<scope>): 🔧 <english description>

Where <scope> is the affected module (e.g., cloudrun, security, code-quality, test).

Minimum self-check

• Did you fetch the latest remote state before analyzing?
• Did you reproduce the failure locally before attempting a fix?
• Did you verify build + test pass after applying the fix?
• Did you switch back to the original branch after each fix?
• Did you present a clear summary of what was fixed and what remains?