Menu
Adversarial pull-request review. Use when the user says "review this PR", "code review", "review the diff", "look at PR
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Multi-pass adversarial critique primitive. Use when another skill or the user invokes /blunder-hunt or asks for a "5x critique", "find what's wrong", or "blunder hunt". Composed by skills like pr-review, polish, and unstuck to surface bugs that single-pass review misses.
Fan out N independent tasks to parallel subagents, collect their results, optionally synthesize. Use when another skill needs work that decomposes into independent pieces — review passes with different lenses, multi-file searches, multi-source data gathering. Composed by skills like blunder-hunt, pr-review, polish, journal.
Prompt primitive that forces exhaustive enumeration. Use when another skill needs to push the agent past surface-level findings — assert a minimum count of issues exist so the agent keeps searching instead of stopping at the first 2-3. Composed by skills like blunder-hunt, pr-review, and polish.
Fan out the same task to multiple models, compare their responses, synthesize a "best of all worlds" answer. Use when one model's output is a good first draft but you want to surface blind spots and combine strengths — planning, design proposals, code reviews, retrospectives. Composes dispatch-parallel.
| name | pr-review |
| description | Adversarial pull-request review. Use when the user says "review this PR", "code review", "review the diff", "look at PR |
Adversarial review. The author already saw the obvious. Your job is to find what they missed.
This skill composes blunder-hunt and lie-to-them from the core registry. Both are listed in deps.skills and should already be installed alongside this skill.
You did not write this PR. You are not its advocate. You are looking for bugs, security gaps, integration breakage, and untested edge cases. A polite review that says "looks good!" is worse than no review — it grants false confidence. A blunt review that names real problems is the value.
If you can't find anything wrong after honest effort, that's a legitimate verdict. Empty approvals only after exhaustive search.
Use the first available source:
gh pr view <n> or gh pr view <url>gh pr viewCapture: number, title, description, base/head SHA, author, list of changed files.
Don't shortcut. Each pass uses different attention.
Pass A — read the diff: gh pr diff <n>. Notice every change.
Pass B — read the changed files in full: git show <head>:<path> for each non-trivial changed file. The diff hides invariants and the surrounding code paths.
Pass C — wander outside the diff: identify 3-5 files NOT in the diff that the change likely affects (callers, callees, shared types, tests, config). Read them. The bug is often where the new code touches old code.
Before the lens passes, compute two things from the diff:
Apply the blunder-hunt primitive with N=5 lenses:
| Pass | Lens | Looking for |
|---|---|---|
| 1 | Data correctness | wrong values, off-by-one, type confusion, null deref |
| 2 | Error handling | swallowed errors, missing fallbacks, silent failures |
| 3 | Integration | broken contracts, signature changes, downstream callers |
| 4 | Invariants | violated assumptions, race conditions, ordering bugs |
| 5 | Hostile input | injection, traversal, untrusted data flowing into trust boundaries |
For each pass, force exhaustive enumeration with lie-to-them:
"There are at least issues of type in this PR. You have found . Find the rest."
Where N is calibrated to PR size (see lie-to-them SKILL.md). Don't fabricate to fill a quota; the lie is in the prompt, not the verdict.
For a high-stakes diff — security-relevant code, public-API change, large refactor, anything tagged priority:high on the PR — compose multi-model-synth:
For routine diffs, single-model review is fine. Don't burn tokens on one-line fixes.
For each finding:
| Field | Notes |
|---|---|
| File | exact path from the diff |
| Line | line number in the head SHA |
| Severity | critical (must fix), issue (should fix), question (request clarification) |
| Description | what's wrong |
| Suggested fix | how to fix it (concrete code or steps) |
| Confidence | high (you can prove it), medium (you suspect it) |
Drop low-confidence minor items (style nits) unless the user explicitly asked for nits.
| Verdict | When |
|---|---|
request changes | one or more critical or high-confidence issue |
comment | only medium-confidence questions |
approve | exhaustive search produced zero findings AND the change does what it claims |
Use gh api to post each finding as an inline comment at the exact file:line. Mark each comment with <!-- kaijutsu:pr-review --> so re-runs can detect and update prior bot comments instead of duplicating.
gh api repos/<owner>/<repo>/pulls/<n>/comments \
-f body="<comment>" \
-f commit_id="<head-sha>" \
-f path="<file>" \
-F line=<line> \
-f side=RIGHT
For idempotency: list existing comments with gh api repos/<owner>/<repo>/pulls/<n>/comments, find ones whose body contains the kaijutsu marker AND match the same file:line, and PATCH them in place via gh api -X PATCH .... Only post new comments when no match exists.
Compose a top-level review body listing the high-severity findings + the synthesized verdict. Submit:
gh pr review <n> \
--<verdict> \
--body-file <tmpfile>
Where <verdict> is request-changes, comment, or approve.
## Review of #<n>: <title>
Reviewer ran 5x blunder hunt with lenses: data correctness, error
handling, integration, invariants, hostile input.
**Verdict:** <approve | comment | request changes>
**Findings posted as inline comments:** <count>
**Findings dropped as low-confidence:** <count>
Top issues:
- `path/to/file.go:42` — <one-line summary>
- `path/to/other.ts:118` — <one-line summary>
<!-- kaijutsu:pr-review -->. This is the idempotency key.