pr-comment-review
Skill67 starsChanged 2 months agoMITView on GitHub
Audit and remediate an open GitHub PR's review feedback: verify Copilot and Codex actually reviewed, drive every unresolved thread to a fix-or-justify reply, correct PR title/description drift against the real diff, and run a one-time self-review pass. Trigger on "have all PR comments been addressed", "did copilot and codex review this", "reply to the PR comments", "address the PR feedback", "is this PR ready to merge", "clean up this PR before merging", "make sure nothing got missed on this PR" — and on generic "review comments" mentions, on single-bot mentions, and when prepping a new PR for review before comments exist. Not a fresh review of an unpushed working diff; that's `/code-review`.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- anchildress1/awesome-github-copilotword for word, first seen Sep 16, 2026
Other versions1 project uses a version of this.
Word for word · 1
- anchildress1/awesome-github-copilot★ 67100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- changelog-writerSkill
- eslint-plugin-configuringSkill
- generate-commit-messageSkill
- readme-generatorSkill
- test-writerSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Prefer GitHub MCP tools when loaded (ToolSearch("select:mcp__plugin_github_github__pull_request_read")).
- Distinctive: line 36
No open PR for the branch → say so and stop.
- Very specific: line 48
Read every page before concluding anyone is absent.
- Distinctive: line 84
Read the result carefully in both directions:
- Distinctive: line 92
Before declaring any automatic reviewer broken, re-trigger it manually and time the response.
- Distinctive: line 123
Read the finding against the current code at that location, not the quoted hunk — code moves.
- Very specific: line 151
Check for the marker <!-- pr-comment-review:self-reviewed --> in the PR's comments/reviews first.
- Very specific: line 180
Run the repo's verification loop (make ai-checks if present, else build + lint + test + secretlint) before committing.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Prefer GitHub MCP tools when loaded
(ToolSearch("select:mcp__plugin_github_github__pull_request_read")); gh api equivalents are
given inline.
1. Resolve the PR
Given a number/URL, use it. Otherwise:
gh pr view --json number,title,body,url,isDraft,baseRefName,headRefNameowner/repo come from whichever identified the PR. A supplied URL carries its own
owner/repo — parse them from it, because the PR may live in a repo the current checkout isn't
(same number, different repo, and every read and reply would land on a stranger's PR). Fall back
to git remote -v (origin) only for a bare number or the current-branch case.
No open PR for the branch → say so and stop. Don't guess.
2. Confirm both required bots reviewed
- Copilot:
copilot-pull-request-reviewer[bot] - Codex:
chatgpt-codex-connector[bot]
pull_request_read(method="get_reviews" | "get_comments", owner, repo, pullNumber)
# gh api --paginate repos/{owner}/{repo}/pulls/{pr}/reviews | .../issues/{pr}/commentsRead every page before concluding anyone is absent. gh api returns one page by default, so a
bot that reviewed after 30 other events looks missing without --paginate; the MCP tool pages
via perPage + the after cursor from pageInfo.
A missing bot is a diagnosis, not a shrug. Diagnose per bot — they have independent configurations, so one explanation rarely covers both:
- Draft PR — check
isDraft. This only explains Copilot if the repo has not enabled Review draft pull requests in its ruleset; with that on, a draft is no explanation at all and you need a different cause. - Pending — last push minutes ago; report the timestamp instead of "absent".
No prior review history — check whether the bot has ever commented on any PR here:
gh api -X GET search/issues -f q="repo:{owner}/{repo} commenter:app/{bot-slug}" --jq '.total_count'-X GETis required —-falone makesghPOST, and search answers with a bare404that reads like a missing repo.{bot-slug}is the login without the[bot]suffix.Report a
0as "no prior comments in this repo" — never as "not installed". A freshly installed app, or one enabled before its first eligible PR, returns exactly the same0, and calling that an installation problem sends the user to fix something that isn't broken.There is no user-token API that answers "is this app installed" (
repos/{owner}/{repo}/installationneeds a GitHub App JWT and returns401togh authcredentials). A recent review on any PR here is the practical proof — a bot that answered yesterday is installed today.You can also check whether this bot was requested, but filter by who was requested — a bare count of
review_requestedevents counts requests aimed at humans and at the other bot:gh api --paginate repos/{owner}/{repo}/issues/{pr}/timeline \ --jq '[.[] | select(.event=="review_requested") | .requested_reviewer.login // .requested_team.name] 'Read the result carefully in both directions:
- Requested and silent, while it answered other PRs in minutes → installed and not delivering. A bot-side failure, worth saying plainly.
- Never requested proves nothing on its own. Bots that review automatically never appear
here at all — Copilot shows up because a ruleset requests it, while Codex triggers on PR
open / ready-for-review / an
@codex reviewcomment and so leaves no request event.
Before declaring any automatic reviewer broken, re-trigger it manually and time the response. Posting
@codex reviewis the supported path, and a bot that answers a manual trigger in minutes after missing the automatic one has a trigger problem, not an install problem — a much more useful thing to tell the user. Send them to Settings → GitHub Apps only when nothing else explains it.- Other — state the evidence. Never "reason unclear"; if inconclusive, say what you checked and what came back, so the user doesn't re-derive it.
3. Drive every unresolved thread to a conclusion
pull_request_read(method="get_review_comments", owner, repo, pullNumber)Returns review_threads[], each with is_resolved / is_outdated / is_collapsed and its
comments — snake_case in the payload, even though the tool description spells them camelCase.
Page with perPage + after until pageInfo.hasNextPage is false; an unresolved thread on page
two counts exactly as much as one on page one.
The gh api fallback can't do this: REST /pulls/{pr}/comments returns flat comment records with
no thread resolution state. If you're on the fallback path, get it from GraphQL:
gh api graphql -f query='query($o:String!,$r:String!,$n:Int!){repository(owner:$o,name:$r){
pullRequest(number:$n){reviewThreads(first:100){nodes{id isResolved isOutdated
comments(first:100){nodes{databaseId author{login} path line body}}}}}}}' \
-f o={owner} -f r={repo} -F n={pr}Covers all sources — both bots, humans, SonarQube, Dependabot. For each unresolved thread:
- Read the finding against the current code at that location, not the quoted hunk — code moves.
- Fix or justify per §6.
- Fixing → implement under the
code-implementationskill's loop (research, implement, verify). - Reply in that thread, never a new top-level comment.
commentIdis the numeric id from#discussion_r<id>, not the GraphQL node id:
State what changed (with commit ref once pushed) or exactly why nothing did. Leave threads unresolved unless the user says otherwise — resolution is a human checkpoint.add_reply_to_pull_request_comment(owner, repo, pullNumber, commentId, body) # gh api repos/{owner}/{repo}/pulls/{pr}/comments/{comment_id}/replies -f body="..."
4. Check the PR's story against its diff
pull_request_read(method="get_diff" | "get_files", owner, repo, pullNumber)Drift runs both ways: undersold (diff does things the body never mentions — drive-by fix, dep bump, config change), oversold (body claims what the diff doesn't do, or describes a superseded approach), title scope mismatch (title vs. what the diff actually touches).
Fix via update_pull_request / gh pr edit. Metadata correction — GitHub's edit history is the
trail, so no comment needed.
5. Self-review — once per PR, not per invocation
Check for the marker <!-- pr-comment-review:self-reviewed --> in the PR's comments/reviews
first. Present → skip to §6 and say so ("self-review already done in <link>; say 'redo the
self-review' to force a fresh pass"). Run a fresh pass only if absent or explicitly requested.
Delegate the pass, scaled to risk:
- Default:
/code-reviewat default effort — single pass, proportionate. high+ only when warranted: auth/security-sensitive code, unusually large diff, or the user asked for depth. Multi-agent review costs real time and tokens.
Findings follow §6. With no existing thread to reply to, post a fresh review comment at the relevant line — the one case where a new comment is correct — so the reasoning is in-context, not just in your report. Leave the marker comment in place afterward.
6. No deferrals
Every finding — either bot, human, or §5 — gets a fix or a specific, substantive reason it won't be fixed. Neither is skippable.
"Minor", "nitpick", "irrelevant", "follow-up" are not reasons; they're what gets written when no decision was made. A real reason is independently verifiable by another engineer: touches an unrelated module, needs a design decision only the user can make, depends on unlanded work, would break an API this PR doesn't own.
A finding that needs a genuine tradeoff decision → stop and ask. Never invent a justification to keep moving.
7. Verify, commit, report
Run the repo's verification loop (make ai-checks if present, else build + lint + test +
secretlint) before committing. Atomic commits, one logical fix each, matching recent git log
conventions.
Do not push unless this turn's invocation authorizes it. Default is commit and report "ready to push".
## Reviewer presence
- Copilot: [present | absent — reason]
- Codex: [present | absent — reason]
- Other reviewers: [list | none]
## Threads addressed (N)
- [topic]: fixed in <commit> — reply posted
- [topic]: not fixed — <specific reason> — reply posted
## Title/description
- [accurate | corrected: <what changed>]
## Self-review
- [finding]: fixed in <commit> — comment posted
- [finding]: not fixed — <specific reason> — comment posted
(or "skipped — already done in <link>" | "none found")
## Needs your input
- [findings blocked on a human decision]
## Status
- N commits, [pushed | not pushed — say "push" to publish]Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

