How to use The Fool skill in Claude Code to stress-test your decisions

Feb 14, 2026

Purpose

This post demonstrates how to use The Fool skill in Claude Code to apply structured critical reasoning to your ideas, plans, and decisions.

Environment

Claude Code CLI
claude-skills plugin installed
The Fool skill (version 1.0.0)

What is The Fool?

The Fool is a critical reasoning skill for Claude Code. It’s named after the court jester who alone could speak truth to the king. The skill applies structured critical reasoning across 5 modes to stress-test any idea, plan, or decision.

I think of it as a professional devil’s advocate that helps me find blind spots before I commit to something.

The skill works by:

Extracting my position from the conversation
Letting me choose how to challenge it
Applying a specific reasoning mode
Presenting 3-5 strongest challenges
Synthesizing insights into a strengthened position

There are 5 reasoning modes:

Mode	What It Does	Output
Expose My Assumptions	Socratic questioning	Probing questions grouped by theme
Argue the Other Side	Builds strongest counter-argument	Counter-argument + synthesis proposal
Find the Failure Modes	Pre-mortem analysis	Ranked failure narratives with mitigations
Attack This	Red teaming	Adversary profiles + attack vectors + defenses
Test the Evidence	Falsificationism	Claims audited with falsification criteria

Installation

I installed the claude-skills plugin first:

npm install -g claude-skills

Then I verified The Fool was available:

claude-skills list | grep fool

The skill should appear in the workflow category.

How to Invoke The Fool

There are several trigger phrases that activate The Fool:

“play the fool”
“devil’s advocate”
“challenge this”
“stress test”
“poke holes”
“what could go wrong”
“red team”
“pre-mortem”
“test my assumptions”

I can use these naturally in conversation with Claude Code. The skill will detect the trigger and activate.

Example 1: Stress-Testing a Technical Decision

When I was deciding between PostgreSQL and MongoDB for a new project, I used The Fool to challenge my choice.

I said to Claude:

I'm planning to use PostgreSQL for my new project. It needs to handle JSON documents, relational data, and full-text search. I think PostgreSQL is the right choice because it supports JSONB, has strong ACID guarantees, and I can use pgvector for embeddings later.

Play the fool on this decision.

Claude responded by asking me to choose a challenge mode:

How should I challenge this?

1. Expose my assumptions - Ask me the hard questions I haven't asked myself
2. Argue the other side - Build the strongest counter-argument and drive toward synthesis
3. Find the failure modes - Assume this fails and tell me why
4. Attack this - Think like an adversary looking for weaknesses
5. You choose - Recommend the best approach based on context

I chose option 2: “Argue the other side.”

Claude then:

Restated my position in its strongest form (steelmanning)
Built the strongest counter-argument for MongoDB
Proposed a synthesis

The counter-argument made me realize I hadn’t considered:

Schema migration overhead for rapid iteration
Document modeling patterns that might fit my domain better
Operational complexity compared to a document store

The synthesis proposed: “Use PostgreSQL if relational integrity is critical and schema is stable. Use MongoDB if domain is document-centric and schema will evolve rapidly.”

This helped me see that my “obvious” choice depended on assumptions about schema stability I hadn’t examined.

Example 2: Pre-Mortem for a Feature Launch

When launching a new feature, I used The Fool’s “Find the failure modes” mode.

We're launching a collaborative editing feature next month. It uses CRDTs, has a conflict resolution UI, and we've tested with 5 concurrent users. We expect 1000 active users in week 1.

Find the failure modes for this launch.

Claude ran a pre-mortem analysis and presented ranked failure narratives:

Failure Mode 1: Network partition causes massive conflicts

Likelihood: HIGH
Impact: HIGH
Early warning: Spikes in conflict rate > 10%
Mitigation: Add conflict rate dashboard, rate limit concurrent edits per document

Failure Mode 2: Mobile performance degrades unexpectedly

Likelihood: MEDIUM
Impact: HIGH
Early warning: Mobile session duration drops
Mitigation: Load test on real devices, set performance budget

Failure Mode 3: Users don’t understand conflict resolution

