From triage-three
This skill should be used when the user asks for adversarial code review, security audit, bug triage, architecture review, or any deep analysis that benefits from multiple perspectives challenging each other. Trigger phrases include: 'triage this', 'find bugs in', 'security audit', 'review this code', 'adversarial review', 'find vulnerabilities', 'audit this for', 'review this PR for correctness'. Uses three adversarial roles (Pusher finds, Challenger questions, Arbiter decides) with style presets (measured, wide-funnel, paranoid, baseline, max-tension).
How this skill is triggered — by the user, by Claude, or both
Slash command
/triage-three:triage-threeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Adversarial triage with three roles. Argument: $ARGUMENTS
Adversarial triage with three roles. Argument: $ARGUMENTS
Triage-three orchestrates adversarial subagents — Pushers propose, Challengers question, Arbiters decide — to produce high-confidence results through tension.
The core unit is the Pusher–Challenger pair: a thesis and its Socratic interrogation. Multiple pairs explore different angles of the same problem. The Arbiter synthesizes across all pairs into verified truth.
For multi-run triage, the Investor sits between runs — a fund manager operating under the user's goal as its charter. It analyzes ROI, reallocates effort, and issues a directed investment thesis. Every allocation must trace back to the charter. Runs are controlled capital deployment, not open-ended repetition.
Everything works in threes: three roles, up to three angles, up to three runs.
Each finding follows a lifecycle: Proposed → Questioned → Decided. Every agent has a point ledger that makes trade-offs explicit. State the relevant scoring table in each agent's prompt.
For complete scoring tables (Pusher, Challenger, Arbiter, Investor ledgers, escalation multipliers), consult references/scoring.md.
Parse the goal from $ARGUMENTS. If empty or unclear, ask using AskUserQuestion.
From the goal, determine what the three roles do. Do NOT ask the user to name or confirm them — just proceed.
Read the goal and reason about the right effort level. Consider:
Derive effort:
| Effort | Angles | Depth | When |
|---|---|---|---|
| Light | 1 | surface | Focused question, small scope, low stakes |
| Standard | 3 | thorough | Most tasks. Broad enough to catch what matters. |
| Deep | 3 | exhaustive | Critical systems, security audits, complex problems |
Briefly tell the user the reasoning and chosen effort level before proceeding:
"This looks like a [light/standard/deep] triage. I'll explore [N] angle(s): [list]. Here's why: [1-sentence rationale]."
If the user pushes back, adjust. Otherwise, proceed. Do NOT present parameter tables or ask the user to pick from systematic options.
When using multiple pairs, identify distinct angles — genuinely different perspectives, not overlapping.
Identify what agents will operate on:
Gather context so agents work on concrete material. Do NOT run agents on vague input.
Execution order:
For complete prompt templates for each role (Pusher, Challenger, Arbiter), consult references/prompts.md.
Select mandate from style (default: measured):
| Style | Mandate |
|---|---|
measured | "Find real issues. Accuracy over quantity. Evidence for each claim." |
wide-funnel / baseline | "Find as much as possible. Quantity and depth. Don't self-censor." |
paranoid / max-tension | "Assume everything is broken. Find what others would miss." |
Include scoring from references/scoring.md (Pusher's Ledger section) in the prompt. Output: numbered findings, each with statement + evidence/location + severity.
The Challenger uses Socratic questioning — not assertion — to stress-test findings. The Challenger genuinely investigates each question against the source material before reaching a verdict.
Select intensity from style:
| Style | Intensity |
|---|---|
measured / wide-funnel | Genuine inquiry. Verify together. Benefit of the doubt when evidence is ambiguous. |
baseline | Skeptical cross-examination. Prove it or it's out. |
paranoid / max-tension | Hostile interrogation. Wrong until proven right. |
Five Socratic questions per finding:
Verdicts: CONFIRMED, REJECTED, or DISPUTED. Include scoring from references/scoring.md (Challenger's Ledger).
After ALL pairs complete, the Arbiter synthesizes across every angle.
Select mandate from style:
| Style | Mandate |
|---|---|
measured / baseline / max-tension | "Only verified truth. False positive = heavy penalty. Missing true finding = mild penalty." |
wide-funnel | "Most complete truth. Missing real finding = HEAVY penalty. Borderline inclusion = mild penalty." |
paranoid | "Only PROVABLY TRUE. Any doubt → exclude." |
Rules:
Output: verified findings grouped by priority, each with evidence, severity, recommendation. Stats: total → confirmed → rejected → disputed → final.
If effort is Deep or the user requested multiple runs:
references/prompts.md for the Investor prompt template.For Investor scoring, charter drift detection, and the complete Investor prompt, consult references/scoring.md and references/prompts.md.
references/scoring.md for ledger format)style=X in arguments; defaults to measuredmeasured, wide-funnel, baseline, paranoid, max-tensionFor detailed scoring and prompt templates, consult:
references/scoring.md — Complete scoring tables for all roles, escalation multipliers, Investor ledger, charter drift detectionreferences/prompts.md — Full prompt templates for Pusher, Challenger, Arbiter, and Investor subagentsnpx claudepluginhub lagz0ne/triage-threeConducts devil's advocate stress-testing on code, architecture, PRs, and decisions to surface hidden flaws via structured adversarial analysis. For high-stakes reviews only.
Orchestrates a three-phase adversarial code review with isolated agents (Hunter, Skeptic, Referee) to eliminate sycophancy and produce high-fidelity bug reports. Use for thorough code review, bug hunting, security audits.
Dispatches concurrent code reviews from architecture, security, and testing perspectives on paths, modules, PRs, or staged changes before merging or release.