# Adversarial Review

> Use when reviewing a PR, patch, or design. Attack the change as a skeptic: enumerate failure modes, missing tests, unsafe defaults, and privilege edges before approving or merging.

- Skill: `magia187/adversarial-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add magia187/adversarial-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/magia187/adversarial-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: magia187 (https://skillmd.com/u/magia187)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/magia187/adversarial-review

---


# Adversarial Review

## When to use

- Reviewing a pull request, patch diff, or proposed design.
- The user asks for a "critical review", "threat model pass", or "what could go wrong".
- Before merging high-risk changes (auth, payments, data deletion, public APIs).

## When not to use

- Rubber-stamping typo/docs-only PRs where risk is negligible.
- Pairing sessions where the goal is collaborative drafting, not gatekeeping (switch to review mode when ready).
- Replacing formal security audit/penetration test engagements.

## Assumptions

- Access to the full diff, linked issue, and ability to run or reason about tests.
- Product/security context may be incomplete — call out assumptions explicitly.
- Do **not** merge, push to protected branches, or dismiss required reviews without authorization.
- Do **not** exfiltrate secrets found in the diff; follow secrets-hygiene instead.

## Workflow

1. Restate the change's purpose and trust boundaries in your own words.
2. Hunt for failure modes: nulls, races, authz gaps, injection, unsafe defaults, partial failure.
3. Check tests for gaps relative to those failure modes.
4. File concrete, severity-tagged findings (blocker / should-fix / nit).
5. Approve only when blockers are addressed or explicitly accepted by the owner.

## Steps

1. **Intent check** — Does the diff match the claimed purpose? Flag unrelated churn.
2. **Abuse cases** — For each new input/surface: unauthenticated access, confused deputy, oversized payloads, replay, TOCTOU, and error-path leaks.
3. **Defaults & footguns** — Fail-open vs fail-closed; permissive CORS; debug flags; default passwords; broad IAM.
4. **Data & teardown** — Migrations, deletes, and retries: idempotency, backup/rollback, PII exposure in logs.
5. **Test gaps** — Map each serious risk to a missing test; demand or add coverage for blockers.
6. **Report** — Structured findings with file/line references and a clear merge recommendation.

## Success criteria

- [ ] Review names specific failure modes, not only style nits.
- [ ] Missing tests for high-severity risks are called out.
- [ ] Unsafe defaults and authz edges are explicitly assessed.
- [ ] Findings are prioritized (blocker vs non-blocking).
- [ ] No unauthorized merge or secret leakage occurred during review.

## Out of scope

- Full formal threat modeling workshops for an entire product.
- Legal/compliance sign-off.
- Rewriting the feature for the author unless asked.