agentleFS
dagarre00dagarre00/claude-code-template/.claude/skills/adversarial-review/SKILL.md

adversarial-review

Skill1 starsChanged 29 days agoMITView on GitHub

Subagent-side, preloaded into the adversary. How the read-only adversary reviews a diff — category sweep, severity vocabulary, reporting floor, and report format; the conductor's side is finding-disposition.

104 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use rethink, root-cause-analysis and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • fabioespindulaSkill

    rethink

    Reframe a plan, idea, or decision before the user commits to it. Use when the user asks to rethink, step back, pressure-test, gut-check, decide, right-size, simplify, think bigger about, or evaluate a concrete plan or decision in product, strategy, technical architecture, career, life, company direction, or personal priorities. This skill improves decision quality before action: clarify the real question, challenge assumptions, compare alternatives, calibrate ambition, classify the operating mode, surface risks, and recommend a next move. Do not use for broad future exploration without a concrete decision; that belongs to a think-big or research-style skill.

    Also in 3 projects that use this

  • MicrosoftSkill

    root-cause-analysis

    Use when a Regional Retail Manager asks I'm seeing unusual inventory movement at our Northwest stores. Can you help me understand what's happening?

    Also in 3 projects that use this

  • anasahmed07Skill

    better-auth-best-practices

    Skill for integrating Better Auth - the comprehensive TypeScript authentication framework.

    Also in 4 projects that use this

  • DockerSkill

    fix-issue

    Fix a single GitHub issue end-to-end: triage, research, write the fix, review, and create a PR. Use when asked to fix an issue: "fix issue 1234", "resolve #500", "create a PR for issue 200".

    Also in 3 projects that use this

  • MicrosoftSkill

    pull-request

    Write concise, focused pull request descriptions for Wassette — at most three sentences on the what and why, with an explicit note on any breaking public-API change and how users adapt. Use when opening or editing a Wassette pull request.

    Also in 3 projects that use this

  • juriwiensSkill

    codex-review

    Run code review via Codex CLI

    Also in 3 projects that use this

  • +2 more from microsoft

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 93 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Verify before asserting (read the test.

    line 26

“Common” is measured: kept by at least 6 in 10 of the 93 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Adversarial Review — the sweep

Review the commit range named in your brief against the wiki. Raise findings; never fix them.

The category sweep

Sweep all 8 categories in order at full depth:

#CategoryLook for
1correctnessWrong branch, off-by-one, silent None/nil, swallowed exception, error path returning success, Behavior case not actually implemented
2concurrencyShared mutable state, non-atomic read-modify-write, check-then-act, unawaited work, lock ordering, assumed single-threading
3durabilityPartial write with no rollback, lost update, unbounded retry, non-idempotent handler, migration with no down path, unvalidated write
4securityUnvalidated input crossing a trust boundary, injection (SQL/shell/template), secret in code or log, missing authz, unsafe deserialization
5architectureImport the architecture.md § Layers table forbids; business rules in controller/handler/repository; concrete dependency built outside composition root; change to architecture rules or check
6test-integrityTest asserting nothing, tautology, mock hiding the real boundary, test passing without the implementation, [x] case lacking a test
7complexityCode not forced by the cases: dead code, single-implementation abstraction (except required ports), hand-rolled stdlib/platform feature, replaceable dependency, duplicate helper, shortcut: without revisit trigger. Prefix claim with delete:, stdlib:, native:, yagni:, or shrink: and name the replacement
8otherStale wiki claim in the diff, misleading name, comment contradicting code

Verify before asserting (read the test; grep for callers). Unverified findings are confidence: low or dropped. Score against the spec and declared layers, never personal taste.

Severity (closed) and the reporting floor

SeverityMeaningWrite-up
criticalData corruption, secret exposure, or wrong result on a normal pathFull, with concrete failure scenario
majorWrong result on an edge path; test not testing its Behavior; layer violationFull, with concrete failure scenario
minorReal but contained — poor error message, narrow missing validationOne line: claim and path:line
nitStyle, naming, commentNot itemised — one tally line
  • The floor governs write-up, never depth of sweep.
  • Unsure between critical and major → major (explain why it might be higher). Unsure if nit → minor.
  • complexity findings are minor at most (unless they also cause a wrong result, which is correctness).

Report format

# Findings — <slug>

**Commit:** <sha from git rev-parse HEAD>
**Scope:** <commit range reviewed>
**Checked:** <one line per category swept, so a clean pass is reviewable>

## F1 — critical — correctness — <one-line claim>

**Where:** `path/to/file.py:42`
**What's wrong:** <2–3 sentences, mechanism not vibes>
**Failure scenario:** <concrete inputs/state/interleaving → wrong output or crash>
**Confidence:** high | medium | low

## F2 — minor — security — <claim> — `path:line`

Nits: 3 (naming ×2, stale comment ×1)

## Out of scope

- <pre-existing problems outside the diff>

Nothing above nit → state that explicitly with the Checked: lines. Name any implied gotcha or ADR inside the finding.

Re-review round: Given only the fix commit range and prior findings + dispositions, confirm each fix, accept or contest each rejection once, and stop — do not re-scan the original diff or open new lines of attack from round one.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.