review-and-fix

Run a review-and-fix cycle on a pull request. The PR must already exist. If a PR number is provided as an argument, use it; otherwise use the PR associated with the current branch.

Step 1: Resolve PR Context

Determine which PR to work on:

# If $ARGUMENTS is set, use it as the PR number; otherwise resolve from current branch
PR_NUMBER="${ARGUMENTS:-}"
if [ -z "$PR_NUMBER" ]; then
    PR_NUMBER=$(gh pr view --json number -q '.number' 2>/dev/null || echo "")
fi

If no PR can be resolved, tell the user and stop. Do not try to open a PR — this command is fix-only.

Fetch PR metadata to confirm the target:

gh pr view "$PR_NUMBER" --json number,title,headRefName,baseRefName,state,mergeable

Confirm the PR is open. If it is merged or closed, stop and report.

Check that the current working tree matches the PR's headRefName. If not, tell the user and stop — do not switch branches automatically, since the user may have unsaved work or be in a specific worktree. Tell them the command required branch and let them switch.

Step 2: Dispatch Review Subagent

Use the Agent tool to run a code review in a subagent. This keeps the raw diff output out of the main context and isolates the review findings.

Agent prompt template:

Review PR #<number> in the current repository. The head branch is <headRefName>
and the base is <baseRefName>.

1. Get the diff with: gh pr diff <number>
2. Analyze every changed hunk for:
   - Bugs and logic errors
   - Missing error handling on system-boundary calls
   - Style violations against project conventions (read CLAUDE.md if present)
   - Missing tests for new behavior
   - Performance regressions on hot paths
   - Accessibility issues in view code (if the project has accessibility rules)
3. For each finding, return a JSON object:
   {
     "path": "relative/path.ext",
     "line": 42,
     "confidence": 0-100,
     "category": "bug|style|test|perf|a11y|other",
     "description": "What is wrong",
     "suggested_fix": "Concrete change to make (code snippet or instruction)"
   }
4. Return a JSON array of findings. If nothing is wrong, return [].

Be strict about confidence scoring. Only score >= 80 for issues you are certain
are real bugs or clear policy violations. Score 60-79 for likely-but-not-certain
issues. Score below 60 for subjective preferences — these will be discarded.