PR Review Response

Fetch PR review comments, categorize them, draft responses, and optionally apply code fixes.

Usage

/phx:pr-review 42 # Address comments on PR #42 /phx:pr-review 42 --fix # Address + apply code fixes /phx:pr-review https://... # Full URL also works

Arguments

$ARGUMENTS = PR number (or URL), optionally followed by --fix .

Workflow

Step 1: Fetch PR Context

Get PR metadata

gh pr view {number} --json title,body,state,baseRefName,headRefName

Get all review comments (inline + general)

gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate

Get the diff for context

gh pr diff {number}

Parse the PR number from $ARGUMENTS . If a URL, extract the number from it. Detect --fix flag.

Step 2: Categorize Comments

Group each comment into one of these categories:

Category Signal Action

Code change "should be", "change to", "use X instead" Draft fix + response

Question "why", "what if", "how does" Draft explanation

Nitpick "nit:", style-only, formatting Quick acknowledgment

Praise "nice", "good", "LGTM" No action needed

Discussion Architecture, trade-offs, alternatives Draft thoughtful response

Step 3: Map to Code Locations

For each code-change comment:

• Find the file and line from the comment's path and position

• Read the current code at that location

• Understand the reviewer's suggestion in context

• Check if the suggestion conflicts with Iron Laws

Step 4: Draft Responses

For each comment, draft a response following patterns in references/response-patterns.md .

Present ALL draft responses to the user for review:

PR #{number}: {title}

{n} comments to address

Code changes ({n}):

1. {file}:{line} — {reviewer suggestion} → {proposed fix}

Questions ({n}):

1. {question summary} → {draft answer}

Nitpicks ({n}):

1. {nit} → Acknowledged

Discussion ({n}):

1. {topic} → {draft response}

Step 5: Apply Fixes (if --fix)

If --fix flag provided AND user approves:

• Apply code changes from approved code-change responses

• Run mix compile --warnings-as-errors && mix test

• If tests pass, present the changes

• Do NOT commit or push — leave that to the user

Step 6: Post Responses (with user approval)

STOP and ask user to review all draft responses.

After user approves (may edit some):

Post each response as a reply to the original comment

gh api repos/{owner}/{repo}/pulls/{number}/comments/{id}/replies
-f body="{response}"

Iron Laws

• NEVER auto-post responses — Always show drafts and get explicit approval

• NEVER dismiss a review — Only the reviewer should dismiss

• Iron Laws override reviewer suggestions — If a reviewer suggests code that violates an Iron Law, explain why in the response

• Keep responses constructive — Acknowledge the feedback, explain reasoning

• Separate fixes from responses — Apply code changes in a separate step

Integration

PR receives review comments ↓ /phx:pr-review {number} ← YOU ARE HERE ↓ Fix code? → --fix flag applies changes ↓ Post responses (after user approval) ↓ Push changes → user handles git push

Next Steps

After addressing review comments, suggest follow-up:

• /phx:plan — Create a plan if findings reveal scope gaps
• /phx:verify — Run full verification before pushing
• Push changes — user handles git push

References

• references/response-patterns.md — Response templates and common patterns