Skip to main content
ClaudeWave
Skill4.6k repo starsupdated yesterday

the-fool

The Fool skill applies structured critical reasoning across five analytical frameworks, Socratic questioning, falsificationism, pre-mortem analysis, red teaming, and dialectical synthesis, to stress-test ideas, plans, decisions, and proposals before commitment. Use it when challenging an approach's viability, auditing evidence quality, uncovering blind spots and hidden assumptions, or running a devil's advocate exercise; do not use it for generating solutions, building plans, or making final decisions.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/tech-leads-club/agent-skills /tmp/the-fool && cp -r /tmp/the-fool/packages/skills-catalog/skills/(decision-making)/the-fool ~/.claude/skills/the-fool
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# 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:
>
> **Failure 1: Migration Halfway House** — It's 6 months from now. 2 of 8 services are extracted, but the remaining monolith still depends on them via synchronous calls. Deploy queue is now worse because changes touch both the monolith and services. Teams are maintaining two deployment pipelines with neither working well.
>
> **Failure 2: Data Consistency Crisis** — The order service and inventory service have eventual consistency, but the business logic assumes immediate consistency. A flash sale creates 200 oversold orders in 4 minu
component-common-domain-detectionSkill

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 refactoring. Do NOT use for code-level duplication detection (use linters) or dependency analysis (use coupling-analysis).

component-flattening-analysisSkill

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 analyzing why namespaces have misplaced code. Do NOT use for dependency analysis (use coupling-analysis) or domain grouping (use domain-identification-grouping).

component-identification-sizingSkill

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 where to start decomposing. Do NOT use for runtime performance sizing or infrastructure capacity planning.

coupling-analysisSkill

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 decouple?", "coupling report", or evaluating architectural health. Do NOT use for domain boundary analysis (use domain-analysis) or component sizing (use component-identification-sizing).

decomposition-planning-roadmapSkill

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 strategy", or tracking decomposition progress. Do NOT use for domain analysis (use domain-analysis) or component sizing (use component-identification-sizing).

domain-analysisSkill

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 domain cohesion. Do NOT use for grouping existing components into domains (use domain-identification-grouping) or dependency analysis (use coupling-analysis).

domain-identification-groupingSkill

Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).

frontend-blueprintSkill

AI frontend specialist and design consultant that guides users through a structured discovery process before generating any code. Collects visual references, design tokens, typography, icons, layout preferences, and brand guidelines to ensure the final output matches the user's vision with high fidelity. Use when the user asks to build, design, create, or improve any frontend interface — websites, landing pages, dashboards, components, apps, emails, forms, modals, or any UI element. Also triggers on "build me a UI", "design a page", "create a component", "improve this layout", "make this look better", "frontend", "interface", "redesign", or when the user provides mockups, screenshots, or design references. Do NOT use for backend logic, API design, database schemas, or non-visual code tasks.