Foolish Framing — Stress-Test Claims Through Uninformed Objections

# Foolish Framing — Stress-Test Claims Through Uninformed Objections

The opposite of adversarial framing. Instead of constructing intelligent counterarguments, simulate the kind of objections that come from someone who hasn't used the system, doesn't understand the concepts, and says things that are illogical but leave you thinking. The purpose is not to defeat the objections with logic — they aren't rooted in logic. The purpose is to force yourself to articulate what you know at a level simple enough that no ambiguity survives.

## Arguments

`<claim or system to stress-test>` — What should be defended against foolish questions.

Examples:
- `/foolish-framing Claude Code OS is an operating system`
- `/foolish-framing remote control is a killer feature`
- `/foolish-framing the power law distribution proves Unix philosophy`

## Reference Document

Read `reference-documents/foolish_framing.pdf` before running this skill. It contains a complete sparring session demonstrating the technique — five rounds of foolish objections about Claude Code OS with defenses from both the user and Claude Code.

## How It Differs from Adversarial Framing

| | Adversarial Framing | Foolish Framing |
|---|---|---|
| **Objector** | Intelligent, informed, constructs the strongest possible case | Uninformed, illogical, says things that sound dumb but stick |
| **Objections** | Precise, structural, targets real weaknesses | Vague, surface-level, often based on false equivalences |
| **Goal** | Find where the claim actually breaks | Force the defender to articulate their understanding simply |
| **Outcome** | The claim either survives or doesn't | The defender's clarity improves regardless |
| **Tone** | Rigorous, respectful | Frustrating, sometimes absurd |

## Workflow

### Step 1: Understand the Claim

Read what the user wants to defend. Understand the system, the naming, the framing — whatever is being claimed.

### Step 2: Generate Foolish Objections

Create 3-5 objections that an uninformed person would actually say. These should be:

- **Surface-level** — based on what things look like, not how they work ("it's just scripts," "I can SSH too")
- **False equivalences** — equating fundamentally different things ("Perplexity Computer also controls the computer, so it's the same")
- **Dismissive of nuance** — refusing to see the difference between a shortcut and a system ("bash aliases do the same thing")
- **Appeal to personal preference as universal** — ("I don't want to work from my phone, so remote control is pointless")
- **Outdated framing** — ("that paper is from 1970, computing has changed")

### Step 3: Spar

Present each objection one at a time. Let the user respond. After each response:

- Acknowledge what was strong in the defense
- Note if there's a gap or ambiguity
- Move to the next objection, making it harder

If the user struggles, offer a defense yourself — but frame it as a collaborative answer, not a correction.

### Step 4: Synthesize

After all rounds, summarize:
- Which defenses were strongest
- Which areas still have ambiguity
- What the sparring revealed about the user's understanding
- One sentence that captures the core defense — the simplest possible articulation

## Rules

1. **The objections must sound genuinely foolish** — not intelligent devil's advocacy. Think of someone who uses ChatGPT once and thinks they understand AI.
2. **Don't strawman.** Foolish doesn't mean fake. These are objections real people actually make.
3. **The user's response matters more than the objection.** The skill is about building the user's clarity, not about the quality of the attack.
4. **Multilingual is fine.** If the user or the objector speaks in Hindi, Spanish, or any other language, respond in kind. Real foolish questions come in every language.
5. **End with clarity, not victory.** The goal is not "I won the argument." The goal is "I now understand my system well enough to explain it to anyone."