Run the mandatory skeptic review over a staged diff and record it in the PR body. Use before `gh pr create` on any change touching Go code in core-agent. Covers what to delegate, what the reviewer needs to be told, how to disposition findings, and the `## Adversarial review` section the required CI check looks for.
Installs into .claude/skills of the current project.
Are you the author of Adversarial Review Gate?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/go-steer-adversarial-review-gate)
---
name: adversarial-review-gate
description: Run the mandatory skeptic review over a staged diff and record it in the PR body. Use before `gh pr create` on any change touching Go code in core-agent. Covers what to delegate, what the reviewer needs to be told, how to disposition findings, and the `## Adversarial review` section the required CI check looks for.
---
# Adversarial review gate
Before `gh pr create` on any change touching Go code: a skeptic reviews the
staged diff, every finding is fixed or pinned, and the outcome is recorded in
the PR body under an `## Adversarial review` heading.
This is not advisory. The `review-gate` CI check is **required** and a
Go-touching PR fails without the section. (Docs-only PRs and PRs authored by
`go-steer-bot[bot]` are exempt.)
## Run it
Stage first — the reviewer reads `git diff --cached`, so anything unstaged is
invisible to it and will reach the PR unreviewed.
```bash
git add <the files>
git status --short # confirm nothing you meant to include is still ` M`
```
Stage by name, never with `git add -A` or `git add .`. The tree can hold
things that are not yours to commit: a scratch file, a reviewer's leftover,
or an untracked file that belongs to the developer whose checkout this is.
Then delegate to the `reviewer` subagent. **Tell it three things**, because a
reviewer that has to infer intent grades style instead of correctness:
1. the issue number and what the change is meant to do,
2. the specific things you are least sure about — the race you talked
yourself out of, the guard you are not certain actually guards,
3. that it should verify against real dependency source rather than memory,
and mark each finding CONFIRMED or PLAUSIBLE.
Ask it explicitly not to manufacture findings. A clean verdict with a list of
what was checked is a real result.
## Disposition every finding
Every one gets fixed or pinned — pinned meaning you argue in writing why it
is not a defect, or why it is a known limit you are accepting. Silently
dropping a finding is the failure mode this gate exists to prevent.
Do not take the reviewer at face value. It is another model and it is
sometimes wrong, sometimes confidently. Check the claim before you act on
it; if it is wrong, say so in the disposition rather than changing code to
satisfy it.
Findings about **comments and docs the diff makes false** are real findings,
including in files the diff does not touch. Fix those.
If the reviewer comes back without a report, because a budget cap stopped
it or you stopped it, the gate has not run yet. Delegate again with a
narrower brief: the files you are least sure of, and the one or two
questions that matter. A cap returns whatever the reviewer had written by
then, which is a starting point, not a verdict. A stop returns nothing at
all. Each run can spend up to its budget, so a narrower brief is also the
cheaper one.
## Record it
A table is the readable form: finding, and what you did about it.
Say who found what. When a finding came from your own checks rather than
the reviewer, say so in its row, and if a reviewer run returned nothing,
say that too. A section that credits the reviewer with findings it never
returned tells the next reader the gate caught them, and so hides the
fact that it did not.
```markdown
## Adversarial review
Skeptic subagent over the staged diff. **No correctness defects** — `go
build`, `go vet`, the package suite and `-race` all clean. N findings, all
addressed:
| # | Finding | Disposition |
|---|---------|-------------|
| 1 | … | **Fixed.** … |
| 2 | … | **Pinned as a known limit** — … |
```
Then, if the change was a bug fix, the pre-fix failure evidence (see
`prefix-failure-verification`), and if it added a guard, the mutation
evidence. Both belong in the same PR body.
Close with what the review explicitly cleared. The things most worth doubting
— the race, the nil path, the vacuous-test question — are worth a sentence
each even when the answer was "fine", because that is the part a future
reader cannot reconstruct.
## Evidence it pays
The #537–#567 shutdown/resume train shipped seven substantive PRs and this
gate caught a P0/P1-class defect in nearly every first draft. On #1137 it
caught an allowlist entry scoped package-wide when it was documented as
applying to one file — a hole wide enough to drive the original bug back
through.