> ## Documentation Index > Fetch the complete documentation index at: https://lizamas.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Adversarial Pairing: Doer and Reviewer Agent Sessions > Adversarial Pairing runs a doer agent and one or more reviewer agents in separate terminal sessions, coordinating through a shared Markdown blackboard. Adversarial Pairing sits between solo Pairing mode and the full Multi-Agent System. You run one doer agent and one or more reviewer agents in separate terminals, all coordinating through a shared Markdown blackboard. The doer holds the only coding session; reviewers read the blackboard, inspect submitted artifacts, and issue verdicts — without asking you for each individual review action. The result is peer-agent accountability without the overhead of a full autonomous sprint. ## When to Use It > [card] High-stakes Pairing changes > > Changes that are too risky to rely on a single agent's judgment — database migrations, auth flows, public API modifications. > [card] Complex debugging > > Hard bugs where you want root-cause analysis reviewed by a second agent before the fix is written. > [card] Architectural edits > > Structural changes that touch multiple subsystems and benefit from cross-model review before a single line of production code is written. > [card] Full MAS is too heavy > > The task is well-scoped and doesn't need 11+ agents, but a single reviewer is better than none. ## How It Works Adversarial Pairing runs multiple standard Pairing sessions against one shared Markdown file — the **blackboard**. Each session is an ordinary agent terminal: * **One doer session** — the only session with permission to write code or make state changes * **One or more reviewer sessions** — run autonomously, reading the blackboard and writing verdicts without prompting you for each action The blackboard tracks the goal, plan, submitted artifacts, review notes, validation output, and final decisions. It's a coordination surface, not a chat log. > [!NOTE] > > Run reviewers on **different model providers** whenever possible. When your doer is Claude and your reviewers include Codex (or vice versa), each model's distinct blind spots become visible. Disagreement between reviewers is useful signal — it surfaces assumptions that a single-provider review would pass silently. ## Activating Adversarial Pairing Start the doer session first so it can create and initialize the blackboard. Then open reviewer sessions against the same blackboard path. > [tab] Basic setup > > Open three terminals in your initialized project directory: > > **Terminal 1 — Doer:** > > ```bash theme={null} > # In your agent session, run: > /adversarial-pairing doer .liza/adversarial/my-task.md > ``` > > **Terminal 2 — Reviewer (Claude):** > > ```bash theme={null} > /adversarial-pairing reviewer-claude .liza/adversarial/my-task.md > ``` > > **Terminal 3 — Reviewer (Codex):** > > ```bash theme={null} > /adversarial-pairing reviewer-codex .liza/adversarial/my-task.md > ``` > > The `reviewer-` form tells each reviewer both its role and the stable ID it registers on the blackboard — useful when running multiple reviewers so their verdicts are clearly attributed. > [tab] With yolo flag > > If you want the doer to proceed through its own approval gates without pausing for your confirmation each time, add `yolo` to the doer invocation: > > ```bash theme={null} > /adversarial-pairing doer .liza/adversarial/my-task.md yolo > ``` > > > [!WARNING] > > > > `yolo` skips **doer-side human approval gates only**. It does not waive reviewer approvals, reviewer stop conditions, validation requirements, or your ability to issue a stop instruction at any time. Reviewer sessions always require agent-to-agent approval before the doer commits. > [tab] Setting the goal > > If the blackboard file doesn't exist yet, include a short goal paragraph in your first doer message alongside the activation command: > > ```text theme={null} > /adversarial-pairing doer .liza/adversarial/retry-client.md > > Goal: Add exponential backoff retry logic to the HTTP client in > src/client.py. Retries should apply to 429, 502, 503, and 504 > responses only, with jitter, and be configurable per-caller. > ``` > > The doer records this goal in the blackboard before planning, so all reviewer sessions start from the same task frame. ## The Workflow **1. Doer records goal and plan** The doer reads the task, builds a plan, and writes both the goal and implementation plan to the blackboard. Reviewers can see this immediately. **2. Reviewers challenge the plan** Reviewer sessions read the blackboard, analyze the plan, and write review notes and verdicts. They challenge assumptions, flag risks, and request changes — they don't just suggest. A reviewer can block forward progress until its concerns are addressed. **3. Plan approval** Once reviewers approve the plan (and you approve if not in `yolo` mode), the doer has permission to write code. **4. Doer implements** The doer implements the approved plan in its working branch, then submits the candidate diff to the blackboard for code review. **5. Reviewers approve the diff** Reviewer sessions inspect the submitted diff and either approve or request changes. Follow-up rounds continue until all reviewers approve. **6. Doer commits, rebases, and merges** After reviewer approval, the doer commits, rebases, and merges into the target branch, then deletes its dedicated worktree and the topic branch. Without `yolo`, it asks you before each of these git state changes; with `yolo`, it proceeds unless a stop condition applies. ## Key Difference from Solo Pairing In standard Pairing mode, a reviewer's input is advisory — you make the final call. In Adversarial Pairing, **reviewer agents can block progress**. A reviewer verdict of "rejected" is not a suggestion; it halts the doer until the concern is resolved. This creates real accountability between agents, not a polite second opinion. For debugging tasks, you can configure the blackboard to require explicit root-cause analysis and a failing-test gate before implementation begins. That gives you MAS-style diagnostic rigor — diagnosis review and failing-test review — without handing the entire task to the autonomous pipeline. ## Blackboard Path Notes The blackboard file path is arbitrary — put it wherever makes sense for your project (`.liza/adversarial/` is a reasonable convention). The file is typically untracked and should not be committed unless you explicitly want a record. During coding, the doer normally uses a dedicated git worktree recorded in the blackboard; reviewers inspect the staged or unstaged diff for the current review round. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.