Address PR Comments

Purpose

Read PR review comments and address them by making code changes, answering questions, or discussing feedback with the user. Post replies to acknowledge addressed comments.

Prerequisites

• •Must be on the PR's branch (not main/master)
• •PR must exist and be open

Workflow

Step 1: Verify Environment

Check we have a GitHub remote and are on a feature branch:

git remote -v
git status
git rev-parse --abbrev-ref HEAD

STOP if:

• •No remote exists → "This skill requires a GitHub remote. Please add one with git remote add origin <url> first."
• •On main/master → "Please switch to the PR's branch first. You can find it with gh pr view <number> --json headRefName"
• •Uncommitted changes → "Please commit or stash your changes first."

Step 2: Identify the PR

User will provide a PR number (e.g., #12 or 12), or auto-detect from current branch:

gh pr view --json number,state,title

If no PR exists for the current branch, ask the user for a PR number.

Validate the PR is open. If closed/merged, inform the user and stop.

Step 3: Fetch PR Comments

Retrieve general PR comments:

gh pr view <number> --comments

Present the comments to the user, showing:

• •Comment author
• •Comment body
• •When it was posted

If no comments exist, inform the user and stop.

Step 4: Process Comments

For each comment, work with the user to determine the appropriate action:

1. •

   Present the comment clearly to the user

2. •

   Ask what action to take using AskUserQuestion:

   • •"Make code changes" → implement the requested changes
   • •"Post a reply" → draft and post a response
   • •"Discuss first" → talk through the feedback before acting
   • •"Skip this comment" → move to the next comment
3. •

   Execute the action:

   • •Code changes: Make the changes, then optionally post a reply confirming what was done
   • •Reply: Draft a reply and post it using gh pr comment
   • •Discussion: Explore the codebase if needed, discuss with user, then decide on action
4. •

   Track progress using TodoWrite to show which comments have been addressed

5. •

   Loop until all comments are processed or user wants to stop

Step 5: Post Replies

When posting replies to acknowledge addressed comments:

gh pr comment <number> --body "<reply>"

Keep replies concise and professional. Reference specific changes made if applicable.

Step 6: Commit and Push

After making code changes:

git add .
git status
git commit -m "<summary of changes addressing review feedback>"
git push

Report what was changed and pushed.

Step 7: Report Completion

Summarise what was done:

• •Number of comments addressed
• •Code changes made (files modified)
• •Replies posted
• •Any comments skipped or left unresolved

Guidelines

DO:

• •Present each comment clearly before asking for action
• •Make requested code changes accurately
• •Post concise, professional replies
• •Commit and push after making changes
• •Track progress through comments

DON'T:

• •Make changes without user approval
• •Post replies the user hasn't approved
• •Skip comments without asking
• •Leave uncommitted changes

Handling Common Scenarios

Comment requests a code change: Implement the change, verify it works, then offer to post a reply confirming it's done.

Comment asks a question: Discuss with the user, explore the codebase if needed, then draft a reply.

Comment is unclear: Ask the user for clarification before taking action.

Multiple comments on same topic: Group them together and address as a single unit.

Disagreement with feedback: Discuss with user, then post a reply explaining the reasoning if they want to push back.

Checklist

• • Verify on feature branch (not main/master)
• • Identify PR (from argument or auto-detect)
• • Verify PR is open
• • Fetch and display comments
• • Process each comment with user
• • Make code changes as needed
• • Post replies as needed
• • Commit and push changes
• • Report what was done