---
name: interrogate
description: "Adversarially review code changes from multiple independent angles, then synthesize a verdict. Use for /interrogate, 'adversarial review', 'multi-model review', 'challenge this', 'stress test this code', 'find blind spots', or 'tear this apart'. Does NOT auto-apply changes."
license: MIT
metadata:
  adapted-from: "cursor/plugins/pstack/skills/interrogate"
  version: "1.0.0"
---

# Interrogate

Spawn several independent reviewers to adversarially review code changes. Each reviewer gets the same prompt and rubric; the adversarial signal comes from diversity of angle and reasoning, not assigned personas. The deliverable is a synthesized verdict. **Do NOT auto-apply changes.**

## Step 1: Determine scope
Identify what to review. If the user points at files or a diff, use that. If on a feature branch, run `git diff main...HEAD` (or the appropriate base) for the full changeset. Package the diff (or file contents) plus any context files reviewers need to understand the code.

## Step 2: State the intent
Write one clear paragraph on what the change is trying to do, derived from the user's message, commit messages, PR description, and the code itself. If unsure, ask the user before proceeding.

## Step 3: Spawn reviewers
Launch multiple read-only reviewers in parallel via `invoke_sub_agent`. Prefer diverse reasoning profiles across reviewers; route by role and let Kiro select the actual model (do not hardcode model identifiers). Give each reviewer the same filled prompt: the stated intent, the diff/file contents, and the rubric below.

Rubric each reviewer applies:
- **Correctness**: bugs, broken edge cases, wrong assumptions, race conditions.
- **Security**: injection, auth/authorization gaps, secret handling, unsafe input at boundaries.
- **Breaking changes**: cross-module side effects that break existing behavior.
- **Maintainability**: needless complexity, spaghetti growth, leaky abstractions, wrong layer.
- **Contract/types**: unnecessary optionality, casts, `any`/`unknown` obscuring the real invariant.
Each reviewer returns prioritized findings with file:line evidence.

## Step 4: Synthesize
Parse all findings. Identify consensus (raised by 2+ reviewers independently = highest signal). Note lone-reviewer findings (weight accordingly). Deduplicate across reviewers, noting who raised each. Note explicit disagreements.

## Step 5: Lead judgment
You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator. Categorize every finding:
- **Act on** — real correctness/security/maintainability issues given the actual goals; would block a real PR.
- **Consider** — legitimate but the cost/benefit is unclear right now; worth the user's attention.
- **Noted** — technically valid but not actionable (context-dependent, premature, low-impact).
- **Dismissed** — wrong, nitpicky, or missing context; say why briefly.
For each finding, include which reviewer(s) raised it, the category, and a one-line rationale.

## Output format
Sections: **Intent**, **Reviewers** (one bullet each with finding count), **Act On**, **Consider**, **Noted**, **Dismissed**, **Agreement Map** (where reviewers agreed/diverged and what that pattern implies). Present the verdict; leave the fixes to the user or a separate, explicitly-requested change.