메뉴
After the thing exists: parallel reviewers over a diff one person or nobody has read, especially auth, payments or agent-written code. Fires on tear this apart.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/itsvedantkumar/vstack --skill interrogate명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| name | interrogate |
| description | After the thing exists: parallel reviewers over a diff one person or nobody has read, especially auth, payments or agent-written code. Fires on tear this apart. |
Spawn several parallel reviewers over the same diff, same intent, same rubric. Deduplicate their findings, then deliver a single bucketed verdict.
The deliverable is a verdict, not a patch. Do NOT auto-apply changes.
The original method assumed reviewers from different vendors — different training data, different blind spots — so agreement across models was strong independent evidence.
That premise does not hold here. Claude Code is Anthropic-only. Every reviewer is a Claude model. They share pretraining lineage, post-training, and safety tuning, so their blind spots are correlated. Two Claude models agreeing is weaker evidence than two vendors agreeing, and — more dangerously — four Claude models missing the same thing tells you almost nothing about whether it's there.
Two consequences, and they are load-bearing:
Do not describe this setup to the user as equivalent to multi-vendor review.
Identify what to review from context:
git diff main...HEAD (or the appropriate base branch) for the full changesetPackage the diff (or file contents) plus any surrounding context files the reviewers need to understand the code.
Before spawning reviewers, state the intent explicitly. What is this code trying to accomplish? Derive it from the user's message, commit messages, the PR description if one exists, and the code itself.
Write one clear paragraph. Reviewers challenge whether the work achieves the intent well, not whether the intent itself is correct. If the intent is genuinely ambiguous, pick the most plausible reading, state the assumption in the verdict, and proceed.
Spawn every reviewer in ONE message as multiple Agent tool calls. Four calls, one assistant turn. Do not spawn one, wait, spawn the next — sequential fan-out is the single most common failure of this skill and it costs you the wall-clock benefit of the whole method while producing an identical verdict. If you catch yourself writing a second message containing a second Agent call, you have already broken the skill.
Set run_in_background: false on all of them so the batch runs concurrently and every result is in hand before synthesis.
| Reviewer | subagent_type | model | Lens (rubric emphasis to stress in the prompt) |
|---|---|---|---|
| A | code-reviewer | opus | Correctness, concurrency, state, error paths |
| B | security-auditor | sonnet | Security, authn/authz, trust boundaries, TOCTOU, abuse |
| C | code-reviewer | fable | Structural integrity, complexity budget, code-judo simplifications |
| D | code-reviewer | haiku | Verification: tests, invariants, what would catch a regression |
Model slugs behind those overrides: opus → claude-opus-5, fable → claude-fable-5, sonnet → claude-sonnet-5, haiku → claude-haiku-4-5. Use the short override strings in the tool call.
code-reviewer and security-auditor have Read, Grep, Glob, Bash only, so reviewers are structurally read-only — they cannot edit the branch even if a finding tempts them. If a lens has no matching agent type, use subagent_type: "general-purpose" with model: set and forbid writes in the prompt body.
Scale the roster to the job: drop D on a pure refactor with no behavior change; drop B when nothing touches input, auth, secrets, or IO. Never drop below two lenses — one reviewer is what you already have.
Read references/reviewer-prompt.md and fill in the template for each reviewer with:
references/rubric.mdreferences/code-quality-review.md{LENS} slotEverything except {LENS} is identical across reviewers. The lens is the only deliberate divergence, so it has to carry the weight.
As results come back, build a unified picture:
You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator.
Read references/lead-judgment.md for the full framework. Reviewers see a slice of the codebase; you have the full context — the goal, the constraints, what was already tried and rejected. Use it aggressively.
Categorize every finding:
For each finding include: which reviewer(s) and lens(es) raised it, the category, and a one-line rationale.
[The stated intent paragraph from Step 2]
[Findings to address. For each: description, which reviewers raised it, why it matters.]
[Findings worth thinking about. For each: description, reviewers, tradeoff.]
[Valid but low-priority. Brief list.]
[Rejected findings with rationale, so the user can override your judgment where they disagree.]
Where reviewers converged, where they diverged, and what the pattern means. Then, explicitly: which lenses came back empty, and whether that is a clean bill of health or an untested area. Close with a one-line reminder that all reviewers were Anthropic models and share blind spots, so this verdict bounds known risk, not total risk.
In a Conductor workspace (CONDUCTOR_WORKSPACE_PATH is set), also post each Act-on and
Consider finding as an inline mcp__conductor__DiffComment at its file:line — that puts the
verdict in the Checks panel next to the diff, where the merge decision happens. Do not post
to GitHub unless asked.
Stop. The user decides what to fix. If they ask you to apply findings, treat that as a normal change — plan it, make it, verify it. Re-running interrogate on your own fixes is legitimate and often catches a bad patch.