Mycelium devils-advocate
Systematically challenge current assumptions before major decisions. Counters confirmation bias, groupthink, and overconfidence.
install
source · Clone the upstream repo
git clone https://github.com/haabe/mycelium
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/haabe/mycelium "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/devils-advocate" ~/.claude/skills/haabe-mycelium-devils-advocate && rm -rf "$T"
manifest:
.claude/skills/devils-advocate/SKILL.mdsource content
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.
- What went wrong?
- What assumption was the weakest link?
- What signal did we ignore?
- 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
- What are we most confident about? (That's where overconfidence hides)
- What evidence have we dismissed or downweighted?
- Are we anchored on our first idea? (Shotton - anchoring bias)
- Have we tested with users who DON'T match our ideal profile?
- What would make us abandon this direction entirely?
- Are we building for ourselves or for actual users?
- What's the simplest version that could validate/invalidate this?
- What have we NOT measured that we should?
- If we had to start over, would we make the same choice?
- Who disagrees with us and what's their strongest argument?
When to Use
- Before every diamond scale transition (L2->L3, L3->L4)
- Before architecture decisions
- Before committing to a specific solution
- When the team feels "certain" (certainty is a bias signal)
Output
Log the challenge results in decision-log.md alongside the decision.