haacked/dotfiles/address-pr-reviews

Address PR Reviews

Evaluate a pull request's unresolved inline review comments interactively. Comments may come from any reviewer — humans, or bots such as Copilot, ReviewHog, Greptile, and Graphite. For each comment, determine whether it identifies a real issue or is a false positive, then fix or dismiss accordingly.

This skill never requests a review from anyone, and never waits for one. It only evaluates comments that already exist on the PR — waiting for in-flight reviews and re-consolidating afterwards belongs to the wait-for-pr-reviews skill, which chains this one before and after the wait.

Requires Bash 4+, Git, jq, and authenticated gh 2.53+. Resolve scripts/ and references/ paths against this skill's directory. PR detection, comment fetching, thread resolution, and both prose passes carry what they need, so they work when only this skill folder is copied into a sandbox.

references/plain-writing/ and references/comment-cleanup/ hold copies of those two skills. Step 3 and Step 5 read the copy rather than invoking the skill, so each pass runs by the same rules whether or not the harness has that skill installed. A relative path written inside a copy resolves against that copy's own directory. The bundled prose rules end with a python3 lint, so a sandbox without python3 leaves that lint unrun: say so in the summary and apply the rules on their own. The step record in Steps 2 and 5 skips itself when no clone is present.

Arguments (parsed from user input)

• No arguments: detect PR from the current branch
• PR URL: https://github.com/owner/repo/pull/123
• PR number: 123 (infers repo from current directory)
• --no-commit: stage the fixes but don't commit them, so the invoker owns the commit. It also skips the push, because the run adds nothing to push.
• --no-push: commit fixes as usual but never push — the invoker owns the push (wait-for-pr-reviews passes this while reviews are in flight)
• --fixed-file <path>: under --no-push, append each fixed bot comment to this file, so the invoker can reply after its push (wait-for-pr-reviews passes this)
• --unattended: nobody is watching this run, so treat this skill's approval gates as approved and never ask. babysit-prs passes it on every dispatch. Each gate below states the default it takes.

Example invocations:

• /address-pr-reviews -- process review comments for the current branch's PR
• /address-pr-reviews https://github.com/owner/repo/pull/123 -- process a specific PR
• /address-pr-reviews 123 -- process PR #123 in the current repo
• /address-pr-reviews 123 --unattended -- process PR #123 with no one watching

Asking the user

Two steps below stop for approval: the fix confirmation in Step 3 and the push in Step 5. Replies to bot comments never stop for approval. Ask through the harness's structured question tool whenever the harness has one — AskUserQuestion in Claude Code and PostHog Desktop. A task runner reads a question asked in ordinary prose as the end of the turn, so the run finishes at the gate with the work half done, and nothing afterwards tells that apart from a completed pass. A harness without such a tool asks in prose as usual.

Under --unattended, do not ask at all. Take the default each gate names.

Your Task

Step 1: Detect PR

Remember and strip --no-commit, --no-push, --fixed-file <path>, and --unattended — the detection script treats any non-flag token as the PR argument. Then run it with what remains, or with no argument at all when nothing remains:

scripts/detect-pr.sh --json "<remaining args>"

This outputs {"pr_number", "org", "repo", "head_branch", "head_sha", "error"}. JSON mode always exits 0, so read .error: if it is non-null, report it and stop. org and repo come back lowercased, which every gh call below accepts.

Save PR_NUMBER, ORG, REPO (as <org>/<repo>), HEAD_BRANCH, and HEAD_SHA. Resolve the PR once, here. An agent harness checks the PR head out detached, where the detection script resolves the PR from HEAD's commit; once this skill commits a fix, HEAD moves off the PR head and a second lookup finds nothing. Step 5 needs HEAD_BRANCH to push.

Abort now if git rev-parse HEAD differs from HEAD_SHA. An invocation with an explicit PR URL or number can run from a checkout that isn't the PR head — a stale worktree, or one left on unrelated commits — and Step 5's push would then carry that unrelated HEAD onto the PR's branch.

Step 2: Fetch and Filter Unaddressed Comments

First, check best-effort whether any reviews are still in flight — their comments haven't landed yet:

scripts/check-pending-reviews.sh <repo> <pr_number>

If your own pre-check reports pending reviewers, tell the user the comments processed below are a partial view and suggest the wait-for-pr-reviews skill, which owns in-flight-review detection and re-consolidation. Skip the pre-check when the invoker points you at a verdict file from a check earlier this session (as wait-for-pr-reviews does) — read that file instead of re-running the script, and if it shows pending reviewers, note the partial view without suggesting the skill: the invoker already owns the wait. If the script fails, note it and proceed — detection never blocks comment processing, and an unattended run treats this as proceed, never stall.

