From crucible
Performs adversarial reviews of design docs, implementation plans, code, PRs, or documentation using fresh Devil's Advocate subagents. Iterates until clean or stagnation detected.
npx claudepluginhub raddue/crucibleThis skill uses the workspace's default tool permissions.
<!-- CANONICAL: shared/dispatch-convention.md -->
Conducts devil's advocate stress-testing on code, architecture, PRs, and decisions to surface hidden flaws via structured adversarial analysis. For high-stakes reviews only.
Performs devil's advocate stress-testing on code, architecture, PRs, and decisions to surface hidden flaws, edge cases, and blind spots in high-stakes reviews.
Launches parallel agents for iterative review of plans or code across 4 escalating rounds: broad, multisample, focused, focused+multisample. Targets issues in plans >500 lines or with >3 components.
Share bugs, ideas, or general feedback.
All subagent dispatches use disk-mediated dispatch. See shared/dispatch-convention.md for the full protocol.
Adversarial review of any artifact. Dispatches a Devil's Advocate subagent to attack the work, fixes findings, then dispatches a FRESH Devil's Advocate to attack again. Iterates until clean or stagnation is detected.
Core principle: Fresh eyes every round. No anchoring, no confirmation bias.
Announce at start: "I'm using the red-team skill to adversarially review this artifact."
digraph red_team_loop {
"Dispatch FRESH Devil's Advocate" -> "Reviewer returns findings";
"Reviewer returns findings" -> "No Fatal/Significant issues" [label="clean"];
"No Fatal/Significant issues" -> "Artifact approved -- proceed";
"Reviewer returns findings" -> "Fatal/Significant issues found";
"Fatal/Significant issues found" -> "Dispatch fix agent";
"Dispatch fix agent" -> "Score issues (Fatal=3, Significant=1)";
"Score issues (Fatal=3, Significant=1)" -> "Compare weighted score to prior round";
"Compare weighted score to prior round" -> "Dispatch FRESH Devil's Advocate" [label="strictly lower score = progress"];
"Compare weighted score to prior round" -> "Escalate to user" [label="same or higher score = stagnation"];
"Reviewer returns findings" -> "Escalate to user" [label="architectural concern"];
}
crucible:quality-gate) may impose a global safety limit.Stagnation uses weighted scoring, not raw issue counts. This prevents false stagnation when Fatal issues are converted to Significant ones (which is genuine progress).
Weights: Fatal = 3 points, Significant = 1 point.
Example: Round 1 finds 2 Fatal + 1 Significant = score 7. Fixer eliminates both Fatals but surfaces 3 new Significants. Round 2 finds 0 Fatal + 3 Significant = score 3. That is progress (3 < 7), not stagnation.
Progress requires EITHER:
If neither condition is met, that is stagnation. Escalate to user with findings from both rounds.
The Devil's Advocate MUST classify every challenge:
| Artifact | Fix Mechanism |
|---|---|
| Design doc | Plan Writer subagent revises the doc |
| Implementation plan | Plan Writer subagent revises the plan |
| Code / implementation | Fix subagent (new, not the original implementer) |
| Documentation | Fix subagent |
| Standalone invocation | Caller decides |
Use the red-team-prompt.md template in this directory. Provide:
Model: Opus (adversarial analysis needs the best model)
Dispatch a NEW Devil's Advocate subagent (fresh, no prior context). Compute weighted score and compare:
crucible:code-review)If a reviewer returns fewer findings than expected, the review is likely shallow. Dispatch a second reviewer with the instruction: "A prior reviewer found N issues. Find what they missed."
| Artifact | Expected findings (Fatal + Significant) | Minimum dimensions covered |
|---|---|---|
| Design doc | 5-10 | All 6 |
| Implementation plan | 3-8 | Fatal Flaws, Hidden Risks, Fragility, Assumptions |
| Code (feature) | 3-6 | Fatal Flaws, Hidden Risks, Fragility |
| Code (refactor) | 2-5 | Fatal Flaws, Assumptions, Completeness |
These are guidelines, not quotas. A genuinely clean artifact with 1 finding and thorough dimension coverage is fine. A 1-finding review that only addresses one dimension is shallow regardless of the artifact.
No artifact ships without adversarial review.
Code review is necessary but not sufficient.
Code review checks quality — is the code correct, clean, well-structured? Red-teaming attacks assumptions — will this actually work under adversarial conditions? What happens when inputs are hostile, dependencies fail, or load exceeds expectations? These are non-overlapping concerns. Passing code review is not evidence that red-teaming is unnecessary.
| Excuse | Reality |
|---|---|
| "Code review already passed" | Code review and red-teaming have non-overlapping coverage. Review checks quality; red-teaming attacks assumptions under adversarial conditions. Both are required. |
| "This is a minor change" | Minor changes in critical paths have disproportionate blast radius. Small diffs are where subtle bugs hide — less code to review means less obvious where to look. |
| "We're behind schedule" | Skipping adversarial review saves hours now, costs days when the issue surfaces in production. Red-teaming is the cheapest place to find these issues. |
| "The design was thorough" | Thorough designs have thorough failure modes. Complexity = attack surface. The more thought went in, the more assumptions to challenge. |
| "Just a refactor, behavior unchanged" | Refactors are where equivalence assumptions hide. Red-team verifies the equivalence claim — the most dangerous bugs are ones where "nothing changed" but something did. |
| "Quality gate will catch it later" | Quality gate invokes red-team. Skipping here means skipping there. |
| "The inquisitor already tested it" | Inquisitor writes executable tests for cross-component behavior. Red-team attacks design assumptions and failure modes that can't be expressed as tests. Different tools. |
| "We already did N rounds" | Prior rounds found things to fix. That's evidence the artifact needed review, not evidence it's now clean. Fresh eyes, every round. |
Process violations — Never:
Skip rationalizations — STOP if you catch yourself thinking:
Red-team operates in two modes depending on the caller:
When invoked by crucible:quality-gate: Run single-pass only. Return findings for this round. Do NOT iterate, do NOT apply stagnation detection, do NOT dispatch fix agents. Quality-gate owns the loop, stagnation detection, and fix dispatch. You are a reviewer, not a coordinator.
When invoked directly (e.g., by crucible:finish or standalone): Run the full iterative loop with stagnation detection, fix dispatch, and escalation as described above.
Multi-model consensus: When invoked by quality-gate on consensus-eligible rounds, quality-gate handles the multi-model dispatch via the consensus MCP tool. Red-team itself does not call consensus — the quality-gate orchestrator substitutes a consensus call for the red-team dispatch on eligible rounds. When invoked standalone, red-team uses single-model dispatch only.
Direct invocation only. When operating in single-pass mode (invoked by quality-gate), skip this section entirely — quality-gate handles its own external review integration.
After dispatching the host red-team subagent, call the external_review MCP tool with:
prompt: contents of skills/shared/external-review-prompt.mdcontext: same artifact + attack prompt context provided to the host reviewerskill: "red_team" (top-level argument for per-skill toggle enforcement)metadata: {"skill": "red_team"} (traceability)Per-skill toggle: The server checks the skill argument against skills.red_team in the external review config. Only active if set to true. If the external_review MCP tool is unavailable or the call fails, skip silently and proceed with host findings only.
Append external perspectives after the host Devil's Advocate findings in the output. External findings use the same Fatal/Significant/Minor classification but are informational only — they do NOT count toward stagnation scoring (INV-2). Only host red-team findings drive the scoring algorithm.
Called by:
Pairs with:
See prompt template: red-team/red-team-prompt.md