The Fool

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.

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

Core Workflow

1. Identify — Extract the user's position from conversation context. Restate it as a steelmanned thesis for confirmation. 2. Select — Use AskUserQuestion with two-step mode selection (see below). 3. Challenge — Apply the selected mode's method. Load the corresponding reference file for deep guidance. 4. Engage — Present the 3-5 strongest challenges. Ask the user to respond before proceeding. 5. Synthesize — Integrate insights into a strengthened position. Offer a second pass with a different mode.

Mode Selection

Use AskUserQuestion to let the user choose how to challenge their idea.

Step 1 — Pick a category (4 options):

Step 2 — 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 2, proceed with Dialectic synthesis
• "You choose" → Skip step 2, load references/mode-selection-guide.md and auto-recommend

5 Reasoning Modes

Reference Guide

Constraints

MUST DO

• Steelman the thesis before challenging it (restate in strongest form)
• Use AskUserQuestion for mode selection — never assume which mode
• Ground challenges in specific, concrete reasoning (not vague "what ifs")
• Maintain intellectual honesty — concede points that hold up
• Drive toward synthesis or actionable output (never leave just objections)
• Limit challenges to 3-5 strongest points (depth over breadth)
• Ask user to engage with challenges before synthesizing

MUST NOT DO

• Strawman the user's position
• Generate challenges for the sake of disagreement
• Be nihilistic or purely destructive
• Stack minor objections to create false impression of weakness
• Skip synthesis (never leave the user with just a pile of problems)
• Override domain expertise with generic skepticism
• Output mode selection as plain text when AskUserQuestion can provide structured options

Output Templates

Each mode produces a structured deliverable. See the corresponding reference file for the full template.

After any mode, the final output must include:

1. Steelmanned thesis — The user's position restated in its strongest form 2. Challenges — 3-5 strongest points from the selected mode 3. User response — Space for the user to engage before synthesis 4. Synthesis — Strengthened position integrating the challenges 5. Next steps — Offer a second pass with a different mode if warranted

Knowledge Reference

Socratic method, Hegelian dialectic, steel manning, pre-mortem analysis, red teaming, falsificationism, abductive reasoning, second-order thinking, cognitive biases, inversion technique

Documentation

Dialectic Synthesis

Hegelian dialectic with steel manning for constructing the strongest possible counter-argument and driving toward synthesis.

Core Principle

The dialectic is not about winning. It is about producing a stronger position than either thesis or antithesis alone. The Fool's job is to argue the other side so well that the user is forced to either refine their position or acknowledge a genuine trade-off.

Process

1. Restate the thesis — Steelman the user's position first 2. Construct the antithesis — Build the strongest opposing argument 3. Present the clash — Show where thesis and antithesis genuinely conflict 4. Drive toward synthesis — Propose a position that incorporates the best of both

Steel Manning Technique

Steel manning is the opposite of straw manning. Restate the user's position in its strongest possible form before arguing against it.

How to Steelman

Steelman Checklist

• [ ] Have I made the position stronger, not weaker?
• [ ] Would the user recognize this as their view (or better)?
• [ ] Have I included the strongest evidence for their side?
• [ ] Am I attacking this version, not an easier one?

Antithesis Construction

Technique: Strongest Counter-Argument

Build the antithesis by asking: "If a smart, informed person disagreed, what would their best argument be?"

Reductio ad Absurdum (Supporting Technique)

Take the thesis to its logical extreme to reveal hidden limits.

Use sparingly. Reductio highlights the boundary of a principle, not its invalidity.

Synthesis Patterns

After presenting thesis and antithesis, propose a synthesis using one of these patterns.

1. Conditional Synthesis

"X is true when condition A holds; Y is true when condition B holds."

Example: "Microservices are right for the payment service (independent scaling, compliance boundary) but the admin dashboard should stay in the monolith (low traffic, fast iteration)."

2. Scope Partitioning

"Apply X to domain A and Y to domain B."

Example: "Use event sourcing for the audit trail (append-only, queryable history) but standard CRUD for user profiles (simple reads/writes)."

3. Temporal Synthesis

"Start with X, migrate to Y when trigger Z occurs."

