--- name: miguelaperez/pr-review-respond source: https://app.decimal.ai/s/miguelaperez-pr-review-respond@1/SKILL.md source_sha256: 77a1754ebc0e --- # Respond to a PR Review This captures the repeatable loop for turning reviewer feedback (often from a review bot, sometimes a human) into a decision, a set of fixes, and a reply — without blindly "fixing" everything a reviewer flags. Many review comments are wrong for *this particular* repo, and acting on them would make the code worse. The skill's point is to **separate signal from noise, get the user's sign-off, then close the loop on the PR.** The guiding principle: **the user decides what's valid.** You do the legwork — gather the comments, form a reasoned recommendation on each — but you stop and wait before changing code, and you never post a reply until the fixes are in. Before starting, identify the project's remote platform from the git remote URL and confirm you have the right tooling available. Check the platform-specific docs for the exact API calls — e.g. see `working-with-gitea` if the remote is Gitea. ## Workflow ### 1. Fetch the feedback PR review feedback typically lives in three places — pull all of them, because the real substance often lives in per-line comments even when a review's summary body is empty: 1. Top-level discussion comments on the PR 2. The reviews themselves and their summary bodies 3. Per-line (inline) comments for each review Consolidate these into one readable list, keyed by **comment id** (you'll reference these ids when triaging and resolving). Use a table like this: | ID | Source | File | Line | Status | Body | |----|--------|------|------|--------|------| | 42 | inline | `src/foo.ts` | 12 | open | "Consider using X instead of Y" | | 43 | review summary | — | — | open | "Missing error handling throughout" | | 44 | discussion | — | — | open | "Is this change intentional?" | If the user didn't give a PR number, infer it from the current branch or ask. ### 2. Evaluate each comment Go through the comments one at a time and classify each as **valid** (worth fixing) or **not valid** (decline), with a one-line reason grounded in evidence — not vibes. Read the code each comment points at before judging. The reasoning that matters most is **fit with this repo**, because a review bot doesn't know the project's constraints. Before accepting any "you should do X": - **Check the project's scope and platform.** Read the repo's `CLAUDE.md` / README for declared constraints. Comments about platforms, runtimes, or environments the project doesn't target are usually **invalid** — fixing them adds dead code. *(Worked example: an iOS-only app has no macOS build, so review comments about macOS/visionOS/AppKit/`NSPasteboard`, or "wrap `import UIKit` in `#if canImport(UIKit)`", are invalid — there's no build where they matter.)* - **Check existing convention.** If the surrounding codebase already does the opposite of what the comment asks, *on purpose*, the new code matching that pattern is correct, not a defect. Cite the precedent. *(Example: if existing files import `UIKit` unconditionally and clipboard helpers are `#if os(iOS)`-only, a new file following that pattern is right — not a defect.)* - **Take genuine bugs / robustness wins.** Correctness issues that hold regardless of scope are **valid** even when minor (e.g. not stripping `\r` from a CRLF string before rendering). Cheap, real fixes are worth it. - **Answer "confirm this is intentional" questions** — they need a reply, not a code change. If the change was the explicit goal of the PR, say so plainly. Present the verdict grouped by bucket — e.g. **Not valid / won't fix**, **Valid / worth fixing**, **Confirmed intentional** — each item with its reason, a `file:line` link, and the **`comment #`** from the fetched comments. End with a clear recommendation of what to actually do. ### 3. Stop and wait for confirmation **Do not edit code yet.** The user reviews your evaluation and says which items to act on. They may overrule you in either direction — respect that. ### 4. Implement the agreed fixes Make the changes, then **build/test to confirm** using whatever gate the repo uses (check `CLAUDE.md` for the build command). Commit and push to the existing PR branch. Match the repo's commit-message convention, including any required trailer. ### 5. Post the summary back to the PR Post a comment on the PR using the platform's API. Structure it so a reader sees the decisions at a glance (drop empty sections): ```markdown ## Review follow-up ### Fixed - **** — . (commit ``) ### Won't fix (not applicable to this project) - **** — . ### Confirmed intentional - **** — yes, intentional: . ``` Keep it factual and brief — acknowledge the review, state what moved, give the reasoning for what didn't, and note the build/tests passed after the fix. ### 6. Resolve only the fixed threads After the follow-up comment is posted, mark **only** the review threads that landed in the **Fixed** bucket (and that the user confirmed) as resolved. Do **not** resolve every open thread on the PR — especially not items classified as **Won't fix** or **Confirmed intentional**. Those should stay open so the decision stays visible on the diff. List the exact comment IDs from the **Fixed** bucket in your triage before resolving, and confirm them with the user. Use the platform's API to resolve each thread — check the platform-specific docs for the exact call and any quirks. ## Why this shape Reviewers (especially bots) optimize for catching *possible* issues, not for knowing your project. Treating every comment as a mandate produces churn and dead code; ignoring them loses the real bugs they do catch. The valuable work is the judgment in step 2 — which is exactly why step 3 hands that judgment to the user before anything ships.