Pr Review Fix

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

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

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

• 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

• Read references/triage.md for prioritization rules.
• Prioritize by severity: CI failures > review changes > conflicts.
• 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
• Present a summary table to the user before proceeding to fixes.

Phase 3 — Fix

• Read references/fix-workflow.md for the fix procedure.
• 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

• After all fixes, present a completion summary.

Phase 4 — Verify

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

   gh pr checks <number>

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

Routing

| Task | Read |

| --- | --- |

| Discover and list open PR status | references/discovery.md |

| Prioritize which PRs to fix first | references/triage.md |

| Execute fixes on PR branches | references/fix-workflow.md |

| Understand project CI pipeline | references/ci-pipeline.md |

| Common fix patterns and recipes | references/fix-recipes.md |

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?