agentleFS
yunsiiyunsii/wezdeck/skills/adversarial-review/SKILL.md

adversarial-review

Skill4 starsChanged 48 days agoMITView on GitHub

Multi-role adversarial code review (platform skill). Agent loads this skill and runs the co-located runner (find → refute → sandbox repro); humans only state intent (审一下 / 对抗审查). Works for OpenClaw Main and host TUI agents via user-level skill links. Use when user asks for adversarial review, acceptance recommends review, or runtime code changed before merge.

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

13 rules. 0 are common, 5 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 93 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Write-task checklist: acceptance suggests review

    line 31
  2. Very specific:

    After editing this toolkit itself → dogfood

    line 33
  3. Very specific:

    Prefer different families than the writer (strategy B via --writer).

    line 51
  4. Very specific:

    Never: default to $TARGET/skills/adversarial-review unless that path actually exists (compat only).

    line 74
  5. Very specific:

    If impact_candidates_n == 0 or you choose not to filter, skip to step 5 without --project-slice-file.

    line 138
  6. Very specific:

    Don't ask the human to run run.sh as the main path

    line 209
  7. Very specific:

    Don't use ACP CODEX_HOME for review (env -u CODEX_HOME is inside provider)

    line 210
  8. Distinctive:

    Don't skip refute when claiming 对抗审查

    line 211
  9. Distinctive:

    Don't call solo Main analysis 对抗审查

    line 212
  10. Distinctive:

    Don't run this skill on pure design-doc review and claim 对抗审查

    line 213
  11. Very specific:

    Don't treat main-agent PROJECT_SLICE filter as a review gate or drop hits to hide risk

    line 214
  12. Distinctive:

    Don't assume the skill lives only under the TARGET repo

    line 215
  13. Very specific:

    Don't force-push; wezdeck personal mainline may push master after green (L0-13/19)

    line 216

“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 (platform skill — single source)

Who runs: the coding agent (OpenClaw Main / Claude-TUI / Codex-TUI), not the human.
Never tell the user to copy-paste run.sh as the primary path.
Never replace this with a solo monologue and call it 对抗审查 (that is 设计批判).

This directory is the only skill + runner unit. Other paths are symlinks (user-level or in-repo discovery). Do not maintain a second SKILL.md body.

Who runs what

ActorDuty
HumanIntent only:「对抗审查」「审一下这批改动」「按推荐审查」
Any agentLoad this skill → resolve TOOL + TARGET → run → disclose
Host headless backendsclaude / codex / grok as find/refute (not ACP by default)

When to load / run

  • User asks for 对抗审查 / adversarial review / multi-role review
  • Write-task checklist: acceptance suggests review
  • Runtime code/scripts changed (any git TARGET the agent may review)
  • After editing this toolkit itself → dogfood

Skip / redirect:

  • Pure docs/tests-only (runner auto-skips); user explicitly skips with reason
  • Design docs / RFC / ADR / 方案提案 (no runtime diff): do not force this skill. Use 设计评审 (structured checklist in host validation.md → Design proposal review) or brainstorm only when the user still wants alternative approaches. Never label a doc critique 对抗审查.

Multi-role minimum

RoleStanceRunner stage
find / reviewerguilty-until-provenstage 1
refute / refuterkill weak findingsstage 2
reproempirical in sandboxstage 3
  • Prefer different families than the writer (strategy B via --writer).
  • Same capability twice OK → label SINGLE-MODEL / degraded; do not skip refute.
  • Solo essay without opposite roles → 设计批判, not 对抗审查.

Paths: TOOL vs TARGET (critical)

Do not assume ./skills/adversarial-review exists in the repo under review.

NameMeaning
TOOL_HOMEThis skill/runner directory (where run.sh lives)
TARGETGit repo being reviewed (--repo or current git toplevel)

Resolve TOOL_HOME (first hit wins)

1. $ADV_REVIEW_HOME                          # explicit override
2. directory of this SKILL.md if run.sh is co-located
3. $WEZDECK_ROOT/skills/adversarial-review
4. $HOME/github/wezterm-config/skills/adversarial-review
5. else: fail clearly — "adversarial-review tool not installed; run link-platform-skills.sh"

Never default to $TARGET/skills/adversarial-review unless that path actually exists (compat only).

Resolve TARGET

--repo <path>  if given
else: git rev-parse --show-toplevel from cwd

Context pack v1

Find and refute receive the same pack (not bare diff):

  • META / INTENT / CHANGESET / DIFF / FILES / PROJECT_SLICE / NOTES
  • PROJECT_SLICE = downstream refs to changed symbols (blast radius); grep floor, language-aware resolvers pluggable. --no-impact to skip.
  • Main-agent filter (optional): coarse filter of grep same-name candidates before gates — not a fourth adversarial role. See procedure below.
  • --head WORKTREE includes uncommitted TARGET changes
  • --intent or --intent-file (else commit message or degraded none)
  • Budget: --max-files (10) --max-file-bytes (40960) --context-window (200)
  • Optional: --keep-pack DIR to retain pack.md + impact_candidates.json
# One-shot (no filter) — still valid default
"$TOOL_HOME/run.sh" HEAD --head WORKTREE --repo "$TARGET" \
  --writer main --intent "what this change is for" --mode strict

