interrogate

Interrogate

Three independent reviewers try to break the work before it ships. Diversity is the mechanism: reviewers on different models or provider families find different classes of defects, and agreement across them is high-signal. This is an adversarial lane on top of review, not a replacement for it.

When to use

• a diff or design is contested, high-risk, or security-adjacent
• work is about to ship and a single review pass is not enough evidence
• the user asks to "stress-test", "red-team", or "try to break" a change

When not to use

• routine changes with passing verification — review alone is enough
• the deliverable is an answer, not an artifact under judgment

Phase 1 — Frame the target

Name exactly what is under interrogation: the diff (default), a design doc, or an API contract. State the invariants the change must preserve; reviewers attack those first.

Phase 2 — Seat the panel

Spawn three reviewers in one message, in the background, each read-only:

• seat the panel as a diverse-model panel — different provider families find different defect classes, and agreement across them is high-signal. Read team.roleRouting from the project config (.claude/omc.jsonc) or the user config (claude-omc/config.jsonc; omc config prints the effective values) and collect up to three distinct provider families in canonical role order, filling any remaining seats from the default families — claude, codex, gemini — not already seated, and say which family each seat got. When no routing config exists, fall back to OMC_TEAM_WORKTREE_MODE=detached omc team --no-decompose 1:claude,1:codex,1:gemini "<the framed target, the invariants, and one lens per seat>", or in-session Task dispatches to oh-my-claudecode:code-reviewer and oh-my-claudecode:security-reviewer on different models — the team command needs the task text; pass target, invariants, and lens allocation as that task
• each reviewer gets the same target by path, the invariants, and one lens: correctness, security and trust boundaries, or edge cases and failure modes
• wait for every reviewer to reach a terminal state and collect its output before Phase 3 — the team route starts workers asynchronously, and merging before they finish reports an empty panel; a worker that stalls past the stated interval is named as missing, not silently dropped. Keep worktrees and team state alive through judging, and run omc team shutdown <team-name> --force (the name the startup snapshot prints; --force skips the confirmation prompt) only in the final cleanup step after verification, as the arena skill sequences it
• instruct each to prove every finding with a run against the real code — a failing test, a repro script, or command output that shows the wrong behavior; for a design or plan, a prototype or a probe of the current tree — and to leave out anything it did not run. No findings is a valid result. Findings come back as {severity: blocker|major|minor, claim, evidence, location} where the evidence is the command and the output it printed — a finding without a run is dropped