| name | address-review-comments |
| description | Address actionable pull request review feedback end-to-end.
Use when asked to address review comments, handle requested changes,
go through PR feedback, fix reviewer comments, or continue from a review
finding list. Resolve the PR, inspect unresolved review threads, triage
clear fixes versus subjective questions, implement selected changes, commit
each addressed comment or inseparable comment cluster, push, and monitor CI.
|
| user-invocable | true |
| allowed-tools | Bash, Edit, Read, Write, Glob, Grep, Skill, AskUserQuestion, Task |
Address Review Comments
Work through PR review feedback without losing the boundary between review
comments, commits, and verification.
Arguments
$ARGUMENTS may be a PR URL, <owner>/<repo>#<number>, a PR number, or a
short instruction such as address comments 1-3.
If empty, detect the PR from the current branch.
Prerequisites
Read the repo instructions first (AGENTS.md, CLAUDE.md, or equivalent).
If none exists, follow the user's repo-entry rule before editing.
Read these global rules when relevant:
~/.config/agents/rules/git.md~/.config/agents/rules/github.md~/.config/agents/rules/tool-results.md~/.config/agents/rules/closing-the-loop.md~/.config/agents/rules/testing.mdagents/gh-reference.md from the dotfiles repo before gh commands
If the PR remote is a GitHub Enterprise host, look for local host-specific
GitHub CLI guidance or a dedicated gh wrapper before running commands.
Use that wrapper consistently in place of bare gh for auth, PR reads, API
calls, replies, pushes, and checks; Enterprise instances often need extra host,
proxy, or token configuration that bare gh will not pick up.
Workflow
1. Resolve the PR and branch
Source context from local git first:
- repo from
git remote get-url origin
- branch from
git branch --show-current
- HEAD from
git rev-parse HEAD
Resolve the PR from $ARGUMENTS, or with:
gh pr view --json number,url,title,headRefName,isDraft
If the local branch is not the PR head branch, stop and ask.
Do not address comments on the wrong branch.
2. Fetch review feedback
Use thread-aware reads for GitHub review comments.
Prefer GraphQL through gh api graphql because flat REST comment lists do not
preserve enough thread state.
Fetch at least:
- review threads:
isResolved, isOutdated, file path, line or original line,
URL, comments, authors, and bodies
- PR reviews and review states
- top-level PR comments when the user says "all feedback" or mentions a
non-inline reviewer comment
Ignore resolved or outdated threads unless the user explicitly asks to revisit
them.
Treat existing human or prior-agent replies as a signal that a thread may
already be handled; verify before acting.
3. Triage
Process comments in file order, then line order.
Group comments only when they touch the same hunk or are logically inseparable.
Use these buckets:
- Auto-address: factual, low-risk, clearly correct, and small.
- Ask user: subjective, ambiguous, behavioral, API-affecting, or risky.
- Skip: already handled, obsolete, duplicate, wrong, or intentionally not
being changed.
Bias toward asking when uncertain.
A wrong fix costs more than a short question.
4. Implement selected fixes
For each auto-addressed or user-selected item:
- Read the surrounding code and relevant style/linter config.
- Make the smallest change that addresses the comment.
- Avoid unrelated refactors and cleanup.
- Verify autonomously with the cheapest meaningful check.
- If verification fails, inspect the output, fix, and rerun.
For documentation-only changes, targeted formatting and searches may be enough.
For code changes, run the relevant test, build, lint, or smoke command.
5. Commit each addressed item
Use the commit skill.
Default to one commit per review comment.
If multiple comments touch the same hunk and cannot be separated cleanly, make
one commit for that cluster and say why.
Do not sweep unrelated dirty work into the commit.
Think in hunks, not files.
6. Reply or resolve only when authorized
Do not post GitHub replies, submit reviews, or resolve threads unless the user
asked for public GitHub updates or that is clearly part of the requested
workflow.
When posting through the user's identity:
- include the commit link or short SHA for addressed comments
- explain skips briefly
- append the sign-off required by
~/.config/agents/rules/github.md
7. Push and monitor
After commits are ready, use the push skill.
After every push, immediately invoke ci-monitor for the affected PR.
If ci-monitor reports danger/pr-check failures, chain into fix-pr-checks
and keep monitoring until Danger reruns.
Do not report done while checks are still running unless the monitor times out
or the available tooling cannot see the remaining system.
If monitoring is blocked, report the exact blocked surface.
8. Final report
Keep the final report concise:
PR #N — title
Addressed:
- file:line — summary — commit
Asked:
- file:line — question
Skipped:
- file:line — reason
Verification:
- command/result
- CI status
Mention unresolved or deferred comments explicitly.
