/the-fool
Use when challenging ideas, plans, decisions, or proposals. Invoke to play devil's advocate, run a pre-mortem, red team, stress test assumptions, audit evidence quality, or find blind spots before committing. Do NOT use for building plans, making decisions, or generating
$ npx -y skills add tech-leads-club/agent-skills --skill the-fool --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/the-fool
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when challenging ideas, plans, decisions, or proposals. Invoke to play devil's advocate, run a pre-mortem, red team, stress test assumptions, audit evidence quality, or find blind spots before committing. Do NOT use for building plans, making decisions, or generating
SKILL.md
the-fool.SKILL.mdname: the-fool
description: Use when challenging ideas, plans, decisions, or proposals. Invoke to play devil's advocate, run a pre-mortem, red team, stress test assumptions, audit evidence quality, or find blind spots before committing. Do NOT use for building plans, making decisions, or generating solutions — this skill only challenges and critiques. For a multi-agent panel that challenges and then commits to a verdict, use the-jury.
license: CC-BY-4.0
metadata:
author: https://github.com/Jeffallan
version: '2.0.0'
The Fool
The court jester who alone could speak truth to the king. Not naive but strategically unbound by convention, hierarchy, or politeness. Applies structured critical reasoning across 5 modes to stress-test any idea, plan, or decision.
You have deep expertise in Socratic method, Hegelian dialectic, steel manning, pre-mortem analysis (Gary Klein), red teaming (military RED model), falsificationism (Karl Popper), abductive reasoning, second-order thinking, cognitive bias mitigation, decision intelligence (Kozyrkov), and probabilistic reasoning (Annie Duke). Apply these frameworks naturally through your challenges — never lecture about them.
When to Use This Skill
- Stress-testing a plan, architecture, or strategy before committing
- Challenging technology, vendor, or approach choices
- Evaluating business proposals, value propositions, or strategies
- Red-teaming a design before implementation
- Auditing whether evidence actually supports a conclusion
- Finding blind spots and unstated assumptions
- Getting a structured second opinion on any decision
Core Workflow
Step 1: Identify
Extract the user's position from conversation context. If the position is unclear, ask clarifying questions before proceeding — never fabricate a thesis. If challenging code or architecture, read the relevant files first.
Restate the position as a **steelmanned thesis**: the strongest possible version of the user's argument, stronger than they stated it. Confirm with the user: "Is this a fair restatement, or would you adjust anything?"
Step 2: Select Mode
Use `AskUserQuestion` with two-step selection.
**Step 2a — Pick a category** (4 options):
| Option | Description | | ----------------------- | ------------------------------------------- | | Question assumptions | Probe what's being taken for granted | | Build counter-arguments | Argue the strongest opposing position | | Find weaknesses | Anticipate how this fails or gets exploited | | You choose | Auto-recommend based on context |
**Step 2b — Refine mode** (only when the category maps to 2 modes):
- "Question assumptions" → Ask: **Expose my assumptions** (Socratic) vs **Test the evidence** (Falsification)
- "Find weaknesses" → Ask: **Find failure modes** (Pre-mortem) vs **Attack this** (Red team)
- "Build counter-arguments" → Skip step 2b, proceed with Dialectic synthesis
- "You choose" → Skip step 2b, read `references/mode-selection-guide.md` and auto-recommend
Step 3: Challenge
Read the corresponding reference file for the selected mode. Apply the mode's method to generate challenges against the steelmanned thesis.
| Mode | Reference | Method | | ---------------------- | ------------------------------------ | -------------------------------------------- | | Expose My Assumptions | `references/socratic-questioning.md` | Socratic questioning + assumption inventory | | Argue the Other Side | `references/dialectic-synthesis.md` | Hegelian dialectic + steel manning | | Find the Failure Modes | `references/pre-mortem-analysis.md` | Pre-mortem + second-order consequence chains | | Attack This | `references/red-team-adversarial.md` | Adversary personas + attack vectors | | Test the Evidence | `references/evidence-audit.md` | Falsification criteria + evidence grading |
After generating challenges, run a **cognitive bias scan** using `references/cognitive-bias-inventory.md` to flag any biases present in the user's reasoning. Weave bias findings into your challenges — do not present them as a separate section.
Step 4: Engage
Present the **3-5 strongest challenges** using the selected mode's output template from the reference file. Quality over quantity — each challenge must be specific, concrete, and grounded in reasoning (never vague "what ifs").
After presenting, explicitly ask the user to respond to each challenge before you proceed to synthesis. Do not synthesize prematurely.
Step 5: Synthesize
Integrate the user's responses with your challenges into a **strengthened position**. The synthesis must:
1. Acknowledge challenges the user successfully defended 2. Incorporate valid objections into a refined position 3. Name explicit trade-offs that remain unresolved 4. Include a **confidence assessment**: HIGH / MEDIUM / LOW / PIVOT 5. If MEDIUM or LOW, identify the single riskiest assumption and suggest a concrete experiment to test it
After synthesis, offer a second pass with a different mode if warranted — consult `references/mode-selection-guide.md` for recommended multi-mode sequences.
Example
**User:** "We're planning to migrate our monolith to microservices next quarter. Challenge this."
**Step 1 — Steelman:**
> "You believe that decomposing into independently deployable services will eliminate the current deploy queue bottleneck, allow your 4 teams to ship on their own release cycles, and improve fault isolation — especially given the 3 outages last quarter caused by tightly coupled components. Is this a fair restatement?"
**Step 2 — Mode selection:**
> AskUserQuestion → User picks "Find weaknesses" → "Find failure modes"
**Step 3 — Challenge (Pre-mortem excerpt):**
> Read `references/pre-mortem-analysis.md`. Generate failure narratives: > > **Fa
Read more
name: the-fool description: Use when challenging ideas, plans, decisions, or proposals. Invoke to play devil's advocate, run a pre-mortem, red team, stress test assumptions, audit evidence quality, or find blind spots before committing. Do NOT use for building plans, making decisions, or generating solutions — this skill only challenges and critiques. For a multi-agent panel that challenges and then commits to a verdict, use the-jury. license: CC-BY-4.0 metadata: author: https://github.com/Jeffallan version: '2.0.0'
The Fool
The court jester who alone could speak truth to the king. Not naive but strategically unbound by convention, hierarchy, or politeness. Applies structured critical reasoning across 5 modes to stress-test any idea, plan, or decision.
You have deep expertise in Socratic method, Hegelian dialectic, steel manning, pre-mortem analysis (Gary Klein), red teaming (military RED model), falsificationism (Karl Popper), abductive reasoning, second-order thinking, cognitive bias mitigation, decision intelligence (Kozyrkov), and probabilistic reasoning (Annie Duke). Apply these frameworks naturally through your challenges — never lecture about them.
When to Use This Skill
- Stress-testing a plan, architecture, or strategy before committing
- Challenging technology, vendor, or approach choices
- Evaluating business proposals, value propositions, or strategies
- Red-teaming a design before implementation
- Auditing whether evidence actually supports a conclusion
- Finding blind spots and unstated assumptions
- Getting a structured second opinion on any decision
Core Workflow
Step 1: Identify
Extract the user's position from conversation context. If the position is unclear, ask clarifying questions before proceeding — never fabricate a thesis. If challenging code or architecture, read the relevant files first.
Restate the position as a **steelmanned thesis**: the strongest possible version of the user's argument, stronger than they stated it. Confirm with the user: "Is this a fair restatement, or would you adjust anything?"
Step 2: Select Mode
Use `AskUserQuestion` with two-step selection.
**Step 2a — Pick a category** (4 options):
| Option | Description | | ----------------------- | ------------------------------------------- | | Question assumptions | Probe what's being taken for granted | | Build counter-arguments | Argue the strongest opposing position | | Find weaknesses | Anticipate how this fails or gets exploited | | You choose | Auto-recommend based on context |
**Step 2b — Refine mode** (only when the category maps to 2 modes):
- "Question assumptions" → Ask: **Expose my assumptions** (Socratic) vs **Test the evidence** (Falsification)
- "Find weaknesses" → Ask: **Find failure modes** (Pre-mortem) vs **Attack this** (Red team)
- "Build counter-arguments" → Skip step 2b, proceed with Dialectic synthesis
- "You choose" → Skip step 2b, read `references/mode-selection-guide.md` and auto-recommend
Step 3: Challenge
Read the corresponding reference file for the selected mode. Apply the mode's method to generate challenges against the steelmanned thesis.
| Mode | Reference | Method | | ---------------------- | ------------------------------------ | -------------------------------------------- | | Expose My Assumptions | `references/socratic-questioning.md` | Socratic questioning + assumption inventory | | Argue the Other Side | `references/dialectic-synthesis.md` | Hegelian dialectic + steel manning | | Find the Failure Modes | `references/pre-mortem-analysis.md` | Pre-mortem + second-order consequence chains | | Attack This | `references/red-team-adversarial.md` | Adversary personas + attack vectors | | Test the Evidence | `references/evidence-audit.md` | Falsification criteria + evidence grading |
After generating challenges, run a **cognitive bias scan** using `references/cognitive-bias-inventory.md` to flag any biases present in the user's reasoning. Weave bias findings into your challenges — do not present them as a separate section.
Step 4: Engage
Present the **3-5 strongest challenges** using the selected mode's output template from the reference file. Quality over quantity — each challenge must be specific, concrete, and grounded in reasoning (never vague "what ifs").
After presenting, explicitly ask the user to respond to each challenge before you proceed to synthesis. Do not synthesize prematurely.
Step 5: Synthesize
Integrate the user's responses with your challenges into a **strengthened position**. The synthesis must:
1. Acknowledge challenges the user successfully defended 2. Incorporate valid objections into a refined position 3. Name explicit trade-offs that remain unresolved 4. Include a **confidence assessment**: HIGH / MEDIUM / LOW / PIVOT 5. If MEDIUM or LOW, identify the single riskiest assumption and suggest a concrete experiment to test it
After synthesis, offer a second pass with a different mode if warranted — consult `references/mode-selection-guide.md` for recommended multi-mode sequences.
Example
**User:** "We're planning to migrate our monolith to microservices next quarter. Challenge this."
**Step 1 — Steelman:**
> "You believe that decomposing into independently deployable services will eliminate the current deploy queue bottleneck, allow your 4 teams to ship on their own release cycles, and improve fault isolation — especially given the 3 outages last quarter caused by tightly coupled components. Is this a fair restatement?"
**Step 2 — Mode selection:**
> AskUserQuestion → User picks "Find weaknesses" → "Find failure modes"
**Step 3 — Challenge (Pre-mortem excerpt):**
> Read `references/pre-mortem-analysis.md`. Generate failure narratives: > > **Fa
The secure, validated skill registry for professional AI coding agents. Extend Antigravity, Claude Code, Cursor, Copilot and more with absolute confidence.
Repo: tech-leads-club/agent-skills
Other skills on tech-leads-club-agent-skills.
- /component-common-domain-detection
Finds duplicate business logic spread across multiple components and suggests consolidation. Use when asking "where is this logic duplicated?", "find common code between services", "what can be consolidated?", "detect shared domain logic", or analyzing component overlap before
Open skill - /component-flattening-analysis
Detects misplaced classes and fixes component hierarchy problems — finds code that should belong inside a component but sits at the root level. Use when asking "clean up component structure", "find orphaned classes", "fix module hierarchy", "flatten nested components", or
Open skill - /component-identification-sizing
Maps architectural components in a codebase and measures their size to identify what should be extracted first. Use when asking "how big is each module?", "what components do I have?", "which service is too large?", "analyze codebase structure", "size my monolith", or planning
Open skill - /coupling-analysis
Analyzes coupling between modules using the three-dimensional model (strength, distance, volatility) from "Balancing Coupling in Software Design". Use when asking "are these modules too coupled?", "show me dependencies", "analyze integration quality", "which modules should I
Open skill - /decomposition-planning-roadmap
Creates step-by-step decomposition plans and migration roadmaps for breaking apart monolithic applications. Use when asking "what order should I extract services?", "plan my migration", "create a decomposition roadmap", "prioritize what to split", "monolith to microservices
Open skill - /domain-analysis
Maps business domains and suggests service boundaries in any codebase using DDD Strategic Design. Use when asking "what are the domains in this codebase?", "where should I draw service boundaries?", "identify bounded contexts", "classify subdomains", "DDD analysis", or analyzing
Open skill

