Skill

devils-advocate

Challenges assumptions before major decisions like diamond transitions and architecture choices using pre-mortems, assumption reversals, red teaming, and 10 key questions to counter biases.

developer-tools

npx claudepluginhub haabe/mycelium --plugin mycelium

Tool Access

This skill uses the workspace's default tool permissions.

Preview

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

SKILL.md

Similar Skills

challenge-mode

Challenges assumptions, identifies blind spots, quantifies avoidance costs, and forces concrete action on strategic decisions, founder dilemmas, reasoning validation, or pushback requests.

majestic-founder

the-fool

8.9k

Challenges ideas, plans, decisions, and proposals using structured critical reasoning modes: devil's advocate, pre-mortem, red team, Socratic questioning, and evidence falsification.

6 files

fullstack-dev-skills

oracle-challenge

Challenges coding approaches with critical thinking: questions assumptions, examines evidence, explores alternatives, assesses risks and context fit. Use to validate decisions and test validity.

python

Stats

Parent Repo Stars24

Parent Repo Forks4

Last CommitMay 9, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

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 .claude/harness/decision-log.md alongside the decision.

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 .claude/harness/decision-log.md alongside the decision.