Claude Code skill to more effectively review PRs

A developer published a Claude Code skill that reviews a GitHub pull request by number and returns an approve or reject verdict. The skill runs a code-review pass, rejects only for real defects such as bugs, data loss, security issues, broken callers or missing required tests, and then spawns parallel finding-verifier agents to check each blocking finding before the verdict is finalized. Findings judged false, nit-level or out of scope are dropped and reported separately, and every finding is cited with file and line numbers.

| name | review | |---|---| | description | Review a GitHub PR by number and give an approve or reject verdict. Every finding that would cause a reject is verified first; if a finding is false, the verdict is decided again. Use when the user types /review <PR number . | | argument-hint | <PR number | Review PR $ARGUMENTS and tell the user to approve or reject it. 1. Run the code-review skill on PR $ARGUMENTS pass the PR number as the target, plus any extra flags the user gave . 2. From its findings, decide approve or reject. Reject only for findings that are real defects in this PR bugs, data loss, security, broken callers, missing required tests . Nits, style and follow-up ideas do not cause a reject. 3. If the verdict is reject: for each finding that causes the reject, launch one finding-verifier agent all in parallel, in one message . Give each one the finding, its file and line, and the PR's base and head refs. Do not tell it what verdict you expect. 4. Drop every finding the verifiers judge false, a nit, or out of scope for this PR. Decide approve or reject again from only the findings that were confirmed. 5. Reply in this order: - Verdict: approve or Verdict: reject , with one sentence on why. - If reject: the confirmed blocking findings, and the verifier's result for each. - Findings that were checked and found false, so the user sees what was dropped. - Minor findings, a short numbered list. - One line on what was not checked for example, tests not run locally . Write every finding, in every section, in this shape: - file:line or file:start-end . The line numbers are required. - One short sentence or question in plain, everyday words, as if said to a coworker who is not an engineer. Say what could go wrong, not how the code works. For example: "These tests pass even if the code is broken. Should they call get views ?"