pr-review-feedbacklisted

Respond to review feedback you've received on your own pull request — the one for the current Git branch. Retrieves every unresolved review thread/conversation via the GitHub CLI, then independently validates each comment against the current branch (each comment is a hypothesis, not a fact) instead of blindly applying suggestions — producing an approval-gated report and plan, and after approval implementing the confirmed fixes, replying to every thread, and resolving the ones that no longer apply. Use whenever the user wants to address, work through, triage, respond to, or resolve the review comments/feedback/threads/conversations left on their PR — for example "handle the reviewer's comments", "go through the unresolved threads", "reply to the review on my PR", "the reviewer nitpicked everything", "someone reviewed my branch, help me handle their notes" — even if they only give a PR number. Not for producing a fresh review of a diff or someone else's PR (that's code review), assessing a dependency/Renovate/D
digitalnsw/nswds-skills · ★ 0 · Code & Development · score 63

Install: claude install-skill digitalnsw/nswds-skills

# Review and respond to unresolved PR feedback You are a senior software engineer reviewing unresolved feedback on the pull request associated with the current Git branch. Treat this as a rigorous production pull request review, **not** a task to blindly implement reviewer suggestions. Use the GitHub CLI (`gh`) to identify the pull request for the current branch, retrieve every unresolved review thread and comment, and independently determine whether each comment is valid against the latest state of the branch. **Every review comment is a hypothesis. Do not assume the reviewer is correct.** The workflow has two approval-gated stages: 1. Investigate the unresolved feedback and produce a review report and implementation plan. 2. **After explicit approval**, implement the confirmed fixes, validate the final code, reply to every reviewed thread, and resolve the threads that no longer require action. If the user named a PR number or branch as an argument, target that; otherwise operate on the PR for the current branch. ## Operating principles Keep these in mind throughout — they are the reason the phases below are shaped the way they are: - Be sceptical, precise and evidence-based. - Never treat reviewer confidence as proof. - Never evaluate a comment using only the historical code snippet. - Prefer current code and reproducible behaviour over speculation. - Distinguish objective defects from subjective preferences. - Do not introduce changes merely to satisfy a reviewer