Then run the fetch script, saving its output to a file — Step 5 extracts comment bodies from it, so the raw JSON must survive on disk:

comments_file=$(mktemp)
scripts/fetch-unaddressed-comments.sh <repo> <pr_number> > "$comments_file"

This returns a JSON array of every unresolved inline review comment on the PR — from any reviewer — minus ones you've previously dismissed. Each comment has id, path, line, body, diff_hunk, author (the reviewer's login), and is_bot (true when a bot authored it — Copilot, ReviewHog, Greptile, Graphite, or any other GitHub App; false for human reviewers).

If the script fails or exits non-zero, report the error and stop — do not treat a failed fetch as "no comments."

If the array is empty, record the finished pass and stop, reporting "No unaddressed review comments to process" plus who is still mid-review if the pre-check found anyone. A PR with nothing to address is a completed run, not an abandoned one, and leaving it unrecorded makes every later go run invoke this skill again:

RAN_BRANCH="$HEAD_BRANCH" scripts/record-step.sh address-pr-reviews

RAN_BRANCH names the branch to record against. A detached checkout has none, and passing it here reuses the answer Step 1 already has instead of paying for the lookup again.

Do not record it when the fetch itself failed above; an error is not an empty comment set.

Otherwise, report how many comments were found and proceed.

Step 3: Evaluate Each Comment

For each comment in the array:

1. Read the file at the comment's path around the comment's line (include sufficient context, e.g. 20 lines before and after). If line is null or the surrounding code doesn't match diff_hunk, the comment is likely outdated (the commented code has since moved or changed) — search the file for the code referenced in diff_hunk instead of trusting the line number, and note the discrepancy in your assessment.
2. Use the diff_hunk to understand what changed
3. Evaluate whether the comment is legit or not legit

Evaluation criteria:

A comment is legit if it identifies:

• A real bug or logic error
• A security vulnerability
• A missing edge case that could cause failures
• A clarity improvement consistent with the project's conventions

A comment is not legit if it:

• Is a style preference that conflicts with the project's patterns
• Misunderstands the code's intent or context
• Suggests changes that add unnecessary complexity
• Points out something that is already handled elsewhere

A comment that shows one broken input stands for a class of inputs. This applies when the code is a guard that decides when a transformation is safe, such as copying a WHERE clause into a subquery or running one predicate against a second table. Before you propose a fix, list every input shape that reaches the same code. For a copied WHERE clause, the shapes include a fully qualified table name, an alias, a column from a joined table, and a join the query engine adds on its own. Fix them together. The fix checks the property the transformation needs, such as "every name in the copied clause resolves on the new table" or "both tables select the same rows", and refuses the case when it cannot show the property holds. A fix that adds the comment's input to a list of refused cases leaves the next shape broken.

Present your assessment for each comment with:

• The file path and line number
• A brief quote of the comment
• Your verdict: Legit or Not legit
• Your reasoning (1-2 sentences)
• Your proposed action (what you'd fix, or what you'd reply). For a guard or a transformation, include the input shapes you listed and the property the fix checks.

After evaluating all comments, present a summary table, then ask for confirmation as Asking the user describes: apply every fix, pick a subset, or stop. Unattended default: apply every fix.

Before presenting the assessments and summary table, apply the plain-writing skill in technical mode to them, reading its rules from references/plain-writing/SKILL.md. Keep every quoted comment and every verdict exactly as written. Apply the same rules to each reply you draft in Steps 4 and 5, before you post or show it.

Write every reply as the user. Never mention an AI, an agent, or this skill.

Step 4: Act on Comments

Run this step only after the Step 3 confirmation. If the user stops there, post nothing and change nothing.

For legit comments:

• When the comment reports a bug that the code can exercise, first write a test that builds the comment's input, runs it through the real code, and fails. For a guard or a transformation, run every input shape from Step 3 through the same test. Fix the code until the test passes. If the checkout cannot run tests, say so in the summary.
• Edit the file to address the issue
• Stage each changed file, including the test, with git add <file>

For not-legit comments, branch on who authored the comment:

• Bots (`is_bot` true: Copilot, ReviewHog, Greptile, Graphite, or any other GitHub App): Write a short reply that gives the reason the code is correct to a file, so it survives quotes and newlines. Step 5 substep 7 posts it without asking, with this replies command: gh api "repos/<repo>/pulls/<pr_number>/comments/<comment_id>/replies" --method POST -F body=@<reply-file>.
• Human reviewers (`is_bot` false): Never post anything. Draft the reply and hold it for the user to review and post themselves (see Step 5). Leave the thread unresolved so the reviewer gets the last word.

Step 5: Finalize