agentleFS
dydtjr1128dydtjr1128/claude-bridge/skills/adversarial-review/SKILL.md

adversarial-review

Skill1 starsChanged 34 days agoApache-2.0View on GitHub

Use when Codex should ask Claude CLI for an adversarial challenge review that pressure-tests implementation direction, design choices, assumptions, tradeoffs, and failure modes. Trigger on requests such as ask Claude for adversarial review, challenge this design, pressure-test with Claude, or get a hostile/critical Claude pass.

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

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 0 are common, 12 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 93 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use Claude CLI for a review-only challenge pass.

    line 8
  2. Distinctive:

    Do not run automatic executable validation or print-mode smoke tests.

    line 12
  3. Very specific:

    If the user explicitly requests executable validation, setup remains available as an explicit diagnostic command:

    line 14
  4. Distinctive:

    Do not execute project code or validation commands unless the user explicitly and directly requests that execution.

    line 26
  5. Distinctive:

    Read-only repository inspection commands required to obtain the requested scope are allowed, including git diff, git status, git show, git …

    line 27
  6. Distinctive:

    When the scope is current uncommitted work, include staged, unstaged, and untracked files.

    line 28
  7. Very specific:

    Do not use shell commands for any other purpose, and do not run commands that modify files, the index, refs, configuration, or other …

    line 29
  8. Distinctive:

    Do not retry, add reviewers, expand the scope, or switch to a deeper model automatically.

    line 31
  9. Distinctive:

    If the available time or evidence is insufficient, return the supported findings and state the remaining gap.

    line 32
  10. Distinctive:

    Start with the exact diff or named files in scope and inspect only directly relevant dependencies needed to support a concrete finding.

    line 33
  11. Distinctive:

    Do not perform repository-wide discovery, recursively follow references, or pursue speculative context.

    line 34
  12. Distinctive:

    Use Fable 5.1 only when the user explicitly requests Fable.

    line 46
  13. Very specific:

    Use claude-sonnet-5-5 for the default challenge review.

    line 50
  14. Very specific:

    Use claude-opus-5-5 only when the user explicitly asks for Opus or --deep.

    line 51
  15. Distinctive:

    Do not add reviewers or change models after a failure unless the user directly requests another pass.

    line 52
  16. Very specific:

    If using this skill from its installed plugin cache, resolve the helper relative to this SKILL.md as ../../scripts/claude-bridge.mjs.

    line 85
  17. Very specific:

    Use --deep or --model claude-opus-5-5 only when the user explicitly requests Opus.

    line 87
  18. Distinctive:

    Verify every claim locally before acting on it.

    line 91

“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

Claude Adversarial Review

Use Claude CLI for a review-only challenge pass. This is not a normal defect sweep; it should question whether the approach should ship.

Preflight

Do not run automatic executable validation or print-mode smoke tests. Limit local verification to static file and line inspection.

If the user explicitly requests executable validation, setup remains available as an explicit diagnostic command:

node .\scripts\claude-bridge.mjs setup

Runtime Isolation

The helper runs Claude Code with safe mode, no MCP configuration, slash commands disabled, Chrome disabled, and built-in tools limited to Read, Glob, Grep, and Bash. It uses dontAsk permission mode so unavailable actions fail instead of pausing for approval. Organization-managed policy may still apply.

Bounded Execution Policy

Do not execute project code or validation commands unless the user explicitly and directly requests that execution. This includes tests, builds, package managers, scripts, servers, applications, CI, deployment, release, and workflow automation. A review or investigation request alone is not permission to execute them. Read-only repository inspection commands required to obtain the requested scope are allowed, including git diff, git status, git show, git log, git blame, and git ls-files. When the scope is current uncommitted work, include staged, unstaged, and untracked files; enumerate them with read-only Git inspection before reviewing only those changes. Do not use shell commands for any other purpose, and do not run commands that modify files, the index, refs, configuration, or other repository state. Complete one bounded pass within the helper-selected timeout, including any explicit --timeout override. Do not retry, add reviewers, expand the scope, or switch to a deeper model automatically. If the available time or evidence is insufficient, return the supported findings and state the remaining gap. Start with the exact diff or named files in scope and inspect only directly relevant dependencies needed to support a concrete finding. Do not perform repository-wide discovery, recursively follow references, or pursue speculative context. Once a finding has enough static evidence, report it; if evidence remains insufficient, state the uncertainty and remaining gap instead of continuing to investigate.

