Address Pr Comments

Address PR Comments

Overview

Collect complete PR feedback, verify that the current checkout exactly matches the PR head, classify each source, validate every claim against current code, and implement only still-valid fixes. Create local reviewable commits; do not push, reply, or resolve GitHub threads unless the user explicitly requests those actions.

Workflow

1. Resolve the PR and its head branch.
2. Verify gh availability and authentication.
3. Match the exact clean worktree and synchronize it safely.
4. Collect complete top-level, review-body, and inline feedback.
5. Classify and validate each item.
6. Apply one comment's fix and run targeted checks.
7. Create one local commit for that resolved comment.
8. Repeat from the synchronization check for the next comment.
9. Report addressed, rejected, and unclear feedback with evidence.

1. Resolve the PR

Use the provided number, or infer the PR from the current branch:

gh pr view --json number,title,url,headRefName,headRefOid,headRepository,headRepositoryOwner,isCrossRepository
gh pr view <number> --json number,title,url,headRefName,headRefOid,headRepository,headRepositoryOwner,isCrossRepository

If inference fails, ask for a PR number or URL. Record the returned head branch and head repository; a PR number alone is not enough to select a checkout.

2. Verify GitHub Access

gh --version
gh auth status

Stop and report a missing or unauthenticated CLI.

3. Verify the Exact Checkout

Inspect all worktrees before editing:

git worktree list --porcelain
git branch --show-current
git status --short

• Work only in a checkout whose current branch exactly equals headRefName.
• For cross-repository PRs, also verify that the checkout tracks the returned head repository rather than an unrelated branch with the same name.
• Use a configured remote whose URL matches the head repository; do not assume that remote is origin.
• If no exact checkout exists, ask before creating or switching one.
• If the target worktree has pre-existing changes, stop and ask. Never stash, reset, overwrite, or mix user changes into review-fix commits.

Synchronize the clean PR branch without rewriting history:

git fetch <head-remote> <head-branch>
git rev-list --left-right --count HEAD...FETCH_HEAD

Fast-forward a behind-only checkout. If local and remote histories diverge, stop and ask rather than rebasing, merging, or force-updating without approval. Repeat this comparison immediately before every separate review-fix commit; if the remote moved after editing began, stop and reconcile safely first.

4. Collect Complete Feedback

Resolve bundled paths from the directory containing this SKILL.md, then run:

python3 ./scripts/list_comments.py --pr <number> --json

Use --repo OWNER/REPO when running outside the target repository. Add --include-resolved only when historical resolved threads are relevant.

The JSON output:

• paginates top-level comments, reviews, inline comments, and review threads;
• includes full body text plus a short excerpt;
• filters empty COMMENTED review shells;
• maps inline replies to their root thread and filters resolved threads by default;
• classifies source as human, ai_reviewer, automation, or unknown;
• extracts recognizable “Prompt for AI Agents” blocks without discarding the body.

Treat the helper output as an inventory, not a decision. Ignore deployment/status automation that contains no review feedback.

5. Classify and Validate

Read ./references/validation-checklist.md before applying comments.

Mark each item as:

• valid
• invalid
• already_fixed
• out_of_scope
• needs_clarification

Prioritize blocking human concerns, then high-confidence automated findings, then style and nits. Treat every automated suggestion as advisory. Verify embedded agent prompts against current files and repository conventions.

6. Implement and Verify

Handle one validated comment at a time. Keep unrelated cleanup out of the diff. Run the narrowest relevant tests, type checks, lint, or reproduction before committing. If a check fails, fix the working tree and rerun it; do not create a known-broken commit.

7. Commit Locally

For each resolved valid comment:

1. Recheck the remote comparison from section 3.
2. Stage only the files required for that comment.
3. Inspect git diff --staged and git diff --staged --stat.
4. Use an installed commit-message skill when available; otherwise match git log --oneline -10 and the repository's local conventions.
5. Create exactly one local commit for that comment.

Do not combine distinct comments unless their fixes are technically inseparable. Do not commit rejected or unclear items. Do not push, post replies, or resolve threads as part of this workflow.

8. Report Back

Provide:

• addressed comment URLs, files, and commit hashes;
• rejected or already-fixed comment URLs with reasons;
• precise questions for needs_clarification items;
• checks run and their results;
• the final branch/worktree and whether it is ahead or behind its remote.

Quick Commands

python3 ./scripts/list_comments.py --json
python3 ./scripts/list_comments.py --pr <number> --json
python3 ./scripts/list_comments.py --repo OWNER/REPO --pr <number> --json
python3 ./scripts/list_comments.py --pr <number> --json --include-resolved

git add <files-for-one-comment>
git diff --staged --stat
git diff --staged
git commit -m "<repository-style-message>"