name	description
fix-pr	Review and address GitHub PR comments. Use when working on PR feedback, fixing review comments, or responding to reviewer concerns. Handles both human and AI bot reviews.

Fix PR Comments

Workflow

0. Determine Which PR to Fix

If no PR specified: Use the PR associated with the current branch.

# Get PR for current branch
gh pr view --json number,headRefName

If a PR is specified (by number or URL):

1. Check if current branch matches the PR's head branch
2. If they don't match, ask the user before switching branches
3. Switch to the correct branch: git checkout <pr-branch>

# Get PR head branch for a specific PR number
gh pr view {pr_number} --json headRefName --jq '.headRefName'

# Check current branch
git branch --show-current

1. Check Merge Status & Rebase if Needed

Before addressing comments, ensure the branch can merge cleanly:

# Fetch latest main
git fetch origin main

# Check if branch can merge cleanly (dry run)
git merge-tree $(git merge-base HEAD origin/main) HEAD origin/main

# Or try a merge without committing
git merge origin/main --no-commit --no-ff && git merge --abort

If merge conflicts exist:

1. Rebase off latest main: git rebase origin/main
2. Resolve conflicts during rebase
3. Force push the rebased branch: git push --force-with-lease

2. Check CI Status & Fix Failures

Check GitHub Actions status for the latest commit:

# Get CI status for current branch
gh pr checks

# Get detailed run info for failing checks
gh run list --branch $(git branch --show-current) --limit 5

# View logs for a specific failed run
gh run view {run_id} --log-failed

For CI failures:

1. Identify which checks are failing (lint, tests, build, etc.)
2. Read the failure logs to understand the issue
3. Fix the underlying problem
4. If unsure about the fix, use AskUserQuestion before making changes

Common CI failures:

• Lint: Run yarn lint:fix and commit
• Type errors: Fix TypeScript issues
• Test failures: Run the specific failing test locally with yarn test -g "test name"
• Build failures: Check for missing imports, syntax errors

3. Gather PR Context

# Get PR number from current branch (or ask user)
gh pr view --json number,title,body,headRefName

# Get ALL review comments with full nested threads
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --paginate

# Get review threads (includes resolved state)
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews --paginate

# Get issue-style comments (general PR discussion)
gh pr view {pr_number} --comments --json comments

Important: Default gh pr view only shows top-level comments. Use the API endpoints to get full nested conversation threads.

4. Check Git History

# See commits since PR opened, with timestamps
git log --oneline --since="PR_CREATED_DATE" --format="%h %ci %s"

# Compare comment timestamps to commit timestamps
# Comments made BEFORE a commit may already be addressed

Cross-reference comment timestamps with commit history. A comment from Monday might be fixed by Tuesday's commit.

5. Prioritize Comments

Order of priority:

1. Most recent comments first (freshest context)
2. Unresolved threads over resolved
3. Human reviewers over bots
4. Comments with user engagement (reactions, replies)

6. Interpret Emoji Reactions

Check reactions on each comment:

Emoji	Meaning	Action
👀	"I'll take a look"	User acknowledged, may be in progress
👍	"OK" or "sounds good" or "Will fix"	User agreed, or responded to the question in the affirmative, or implement the suggestion
👎	"No" or "Wontfix"	User declined, or responded to the question in the negative, or skip this comment

7. Handle User Replies

If the user (PR author) has replied to a comment:

• Follow what they said - their reply is the decision
• Look for "done", "fixed", "will do", "good point", etc.
• Also check for pushback or clarification requests

8. Bot Comments (AI Reviewers)

Be skeptical of bot/AI reviewer comments when:

• User hasn't reacted with 👍
• User hasn't replied to it
• No human reviewer has endorsed it

Bot comments may:

• Miss project-specific context
• Suggest patterns that don't fit this codebase
• Be technically correct but not applicable here

When unsure about a bot comment: Use AskUserQuestion to confirm before implementing.

9. Address Comments

For each actionable comment:

1. Read the full thread (including nested replies)
2. Check if already addressed by recent commits
3. Make the fix or explain why not
4. Mark as addressed in your working notes

Quick Commands

# Full comment dump with reactions
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
  --jq '.[] | {id, user: .user.login, body, created_at, path, line, in_reply_to_id, reactions: .reactions}'

# Get current user's GitHub username (to identify user's own replies)
gh api user --jq '.login'

When in Doubt

Use AskUserQuestion to clarify:

• Conflicting reviewer suggestions
• Bot comments that seem off
• Architectural decisions
• Comments that could be interpreted multiple ways