Agent procedure

  1. Identify TARGET cwd/repo, BASE_REF, writer
    (main | claude | codex | grok | human)
  2. Resolve TOOL_HOME (above). Confirm "$TOOL_HOME/run.sh" is executable.
  3. Optional dry probe
    "$TOOL_HOME/lib/select-backends.sh" --writer <writer> --no-probe
  4. Optional · main-agent PROJECT_SLICE filter (recommended when impact noise is high or you already know the module map; skip when candidates are few / empty):

    You (the orchestrating main agent) have project context. You may coarse-filter grep floor hits before find/refute. This is material budget, not review:

    DoDon't
    Drop obvious decoy same-name (wrong language tree, generated, lock, unrelated package)Drop because “probably unused” without a reason
    Keep anything that might be a real consumerWrite findings / severities here
    When unsure → KEEPShrink the slice to make the change look safer
    Record short notes on what you droppedReplace refute or claim you “pre-reviewed”
    PACK_DIR="$(mktemp -d "${TMPDIR:-/tmp}/adv-pack.XXXXXX")"
    "$TOOL_HOME/run.sh" <BASE_REF> --repo "$TARGET" --writer <writer> \
      --head WORKTREE --pack-only --keep-pack "$PACK_DIR" --json \
      > "$PACK_DIR/pack-only.json"
    # Read $PACK_DIR/impact_candidates.json (or .impact_candidates in pack-only.json).
    # Write keep list (array of hits, or object form):
    #   { "keep": [ ... ], "dropped": [ ... ], "filter": "main-agent",
    #     "notes": "dropped foo.go: decoy same-name in vendor" }
    # Template: $PACK_DIR/project_slice.keep.example.json

    If impact_candidates_n == 0 or you choose not to filter, skip to step 5 without --project-slice-file.

  5. Run gates
    "$TOOL_HOME/run.sh" <BASE_REF> --repo "$TARGET" --writer <writer> --mode strict \
      --project-slice-file "$PACK_DIR/project_slice.keep.json"   # if filtered
    Or one-shot without filter:
    "$TOOL_HOME/run.sh" <BASE_REF> --repo "$TARGET" --writer <writer> --mode strict
    Explicit backends only if user named them:
    "$TOOL_HOME/run.sh" <BASE_REF> --repo "$TARGET" \
      --reviewer claude --refuter codex --mode strict
    长跑解耦(host 支持后台时):三门全量 + 慢后端(codex)可能数分钟。若 host 支持后台执行(Claude Code 的 Bash run_in_background),后台跑 run.sh 且 --json > <file>,完成后读该文件再汇报,别同步阻塞会话;host 不支持后台 (如 Codex-TUI)则同步跑,先给用户一句「耗时约 N 分钟」预告。
  6. Report with mandatory disclosure (below). Include impact_filter when set. Honest fail if tool/backends fail.
  7. Do not claim cross-agent if form is single-model; do not invent green gates.

Writer → expected pair (strategy B)

writerTypical pair when available
claude / Claude-ACP/TUIcodex × grok
codex / Codex-*claude × codex (else × grok)
main / Main-Grokclaude × codex
humansame as global best

Mandatory disclosure (paste into 结果)

## 对抗审查披露
- writer: Main-Grok | Claude-ACP | Codex-ACP | human | …
- 形态/form: cross-family | partial-avoidance | single-model-multi-role | …
- form/degraded/reason: (from select-backends / run log)
- reviewer 全名 / 立场: …
- refuter 全名 / 立场: …
- impact_filter: none | main-agent (kept K / candidates C; dropped D) + notes if any
- repro: 已跑 | 跳过(理由)
- 命令或范围: run.sh <BASE> --repo <TARGET> --writer … [--project-slice-file …]
- skipped_gates: … | 无
- 关键结论(每条标 [阻塞] / [非阻塞·backlog]): …(绑 find/refute/repro)

Helper commands (agent-only)

"$TOOL_HOME/run.sh" selfcheck claude codex grok
"$TOOL_HOME/run.sh" dogfood --mode strict --fail-on-finding
"$TOOL_HOME/run.sh" <BASE> --repo "$TARGET" --writer main --dry-run --no-probe
"$TOOL_HOME/run.sh" <BASE> --repo "$TARGET" --pack-only --keep-pack /tmp/p --json
"$TOOL_HOME/run.sh" <BASE> --repo "$TARGET" --project-slice-file /tmp/p/project_slice.keep.json
PROVIDER_MOCK=1 "$TOOL_HOME/run.sh" <BASE> --repo "$TARGET"   # offline, no LLM
# reasoning effort per stage: find/refute=high, repro=low (passed to provider CLI)

Install / refresh user-level discovery (idempotent):

# from wezdeck primary
./scripts/dev/link-platform-skills.sh

Don't

  • Don't ask the human to run run.sh as the main path
  • Don't use ACP CODEX_HOME for review (env -u CODEX_HOME is inside provider)
  • Don't skip refute when claiming 对抗审查
  • Don't call solo Main analysis 对抗审查
  • Don't run this skill on pure design-doc review and claim 对抗审查
  • Don't treat main-agent PROJECT_SLICE filter as a review gate or drop hits to hide risk
  • Don't assume the skill lives only under the TARGET repo
  • Don't force-push; wezdeck personal mainline may push master after green (L0-13/19)

Related

  • Runner (this dir): run.sh, lib/, prompts/
  • Docs: docs/adversarial-review.md (wezdeck)
  • Host doctrine: agent-profiles/v1/en/validation.md
  • Link installer: scripts/dev/link-platform-skills.sh
  • OpenClaw L0-21: short always-on rule in workspace/AGENTS.md; disclosure template SoT = this file

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.