agentleFS
anchildress1anchildress1/awesome-ai/skills/pr-comment-review/SKILL.md

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

  • Other versions1 project uses a version of this.

    Word for word · 1

    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.

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
  1. Very specific:

    Prefer GitHub MCP tools when loaded (ToolSearch("select:mcp__plugin_github_github__pull_request_read")).

    line 19
  2. Distinctive:

    No open PR for the branch → say so and stop.

    line 36
  3. Very specific:

    Read every page before concluding anyone is absent.

    line 48
  4. Distinctive:

    Read the result carefully in both directions:

    line 84
  5. Distinctive:

    Before declaring any automatic reviewer broken, re-trigger it manually and time the response.

    line 92
  6. Distinctive:

    Read the finding against the current code at that location, not the quoted hunk — code moves.

    line 123
  7. Very specific:

    Check for the marker <!-- pr-comment-review:self-reviewed --> in the PR's comments/reviews first.

    line 151
  8. Very specific:

    Run the repo's verification loop (make ai-checks if present, else build + lint + test + secretlint) before committing.

    line 180

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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,headRefName

owner/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}/comments

Read 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 GET is required — -f alone makes gh POST, and search answers with a bare 404 that reads like a missing repo. {bot-slug} is the login without the [bot] suffix.

    Report a 0 as "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 same 0, 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}/installation needs a GitHub App JWT and returns 401 to gh auth credentials). 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_requested events 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 review comment and so leaves no request event.

    Before declaring any automatic reviewer broken, re-trigger it manually and time the response. Posting @codex review is 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:

  1. Read the finding against the current code at that location, not the quoted hunk — code moves.
  2. Fix or justify per §6.
  3. Fixing → implement under the code-implementation skill's loop (research, implement, verify).
  4. Reply in that thread, never a new top-level comment. commentId is the numeric id from #discussion_r<id>, not the GraphQL node id:
    add_reply_to_pull_request_comment(owner, repo, pullNumber, commentId, body)
    # gh api repos/{owner}/{repo}/pulls/{pr}/comments/{comment_id}/replies -f body="..."
    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.

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-review at 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]

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.