360 Secure SkillHub
360 安全技能中心

Adversarial Review

对重要文档运行结构化对抗评审循环:先做复杂度自评决定是否推荐,再并行启动带不同批评视角的评审员,收集结构化 redline 并合并排序,逐条给出同意/不同意/修改立场,最后产出含修订表和拒绝附录的 v2 文档并复制到指定位置。依赖宿主会话目录与并行子智能体调用。

scott3j
scott3j
热度 58.19
最近更新 2026-05-18 12:37:08
分类:效率依赖:代码执行 / 读写文件 / 内部调用大模型应用场景:工作流 / 校对润色 / 任务管理

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add adversarial-review
Metadata
name
adversarial-review
description
Run a structured adversarial multi-agent review loop on any significant document. Spawns parallel Opus reviewers with different critical lenses, collects structured redlines, then guides farsight through agree/disagree positioning and v2 production. SELF-TRIGGERING: load this skill and run the complexity self-assessment whenever you are about to produce or have just produced any substantial document — score it and offer the review loop if it qualifies. Also load when the user says things like: 'use the review team', 'get the review team on this', 'spin up the reviewers', 'have the team look at this', 'red-team this', 'redline this', 'challenge this', 'critique this', 'tear this apart', 'poke holes in this', 'stress test this', 'pressure test this', 'sanity check this', 'validate this', 'get a second opinion', 'before we build/implement/ship this'.

Adversarial Review

Structured multi-agent review loop. Catches what a single agent misses.

Session store: ~/.openclaw/workspace/reviews/
Process: Init session → spawn Opus reviewers → collect redlines → position on each → produce v2 → deliver


Complexity Self-Assessment

Run this check whenever you produce a substantial document. Score 1 point per signal present. If score ≥ 3, offer the review loop without being asked.

# Signal Points
1 Has multiple interdependent components (failure in one affects others) 1
2 Involves schema changes, migrations, or index design 1
3 Irreversible or expensive to undo (data loss, structural rework) 1
4 Affects production systems, stored data, or external services 1
5 Introduces new abstractions, taxonomies, or data models 1
6 Has a defined sequence of steps where order matters 1
7 Contains security, access control, or permission logic 1
8 Will be acted on by code or agents without further human review 1
9 Document is longer than ~500 lines or covers 3+ distinct systems 1
10 Scott said "let's build this" or "implement this" at any point in the conversation 1

Score 0–2 → skip. Simple doc, don't add noise.

Score 3–6 → offer. "This scores [N]/10 on complexity. Want me to run the review team on it before we act?"

Score 7–10 → strongly recommend. Don't just offer — make the case. "This scores [N]/10 on complexity — multiple interdependent systems, production consequences, hard to reverse. I'd strongly recommend running the review team before we act on this. Today's taxonomy strategy was a 10/10 and the review caught 14 issues including multiple production-breaking bugs."


Quick Reference

Step Action
0. Init session scripts/new-review.sh <slug> <path-to-doc>
1. Choose reviewers Read references/review-types.md for the right bundle
2. Spawn reviewers sessions_spawn with model=anthropic/claude-opus-4-6, mode=run — all in parallel
3. Wait Reviewers auto-announce. Do NOT poll.
4. Save raw output Write each reviewer result to redlines/reviewer-{role}.md
5. Synthesize scripts/synthesize.sh <session-dir> → writes redlines/combined.md
6. Position AGREE / DISAGREE / MODIFY on every redline → write positions.md
7. Produce v2 Write output/{slug}-v2.md incorporating accepted changes + rejected appendix
8. Deliver scripts/cp-output.sh <session-name> <destination>

Session Directory Structure

~/.openclaw/workspace/reviews/{YYYY-MM-DD}-{slug}/
├── input/
│   └── {original-filename}       ← copy of doc being reviewed
├── redlines/
│   ├── reviewer-{role}.md        ← raw output per reviewer
│   └── combined.md               ← synthesize.sh output (sorted by severity)
├── positions.md                  ← farsight agree/disagree log
└── output/
    └── {slug}-v2.md              ← final document

Review Types

Document Type Reviewer A Reviewer B
Architecture / strategy Theory & data modeling Implementation & systems
Pipeline / workflow Sequencing & dependencies Failure modes & ops
Schema / migration SQL correctness & constraints Performance & indexes
Security design Threat modeling Implementation gaps
Marketing / positioning Message clarity & truth Competitive exposure
API / interface design Consistency & contracts Consumer experience

For full persona prompt templates → read references/reviewer-personas.md
For pre-configured bundles → read references/review-types.md


Spawning Reviewers

Spawn ALL reviewers simultaneously — parallel, not sequential. Independent reviewers find different issues.

Model Selection

Doc Score Default Model Rationale
7–10 anthropic/claude-opus-4-6 Deep reasoning required; subtle architectural flaws need Opus
3–6 anthropic/claude-sonnet-4-6 Worth trying; structured prompts may close the gap

A/B testing note: If Sonnet misses a CRITICAL issue that Opus would have caught on a 3–6 doc, upgrade that doc type to Opus permanently. Track findings in references/model-notes.md as patterns emerge.

Key parameters for every reviewer spawn:

model: anthropic/claude-opus-4-6   ← or sonnet for 3-6 scored docs
mode: run
runTimeoutSeconds: 300
label: reviewer-{role}

The task field contains the full reviewer prompt from references/reviewer-personas.md plus the document content to review.


Positioning Rules

For EVERY redline, take an explicit position. No skipping.

Position When Requirement
AGREE Critique is correct, change should be made State what changes
DISAGREE Original design is defensible Must provide rationale — not just dismissal
MODIFY Issue is real, suggested resolution is wrong Propose your alternative

All CRITICAL redlines default to AGREE unless strongly defensible.
At least 1 DISAGREE expected — if zero, you may be rubber-stamping.

Write positions to positions.md in the session directory.


v2 Requirements

  • Revision table at the top (what changed and why)
  • All AGREE + MODIFY changes incorporated
  • Rejected redlines documented in an appendix ("considered and rejected")
  • Version bumped, date updated
  • Saved to output/{slug}-v2.md

Quality Bar

A good review session produces:

  • ≥2 CRITICAL issues (if zero, reviewers weren't adversarial enough — re-spawn with harder prompt)
  • ≥1 DISAGREE from farsight (if zero, consider whether the doc was genuinely perfect or just unchallenged)
  • A v2 meaningfully different from v1

Redline Format

**[REDLINE-{TYPE}-{NNN}]** {Section reference}
**Claim:** What the document says
**Challenge:** The specific objection or gap
**Severity:** CRITICAL | MAJOR | MINOR
**Suggested Resolution:** What should change

Full spec → read references/redline-format.md