Executable validation, Opus, --deep, retries, and fixes each require explicit user intent. Do not infer that intent from risk, difficulty, a failed review, or an adversarial review request.

Normalize shorthand only after the user explicitly selects a model:

  • sonnet or sonnet5.5 -> claude-sonnet-5-5; explicit sonnet5 or sonnet-5 -> claude-sonnet-5
  • opus or opus5.5 -> claude-opus-5-5; fable or fable5.1 -> claude-fable-5-1
  • Explicit opus5 / claude-opus-5 and fable5 / claude-fable-5 remain pinned to version 5
  • opus4.8 or opus 4.8 -> claude-opus-4-8

Use Fable 5.1 only when the user explicitly requests Fable.

Model Selection

  • Use claude-sonnet-5-5 for the default challenge review.
  • Use claude-opus-5-5 only when the user explicitly asks for Opus or --deep.
  • Do not add reviewers or change models after a failure unless the user directly requests another pass.

Adversarial Prompt

You are an adversarial software reviewer.
Scope: <same exact scope the user gave>
Do not edit files.
Do not execute project code or validation commands unless the user explicitly and directly requests that execution. This includes tests, builds, package managers, scripts, servers, applications, CI, deployment, release, and workflow automation. A review or investigation request alone is not permission to execute them.
Read-only repository inspection commands required to obtain the requested scope are allowed, including `git diff`, `git status`, `git show`, `git log`, `git blame`, and `git ls-files`.
Do not use shell commands for any other purpose, and do not run commands that modify files, the index, refs, configuration, or other repository state.
Complete one bounded pass within the helper-selected timeout, including any explicit `--timeout` override.
Do not retry, add reviewers, expand the scope, or switch to a deeper model automatically.
If the available time or evidence is insufficient, return the supported findings and state the remaining gap.
Start with the exact diff or named files in scope and inspect only directly relevant dependencies needed to support a concrete finding.
Do not perform repository-wide discovery, recursively follow references, or pursue speculative context.
Once a finding has enough static evidence, report it; if evidence remains insufficient, state the uncertainty and remaining gap instead of continuing to investigate.
Limit verification to static file and line inspection.

Try to find the strongest reasons this should not ship yet.
Prioritize data loss, corruption, migrations, schema drift, concurrency, rollback, idempotency, trust boundaries, stale state, and missing tests.
Report only material findings grounded in files, line numbers, or command output.
Return in Korean unless the user requested another language.
Start with Findings ordered by severity. If no actionable finding, say so clearly.
Then give a short structural verdict: solid parts, fragile parts, and top 3 improvements.

Preferred Helper

node .\scripts\claude-bridge.mjs adversarial-review --scope "all current uncommitted changes, including staged, unstaged, and untracked files"

If using this skill from its installed plugin cache, resolve the helper relative to this SKILL.md as ../../scripts/claude-bridge.mjs.

Use --deep or --model claude-opus-5-5 only when the user explicitly requests Opus. The default timeout is 15m0s, 45m0s for model names containing opus, or 60m0s for model names containing fable; an explicit --timeout <duration> overrides it.

The helper stores prompt, JSON, markdown, and logs under .codex/claude-bridge/.

Verify every claim locally before acting on it. Preserve inference and uncertainty labels. Do not let Claude edit files during this review. After presenting findings, stop and ask the user which issues, if any, they want fixed before touching files.

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.