Example: "Start with a monolith, extract services when team size exceeds 3 squads or deploy frequency hits weekly conflicts."

4. Risk Mitigation Synthesis

"Proceed with X but add safeguards from Y."

Example: "Adopt the new framework but keep the abstraction layer so we can swap back within 2 sprints."

5. Hybrid Extraction

"Take the strongest element from each side."

Example: "Use the microservices deployment model (independent containers) but keep a shared database with schema ownership (avoiding distributed data complexity)."

Confidence Assessment

Rate the synthesis outcome.

Anti-Patterns

Output Template

## Thesis (Steelmanned)

[User's position restated in strongest form]

**Strongest evidence for:** [1-2 supporting points]

## Antithesis

[Strongest counter-argument]

**Strongest evidence for:** [1-2 supporting points]

## Points of Genuine Conflict

| Dimension | Thesis Says | Antithesis Says |
|-----------|------------|-----------------|
| [e.g., Speed] | [Position] | [Counter-position] |
| [e.g., Cost] | [Position] | [Counter-position] |

## Proposed Synthesis

**Pattern:** [Conditional / Scope / Temporal / Risk Mitigation / Hybrid]

[Concrete synthesis proposal]

**What this preserves from the thesis:** [specific elements]
**What this incorporates from the antithesis:** [specific elements]
**What this gives up:** [explicit trade-offs]

**Confidence:** HIGH / MEDIUM / LOW / PIVOT
**If MEDIUM:** Test [riskiest assumption] by [experiment]

Evidence Audit

Falsificationism and evidence quality assessment for auditing whether claims are actually supported by evidence.

Core Principle

Karl Popper's key insight: a claim is only meaningful if you can specify what would disprove it. The Evidence Audit mode extracts claims from proposals, designs falsification criteria, assesses evidence quality, and surfaces competing explanations. The goal is not to disprove — it is to determine whether the evidence actually supports the conclusion.

Process

1. Extract claims — Identify the specific claims being made 2. Design falsification criteria — For each claim, specify what would disprove it 3. Assess evidence quality — Evaluate the evidence supporting each claim 4. Identify cognitive biases — Check for systematic errors in reasoning 5. Surface competing explanations — Find alternative explanations for the same evidence

Claim Extraction

Proposals contain claims — often implicit. Extract them before evaluating.

Types of Claims

Extraction Method

For each statement in the proposal: 1. Is this a claim or a definition? 2. If a claim, what type? 3. What evidence is cited (or implied)? 4. What would make this claim false?

Example Extraction

Statement: "Based on our pilot, migrating to Kubernetes will reduce deployment time by 60%."

Claims extracted:
1. The pilot results are representative of production (Predictive)
2. Kubernetes is the cause of the deployment time reduction (Causal)
3. The 60% reduction will persist at scale (Quantitative)

Falsification Criteria

For each claim, design a test that would disprove it.

Unfalsifiable Claims (Red Flag)

Some claims cannot be falsified. These are red flags.

When you encounter unfalsifiable claims, ask: "What specific, measurable outcome would tell us this worked or didn't work?"

Evidence Quality Assessment

Not all evidence is equal. Assess each piece of evidence on these dimensions.

Evidence Quality Matrix

Evidence Grading Scale

Common Weak Evidence Patterns

Cognitive Bias Awareness

Check for these biases in the reasoning chain.

Competing Explanations (Abductive Reasoning)

For every conclusion, ask: "What else could explain this evidence?"

Method

1. State the evidence 2. State the proposed explanation 3. Generate 2-3 alternative explanations 4. Compare explanatory power

Example

Evidence: "Deployment failures dropped 50% after adopting tool X."

Proposed explanation: Tool X is better than the old tool.

Alternative explanations:
1. The team also started doing more code review in the same period
2. A particularly error-prone service was retired last month
3. The team gained experience that would have improved results with any tool

Output Template

## Evidence Audit: [Proposal/Decision]

### Claims Extracted

| # | Claim | Type | Evidence Cited |
|---|-------|------|---------------|
| 1 | [Specific claim] | Causal/Predictive/etc. | [What evidence supports it] |
| 2 | [Specific claim] | Causal/Predictive/etc. | [What evidence supports it] |
| 3 | [Specific claim] | Causal/Predictive/etc. | [What evidence supports it] |

### Falsification Criteria

| Claim | What Would Disprove It | How to Test |
|-------|----------------------|-------------|
| #1 | [Specific criterion] | [Concrete test] |
| #2 | [Specific criterion] | [Concrete test] |

### Evidence Quality

| Claim | Evidence Grade | Key Weakness |
|-------|--------------|--------------|
| #1 | A/B/C/D/F | [Primary concern] |
| #2 | A/B/C/D/F | [Primary concern] |

### Bias Check

| Bias Detected | Where | Impact |
|--------------|-------|--------|
| [Bias name] | Claim #X | [How it affects the conclusion] |

### Competing Explanations

| Evidence | Proposed Explanation | Alternative Explanations |
|----------|---------------------|------------------------|
| [Data point] | [Original claim] | 1. [Alternative] 2. [Alternative] |

### Verdict

**Overall evidence strength:** Strong / Moderate / Weak / Insufficient

**Recommendations:**
1. [Specific action to strengthen the weakest claim]
2. [Specific action to test the riskiest assumption]

Mode Selection Guide

How to recommend the right reasoning mode when the user selects "You choose" or when auto-recommending.

Signal-to-Mode Mapping

Analyze the user's language and context to identify which mode fits best.

Decision Type Mapping

Domain Mapping

Multi-Mode Sequencing

Some situations benefit from running 2 modes in sequence.

Recommended Sequences

When to Suggest Multi-Mode

Recommend a second pass when:

• The first mode reveals a category of risk the user hadn't considered
• The thesis survives the first challenge largely intact (it may need harder testing)
• The domain spans two mapping categories (e.g., a security architecture decision)

When NOT to Suggest Multi-Mode

• The user's question is narrow and specific
• The first mode already surfaced actionable changes
• The user signals they want to move on

Auto-Recommendation Format

When presenting the recommendation, use this structure:

Based on [specific context signal], I recommend **[Mode Name]** because [1-sentence rationale].

[If a secondary mode is relevant:]
After that, a follow-up with **[Secondary Mode]** would [1-sentence benefit].

Then confirm with AskUserQuestion:

• Option 1: Recommended mode (with "(Recommended)" label)
• Option 2: Secondary mode if applicable
• Option 3: "Let me pick" — return to the full mode selection

Edge Cases

• Vague context: Default to Socratic Questioning — it surfaces what matters
• Multiple concerns: Recommend Pre-mortem Analysis — it covers breadth naturally
• User is emotional/frustrated: Default to Dialectic Synthesis — steel manning validates their position before challenging it
• Technical vs business split: Match the mode to which side the user emphasizes

Pre-Mortem Analysis

Pre-mortem methodology with second-order thinking for identifying how plans fail before they fail.

Core Principle

A pre-mortem inverts the question. Instead of "Will this work?" ask: "It's 6 months from now and this has failed. Why?" This psychological shift bypasses optimism bias by making failure the starting point, not the thing to be argued against.

Process

1. Set the scene — "Imagine it's [timeframe] from now. This plan has failed. Not a small setback — a clear failure." 2. Generate failure narratives — Write specific stories about how it failed 3. Rank by likelihood and impact — Not all failures are equal 4. Trace consequence chains — First → second → third order effects 5. Identify early warning signs — What would you see before the failure? 6. Design mitigations — Concrete actions, not vague "be careful"

Failure Narrative Construction

Failure narratives must be specific. "It didn't scale" is not a narrative. "At 50K concurrent users, the database connection pool exhausted, causing cascading timeouts across all services, which triggered the circuit breaker to reject all requests for 4 minutes during peak hours" is a narrative.

Specificity Checklist

• [ ] Names a specific trigger (not "something goes wrong")
• [ ] Includes a number or threshold
• [ ] Describes the chain of events, not just the end state
• [ ] Identifies who or what is affected
• [ ] Could actually happen (not a fantasy scenario)

Failure Narrative Template

**Failure: [Title]**

It's [timeframe] from now. [Specific trigger event]. This caused [first-order effect],
which led to [second-order effect]. The team discovered the problem when [detection point],
but by then [consequence]. The root cause was [underlying assumption that proved wrong].

Example

**Failure: Migration Data Loss**

It's 3 months from now. During the database migration from PostgreSQL to the new schema,
a batch job silently drops records where the `legacy_id` field contains special characters
(~2% of records). The team discovers the problem 2 weeks post-migration when a customer
reports missing order history. By then, the legacy database has been decommissioned and
backups have rotated past the migration date. The root cause was that the migration script
was tested against a sanitized staging dataset that didn't include special characters.

Second-Order Consequence Chains

Every failure has consequences beyond the immediate impact. Trace at least two orders deep.

Chain Template

Trigger: [event]
  → 1st order: [immediate effect]
    → 2nd order: [consequence of the 1st order effect]
      → 3rd order: [consequence of the 2nd order effect]

Example Chain

Trigger: Key engineer leaves during migration
  → 1st order: Migration timeline slips 4 weeks
    → 2nd order: Overlap period with legacy system extends, doubling operational cost
      → 3rd order: Budget overrun triggers executive review, project gets descoped

Common Second-Order Patterns

Inversion Technique

Ask: "What would guarantee this fails?" Then check if any of those conditions exist.

Guaranteed Failure Conditions

Domain-Specific Failure Patterns

Technical Failures

Business Failures

Process Failures

Early Warning Signs

Output Template

## Pre-Mortem: [Plan/Decision Name]

**Timeframe:** [When would failure be evident]

### Failure Narratives

#### 1. [Failure Title] — Likelihood: High/Medium/Low | Impact: High/Medium/Low

[Specific failure narrative using the template above]

**Consequence chain:**
- 1st order: [immediate]
- 2nd order: [downstream]
- 3rd order: [systemic]

#### 2. [Failure Title] — Likelihood: High/Medium/Low | Impact: High/Medium/Low

[Narrative]

#### 3. [Failure Title] — Likelihood: High/Medium/Low | Impact: High/Medium/Low

[Narrative]

### Early Warning Signs

| Signal | Failure It Predicts | Check Frequency |
|--------|-------------------|-----------------|
| [Observable signal] | Failure #X | Weekly / Sprint / Monthly |

### Mitigations

| Failure | Mitigation | Effort | Reduces Risk By |
|---------|-----------|--------|-----------------|
| #1 | [Specific action] | Low/Med/High | [How much] |
| #2 | [Specific action] | Low/Med/High | [How much] |
| #3 | [Specific action] | Low/Med/High | [How much] |

### Inversion Check

**What would guarantee failure:** [List top 3 conditions]
**Do any exist now?** [Yes/No with specifics]

Red Team Adversarial

Adversarial thinking and red teaming for finding weaknesses before adversaries do.

Core Principle

Red teaming asks: "If someone wanted to break, exploit, or game this, how would they do it?" The Fool adopts the mindset of an adversary — not to cause harm, but to find vulnerabilities before real adversaries do. This applies beyond security: competitors, disgruntled users, perverse incentives, and regulatory challenges are all adversarial forces.

Process

1. Identify the asset — What are you protecting? (system, decision, strategy, product) 2. Construct adversary personas — Who would attack this and why? 3. Map attack vectors — How would each persona exploit weaknesses? 4. Assess impact — Rank by likelihood x impact 5. Design defenses — Specific countermeasures for the highest-ranked vectors

Adversary Persona Construction

Generic "attackers" produce generic findings. Specific personas produce actionable insights.

Persona Template

Common Adversary Personas

Domain-Specific Personas

Attack Vector Identification

By Category

Attack Tree Construction

For complex systems, build attack trees to map paths to a goal.

Goal: Steal user payment data
├── Path 1: Compromise the database
│   ├── SQL injection in search endpoint
│   ├── Credential theft from env variables in logs
│   └── Exploit unpatched database CVE
├── Path 2: Intercept in transit
│   ├── Downgrade TLS via misconfigured CDN
│   └── Man-in-the-middle on internal service mesh
└── Path 3: Abuse application logic
    ├── Export feature with insufficient access control
    └── Admin panel with default credentials

Perverse Incentive Detection

Systems create incentives. Sometimes those incentives reward the wrong behavior.

Questions to Surface Perverse Incentives

Common Perverse Incentive Patterns

Competitive Response Analysis

When the "adversary" is a competitor.

Output Template

## Red Team Analysis: [Target]

### Asset Under Assessment

[What we're protecting and why it matters]

### Adversary Profiles

#### Adversary 1: [Name/Role]
- **Motivation:** [Why they attack]
- **Capability:** [What they can do]
- **Access:** [What they start with]

#### Adversary 2: [Name/Role]
- **Motivation:** [Why they attack]
- **Capability:** [What they can do]
- **Access:** [What they start with]

### Attack Vectors (Ranked)

| # | Vector | Adversary | Likelihood | Impact | Risk Score |
|---|--------|-----------|-----------|--------|------------|
| 1 | [Specific attack] | [Who] | High/Med/Low | High/Med/Low | [L x I] |
| 2 | [Specific attack] | [Who] | High/Med/Low | High/Med/Low | [L x I] |
| 3 | [Specific attack] | [Who] | High/Med/Low | High/Med/Low | [L x I] |

### Perverse Incentives

| Incentive Created | Unintended Behavior | Severity |
|-------------------|-------------------|----------|
| [What the system rewards] | [How it gets gamed] | High/Med/Low |

### Recommended Defenses

| Attack Vector | Defense | Effort | Priority |
|--------------|---------|--------|----------|
| #1 | [Specific countermeasure] | Low/Med/High | Immediate/Next sprint/Backlog |
| #2 | [Specific countermeasure] | Low/Med/High | Immediate/Next sprint/Backlog |
| #3 | [Specific countermeasure] | Low/Med/High | Immediate/Next sprint/Backlog |

Socratic Questioning

Structured question frameworks for exposing assumptions and deepening understanding.

Core Principle

Socratic questioning does not argue. It asks. The goal is to help the user discover gaps in their own reasoning by surfacing what they have not examined. Every question should create a moment of "I hadn't thought about that."

Question Categories

1. Definitional Questions

Challenge vague or overloaded terms.

2. Evidential Questions

Probe the basis for beliefs.

3. Logical Questions

Test the reasoning chain.

4. Perspective-Shifting Questions

Force consideration of other viewpoints.

5. Consequential Questions

Trace the implications.

Assumption Detection Signals

Watch for language that hides assumptions.

Domain-Adapted Question Banks

Technical Decisions

• What are you optimizing for? Are you sure that's the right dimension?
• What's the simplest version that tests the core assumption?
• What constraint are you treating as fixed that might actually be flexible?
• How would you build this if you had to ship in one week?
• What's the most expensive thing to change later?

Business Decisions

• Who is the customer for this decision? Are you sure?
• What would make this a bad investment in hindsight?
• How does this compare to doing nothing?
• What's the opportunity cost of this choice?
• If a competitor made the opposite choice, would you be worried?

Strategic Decisions

• What has to be true for this strategy to work?
• Which of those assumptions are you least confident about?
• What's the fastest way to test the riskiest assumption?
• How will you know if this is failing before it's too late?
• What's the exit strategy if this doesn't work?

Output Template

## Assumption Inventory

| # | Assumption | Type | Confidence |
|---|-----------|------|------------|
| 1 | [Stated or hidden assumption] | Stated / Unstated | High / Medium / Low |

## Probing Questions

### [Theme 1: e.g., "User Behavior"]
1. [Question targeting assumption #X]
2. [Follow-up question deepening the probe]

### [Theme 2: e.g., "Technical Feasibility"]
1. [Question targeting assumption #Y]
2. [Follow-up question]

### [Theme 3: e.g., "Business Viability"]
1. [Question targeting assumption #Z]
2. [Follow-up question]

## Suggested Experiments

| Assumption | Experiment | Effort | Signal |
|-----------|-----------|--------|--------|
| [Riskiest assumption] | [How to test it] | Low/Med/High | [What result means] |