RIJUDEVx/interrogate

What does interrogate do?

Spawn one reviewer per configured model to adversarially review code changes. Each model gets the same prompt and rubric. The adversarial signal comes from model diversity, not assigned personas.

A finding survives only when a run proves it.

The deliverable is a synthesized verdict. Do NOT auto-apply changes.

Step 1, Determine Scope

Identify what to review from context:

• If the user points at specific files or a diff, use that
• If on a feature branch, run git diff main...HEAD (or the appropriate base branch) for the full changeset
• If the user's message references recent work, gather the relevant files

Package the diff (or file contents) plus any surrounding context files the reviewers need to understand the code.

Step 2, State the Intent

Before spawning reviewers, state the intent explicitly. Derive this from:

• The user's message
• Commit messages
• PR description if one exists
• The code itself

Write one clear paragraph. If you're unsure about the intent, ask the user before proceeding.

Step 3, Spawn Reviewers

Launch all reviewers in a single message, one per slot, with the harness's sub-agent tool or delegate_task.

Aim for model diversity: different model families catch different bugs. In T3 Code, pick 3-4 strong models from the user's favourites, from different families, and start each with delegate_task (the t3-tools skill has the steps). Elsewhere, choose 3-4 distinct high-capability models the harness exposes. If you cannot select a model per subagent, spawn reviewers without a model override and get diversity from independent contexts instead.

Subagent	Role
Reviewer A	reasoning-heavy reviewer
Reviewer B	second, independent model family
Reviewer C	a third, fast/different family
Reviewer D	adversarial/strict code-quality reviewer

For each reviewer, spawn a general-purpose subagent:

• OpenCode / Codex: subagent_type: general (via the task tool)
• Claude Code: subagent_type: general-purpose
• Other harnesses: the closest general subagent that can read the repo

Keep reviewers read-only in spirit: they must not edit files. A reviewer that needs a repro runs it in its own scratch copy or worktree, never in place.

Give every reviewer this brief along with the filled template:

Break this change. Prove each finding with a run against the real code, such as a failing test, a repro script, or command output that shows the wrong behavior. For a design or plan, run a prototype or probe the current tree. Keep repros in your own worktree. Report each finding with a title, the exact command, the output it printed, and the output the intent requires. Leave out anything you did not run. That covers style, naming, structure, and risks that need a future change to matter. No findings is a valid result.

If a model slug is rejected as unresolvable, check the valid slugs in the Task tool's error message, pick the closest equivalent (prefer the highest-reasoning tier of the same family), and spawn with the valid slug. Do not block the review on the slug issue.

Read references/reviewer-prompt.md and fill in the template with:

1. The stated intent
2. The diff or file contents
3. The review rubric from references/rubric.md
4. The code-quality lens from references/code-quality-review.md

The same filled template goes to all reviewers, so every model applies the code-quality lens.

Step 4, Synthesize

As results come back, build a unified picture:

1. Verify each finding by rerunning its command. Keep a finding when the output shows the failure and the failure breaks the intent. Drop the rest. Merge findings that share a root cause.
2. Parse all findings from the reviewers
3. Identify consensus. Findings raised by 2+ models independently are highest signal.
4. Identify lone-model findings. Still worth reading, but weight accordingly.
5. Deduplicate. Different models may describe the same issue differently. Merge these and note which models raised it.
6. Note disagreements. If one model flags something and another explicitly says the opposite, that's useful context for the verdict.

Step 5, Lead Judgment

You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator.

Read references/lead-judgment.md for the full framework.

Categorize every finding using these buckets:

• Act on. Real issues affecting correctness, security, or maintainability given the actual goals. These would block a real PR.
• Consider. Legitimate points, but you're not sure they outweigh the cost of addressing them right now. Worth the user's attention.
• Noted. Technically valid but not actionable. Context-dependent, premature optimization, or low-impact given the current stage.
• Dismissed. Wrong, nitpicky, or missing context. Brief explanation why.

For each finding, include:

• Which model(s) raised it
• The category (act on / consider / noted / dismissed)
• A one-line rationale for the categorization

Output Format

Present the verdict in this structure:

Intent

[The stated intent paragraph from Step 2]

Reviewers

• Reviewer [label]: [model name], [N findings] (one bullet per reviewer)

Act On

[Findings that should be addressed. For each: description, which models raised it, why it matters.]

Consider

[Findings worth thinking about. For each: description, which models raised it, tradeoff involved.]

Noted

[Valid but low-priority. Brief list.]

Dismissed

[Rejected findings with brief rationale, including findings no run proved.]

Agreement Map

[Where did models agree, where did they diverge, and what does the pattern of agreement/disagreement tell us?]

Blast radius

Use this mode when a change is small but not yet trusted, and the question is what it breaks beyond the diff. Listing the callers is not the job. Grep finds those in a second. The job is the breakage grep won't show.

Don't trust your own writeup

A writeup of what a change breaks that sounds right is worthless. It reads as convincing whether or not it's true. So don't hand back the writeup. Find the one or two facts the whole thing depends on and prove them by running code.

How sure are you

For each fact the change's safety depends on, get it as far down this list as is cheap, and say where it stopped.

1. You said so. Worthless on its own.
2. You pointed at the line. A real file:line, or the library's own source.
3. You showed the bad case can't happen. You walked the failure step by step and it doesn't reach.
4. You ran it. A script or test that calls the real code and fails loud if you're wrong.
5. You reproduced it in the running app.

Any safety fact you can't get to step 4, say so. Don't write it up as settled. Step 4 is usually one small script that imports the same library the app ships and calls the exact function you're worried about.

Steps

1. Read the change. The diff, the symbols it adds, changes, and deletes, and what it now does differently, including the part the diff doesn't spell out. Pull the PR and commit messages for the reason behind it.
2. Find the one fact it's safe because of. Most changes that look risky are safe because of a single fact, like "this call only drops already-dead cache entries and does nothing else". Find that fact. If it holds, most risky cases are cleared at once. Spend your time here, not on a long list of maybes.
3. Look where grep stops. Read the source of the library you call, and check its pinned version and any local patch. Work out when things run: microtasks, unmount and teardown, Solid versus React. Follow what a symbol search misses: the JSON an API returns, a DB column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream.
4. Be honest about each risk. Give it a real chance of happening and a real cost if it does. Keep the risks you confirmed. List the ones you checked and cleared separately. Cite a real file:line, a search that finds nothing is still an answer, and never make up a caller or an API.
5. Prove the one fact. Write a script or test that runs the real code, run it, and paste what happened. If you can't prove it cheaply, mark it unproven. Don't overstate.
6. For a big or wide change, run it through the review above with several models. Different models catch different real bugs.

What to hand back

• What it does. What changed, including the part that isn't obvious.
• The one fact it's safe because of. State it, say which step you got it to, and show the proof. If you couldn't prove it, write unproven.
• Risks. Only the real ones. Each names how it breaks, the file:line, how likely and how bad, and how to check. Paste the proof for the ones that matter.
• Cleared. What you checked and why it's fine.
• Before you merge. The cheapest test or repro that catches the real bug, including the script you wrote.

Write it through unslop, cite real code, and strip anything private before it goes anywhere public.

Reply: the writeup above, with the one safety fact either proven or marked unproven.