What is the purpose of adversarial-review?

To verify spec compliance with binary verdicts and prevent anchoring bias by using fresh reviewers.

Why must reviewers be fresh after a FAIL?

Fresh reviewers avoid memory of prior findings, reducing anchoring bias and ensuring independent judgment.

What counts as evidence for a verdict?

Required file:line citations that clearly support the PASS or FAIL verdict against the spec.

adversarial-review

Scanned

npx machina-cli add skill a5c-ai/babysitter/adversarial-review --openclaw

Files (1)

SKILL.md

1.4 KB

Adversarial Review

Overview

Independent adversarial code review checking spec compliance. Uses binary PASS/FAIL verdicts (not subjective feedback) with required file:line evidence citations.

When to Use

After quality gates pass in the execution loop
For final comprehensive cross-unit review
When verifying spec compliance of any implementation

Key Differences from Collaborative Review

Aspect	Collaborative	Adversarial
Goal	Help improve code	Verify spec compliance
Verdict	Suggestions	Binary PASS/FAIL
Evidence	Optional	Required (file:line)
Reviewer	Can be reused	Must be fresh
Context	Shared	Independent

Fresh Reviewer Rule

On re-review after FAIL, a NEW reviewer instance spawns with no memory of the previous review. This prevents anchoring bias where a reviewer fixates on previously identified issues.

Anti-Patterns

Reusing reviewers after FAIL
Passing previous findings to new reviewers
Providing subjective or advisory feedback
Accepting partial compliance as PASS

Tool Use

Invoke as part of: methodologies/metaswarm/metaswarm-execution-loop (Phase 3)

Source

git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/methodologies/metaswarm/skills/adversarial-review/SKILL.md

View on GitHub

Overview

Independent adversarial code review checks spec compliance using binary PASS/FAIL verdicts rather than subjective feedback. Evidence citations in the form file:line are required, and reviewers must be fresh to prevent anchoring bias.

How This Skill Works

A reviewer instance analyzes the implementation against the spec and returns a binary PASS or FAIL. Each cycle requires file:line evidence citations, and a fresh reviewer is spawned when a FAIL occurs to prevent anchoring bias. The process is integrated into the metaswarm execution loop (Phase 3).

When to Use It

After quality gates pass in the execution loop
For final comprehensive cross-unit review
When verifying spec compliance of any implementation
Before shipping changes to production
During external audits or security reviews

Quick Start

Step 1: Trigger adversarial-review in the metaswarm execution loop (Phase 3).
Step 2: Reviewer analyzes the implementation and outputs a binary PASS/FAIL with file:line citations.
Step 3: If FAIL, spawn a fresh reviewer and re-run until a PASS or final decision is reached.

Best Practices

Enforce binary PASS/FAIL verdicts only; avoid subjective feedback
Require precise file:line citations as evidence for every verdict
Spawn a fresh reviewer after any FAIL to prevent anchoring bias
Isolate context so each review has no memory of prior findings
Run this review within the metaswarm-execution-loop Phase 3

Example Use Cases

Module X fails to meet input validation spec; reviewer cites src/input.rs:128 and issues a FAIL with concrete evidence.
Module Y passes all spec criteria; reviewer returns PASS with file:line citations across multiple files.
After an initial FAIL, a fresh reviewer re-evaluates and confirms issues, yielding a PASS only after fixes.
Cross-unit review finds a patch in auth-service still violates the authentication spec at auth.go:90.
End-to-end behavior is thoroughly verified; final verdict is PASS with a consolidated set of citations.

Frequently Asked Questions

Add this skill to your agents