gh-fix-pr-reviews

name

gh-fix-pr-reviews

description

Fetch and address GitHub pull request code reviews. Use when Codex is asked to inspect PR review comments, decide whether reviewer findings are real defects or misunderstandings, fix valid issues locally, run focused validation, and create a local commit without pushing. Triggers include GitHub PR URLs, PR numbers, code review comments, requested changes, review threads, and requests to "fix PR review feedback" or "address review comments".

Gh Fix Pr Reviews

Overview

Use this workflow to turn GitHub PR review feedback into verified local code changes. Treat review comments as hypotheses: fetch the PR and review context first, prove whether each issue is real from the code, fix only real defects, and leave misunderstood comments unfixed with a clear explanation.

Workflow

1. Identify the repository and PR.

   • Accept a GitHub PR URL, owner/repo#123, or a PR number when the local repository remote clearly identifies owner/repo.
   • If the repository or PR cannot be determined from local context, ask one concise question before making changes.

2. Fetch complete PR context before editing.

   • Prefer available GitHub MCP tools for structured data: PR metadata, changed files, diff, issue comments, review submissions, and unresolved review threads.
   • If using gh, fetch equivalent context with commands such as gh pr view, gh pr diff, gh pr checkout, and gh api for review comments or threads.
   • Read the affected files locally after fetching the review context. Do not rely only on the diff when deciding if feedback is correct.

3. Classify each review issue.

   • Real: The comment identifies a reproducible bug, broken contract, missing case, confusing behavior, bad test, security issue, performance issue, or maintainability problem that is supported by the current code.
   • Misunderstanding: The current code already handles the case, the reviewer inferred an impossible state, the comment depends on stale code, or the requested change would violate an existing requirement.
   • Unclear: The comment might be valid but cannot be proven from the available code or tests. Investigate further before changing code.
   • If the review issue may or may not be relevant after local investigation, ask the user before changing code. Include concise reasons why it could be relevant and concise reasons why it may not be relevant, then wait for direction.

4. Fix only real issues.

   • Keep edits narrowly scoped to the reviewed problem.
   • Preserve unrelated user or branch changes. Check git status before editing and before committing.
   • Add or update focused tests when the issue is behavioral or likely to regress.
   • Do not perform unrelated refactors while addressing review feedback.

5. Validate the result.

   • Run the most focused test or check that covers the changed code.
   • Broaden validation only when the affected surface is shared or the local project convention requires it.
   • If validation cannot be run, record the reason in the final response.

6. Create local commits, but do not push.

   • Create a separate commit for each real review issue that was fixed.
   • Stage only files changed for that specific review issue before each commit.
   • Do not include unrelated worktree changes.
   • If multiple review comments describe the same underlying defect, fix them together in one commit and mention that grouping in the final response.
   • If one review issue requires touching multiple files, include all required files for that issue in the same commit.
   • Never push the branch unless the user explicitly asks in a later message.

Commit Message

Use this subject format:

where/what: short description

Use where for the main area changed, such as app, api, auth, docs, tests, or a local module name. Use what for the kind of change, such as fix, ref, test, docs, add, or chore.

Examples:

app/ref: clean up run function
api/ref: add user handler
auth/fix: preserve session refresh errors
tests/add: cover empty review comments

When the change is global and no specific where applies, omit the where/ prefix:

ref: rename heco to lace
fix: normalize PR review handling

Reporting

In the final response, include:

• Which review issues were real and fixed.
• Which review issues were misunderstandings, with brief evidence.
• The commit hash and subject for each fixed review issue.
• Validation commands run and their results.
• Any review issue left unresolved and why, including any unclear issue where the user had to decide relevance.