Likelihood: MEDIUM
Impact: MEDIUM
Early warning: Support tickets about “lost work”
Mitigation: Add onboarding tutorial, simplify conflict UI

The second-order thinking caught something I missed: if conflict rate spikes, users might share broken documents on social media, amplifying reputation damage beyond the actual technical issue.

Example 3: Evidence Audit for a Vendor Claim

When evaluating a monitoring tool, I used “Test the evidence” mode.

The vendor claims their APM tool reduces mean time to resolution (MTTR) by 40% based on a case study with a similar company. They have a logo wall of 50+ companies.

Test this evidence.

Claude extracted claims and applied falsification criteria:

Claim 1: “Reduces MTTR by 40%”

Falsification criteria: What would disprove this?
Evidence quality: LOW
- Sample size: 1 case study (n=1)
- Representativeness: Unclear if “similar company” is comparable
- Confounds: Did they change anything else (process, staffing)?
- Recency: Case study date not shown

Claim 2: “Trusted by 50+ companies”

Falsification criteria: Are these active, paying customers?
Evidence quality: NOT TESTABLE
- Logo wall doesn’t indicate adoption depth
- No distinction between trial, free tier, and enterprise
- No customer retention data

The audit revealed I was treating marketing as evidence. This helped me ask the vendor for actual metrics: “Can you share MTTR before/after for 5 customers in our industry?”

Best Practices

DO

Use before committing

Run The Fool before implementation, not after
Stress-test architecture decisions when they’re still cheap to change
Challenge vendor evaluations before signing contracts

Engage with the challenges

The skill asks you to respond before synthesis
Take time to consider each challenge
Some challenges may reveal real issues; others may strengthen your conviction

Run multiple modes

Each mode reveals different blind spots
Socratic questions expose assumptions
Pre-mortem finds failure modes
Red team finds attack vectors
Evidence audit tests your data

Start with “You choose”

If unsure which mode to use, let The Fool recommend
The skill analyzes context and picks the best approach
You can always run a second pass with a different mode

DON’T

Don’t skip the synthesis

The skill doesn’t just list problems
It integrates challenges into a strengthened position
Always review the synthesis and next steps

Don’t treat all challenges as equal

Some challenges will reveal fatal flaws
Others will be speculative edge cases
The skill ranks them by strength and relevance

Don’t override domain expertise

The Fool applies critical reasoning, not domain knowledge
If you’re the expert, the challenges may seem naive
Use your judgment to filter relevant from irrelevant

Don’t use for trivial decisions

The skill adds overhead for good reason
Reserve for decisions with real stakes
“What should I name this variable?” doesn’t need a pre-mortem

Common Workflows

Decision Validation

I use this 3-step workflow for major decisions:

Common Ground - Surface unstated assumptions
The Fool - Stress-test the decision with 2-3 modes
Architecture Designer - Document the refined decision as an ADR

Architecture Review

Before implementing:

Run “Find the failure modes” to discover technical risks
Run “Attack this” to find security vulnerabilities
Run “Argue the other side” to validate technology choices
Document mitigations in the architecture

Proposal Evaluation

When reviewing a business proposal or strategy:

Run “Expose my assumptions” to find hidden premises
Run “Test the evidence” to audit claims
Run “Find the failure modes” to anticipate execution risks
Use synthesis to strengthen or reject the proposal

The Fool works well with other skills:

Common Ground - Surface assumptions before challenging them
Architecture Designer - Document decisions after stress-testing
Code Reviewer - Tactical counterpart for implementation review
Security Reviewer - Domain-specific security challenges

Summary

In this post, I showed how to use The Fool skill in Claude Code to apply structured critical reasoning to decisions. The key point is that different modes reveal different blind spots: Socratic questions expose assumptions, pre-mortem finds failure modes, red team discovers attack vectors, and evidence audit tests your data.

The skill’s strength is that it doesn’t just challenge ideas - it synthesizes challenges into a stronger position. Each mode produces actionable output, not just objections.

For high-stakes decisions, I run The Fool with 2-3 modes before committing. It catches issues that are obvious in hindsight but invisible when I’m too close to the problem.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!