/devils-advocate

name: devils-advocate
description: "Systematically challenge current assumptions before major decisions. Counters confirmation bias, groupthink, and overconfidence."
metadata:
  instruction_budget: "26"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

Devil's Advocate

Run before every major diamond transition and architecture decision. Source: Kahneman, Shotton.

Technique 1: Pre-Mortem

Imagine it's 6 months from now and this decision FAILED spectacularly. 1. What went wrong? 2. What assumption was the weakest link? 3. What signal did we ignore? 4. Who was affected and how?

Technique 2: Assumption Reversal

For each key assumption:

• State the assumption explicitly
• Ask: "What if the OPPOSITE is true?"
• What evidence would support the opposite?
• Is there any evidence we've dismissed?

Technique 3: Red Team

Attack your own position:

• What would a competitor say about this approach?
• What would a skeptical user say?
• What would a security auditor find?
• What would an accessibility advocate flag?

10 Challenge Questions

1. What are we most confident about? (That's where overconfidence hides) 2. What evidence have we dismissed or downweighted? 3. Are we anchored on our first idea? (Shotton - anchoring bias) 4. Have we tested with users who DON'T match our ideal profile? 5. What would make us abandon this direction entirely? 6. Are we building for ourselves or for actual users? 7. What's the simplest version that could validate/invalidate this? 8. What have we NOT measured that we should? 9. If we had to start over, would we make the same choice? 10. Who disagrees with us and what's their strongest argument?

Technique 4: Attribution-vs-Consistency Check

Per anti-pattern *Consistency-as-Evidence* (#7) — graduated 2026-05-09 from a recurring failure where causal chains were built from observational consistency rather than verified attribution.

For each piece of evidence supporting the current claim, label it:

• **Cleanly-attributed**: the cause was demonstrably driving the effect (the action was Mycelium-specific, the variable was isolated, the alternative explanations were ruled out).
• **Consistency-only**: the data is *compatible with* the hypothesis but doesn't *isolate* the cause (the user reported X in a context where Y was also true; the trend matches the prediction but matches three other predictions equally well).
• **Unrelated**: the evidence is a different question entirely; don't include it in the chain.

If ≥1 link in a chain is consistency-only, mark the chain provisional and explicitly identify the missing attribution evidence. If N=1, do not publish a structural conclusion (e.g., "this generalizes to all users") until N≥2 with attribution. Apply this check to your own analysis pre-publish, not after the user catches it.

Technique 5: Ambient triggering on assertion-shaped patterns

Per the bias cluster (corrections.md TL;DR — L5 sycophancy, eval overfitting, sharper-framing anchoring; common root: "agent prefers what feels right over what evidence supports"):

Beyond formal diamond-transition use, run a fast self-check whenever you write text containing structural-claim shapes:

• "X causes Y"
• "this means Z"
• "the framework needs..." / "the user needs..."
• "the right answer is..."
• "this generalizes to..." / "this applies broadly..."

For each, ask: *what specific evidence supports this claim, and does any of it merely support it by consistency rather than attribution?* (Technique 4). If you can't name cleanly-attributed evidence for the claim, downgrade it: from assertion to hypothesis, from "X causes Y" to "X is consistent with Y; attribution evidence pending."

This converts the framework's own anti-bias discipline into a per-publish self-check, not just a per-decision ceremony. Graduated 2026-05-09 from corrections.md TL;DR open candidate.

**MEASURED FIRE RATE, 2026-08-16: ZERO — and this note stays until that changes.** In a dogfood session where twelve agent claims were withdrawn or corrected, this trigger fired on none of them. The operator caught six, explicit invocation of this skill caught two, late self-review caught three, one was caught proactively. **A detector keyed on the five shapes above then scored 0 of 5 recall against the claims actually withdrawn**, because those were universals and counts — "nobody left", "every instance", "eight statements" — not causal assertions. **The five shapes named above are the wrong list for the failure population this technique exists to catch.** Keep running it; do not treat it as coverage. Technique 7 is what measured well.

Technique 7: Blind adversarial pass — the one that measured well

**USE THIS BEFORE A CLAIM LANDS ON A DURABLE SURFACE.** Techniques 3 and 5 ask you to attack your own position. Measured against real withdrawn claims, self-attack found little and the ambient trigger found nothing. This found defects that had already survived self-review, four local gates and CI.

**PREREQUISITE, AND CHECK IT BEFORE YOU START.** This technique REQUIRES the ability to spawn a subagent. If subagent spawning is unavailable — the host forbids it, the user has asked that agents not be spawned unprompted, or the runtime has no such tool — **then the technique with the best measured result is not available to you, and the fallback is self-attack, which this skill's own measurements describe as weaker.** In that case you MUST (a) say so in the output, naming this technique as unavailable rather than silently substituting Technique 3 or 5, and (b) offer to run it if the user is willing to permit one subagent. Reported by a plugin consumer 2026-08-31, where a session-level no-subagent instruction silently downgraded the pass and not