| 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.
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 orVerdict: 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:lineorfile: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?"