break-down-the-impossible — quality + safety report

---
name: break-down-the-impossible
description: Decompose any "impossible" goal into its physical constituent elements until each piece is individually solvable. Use this skill whenever the user is doing moonshot planning, hard goals, founder pitches, ambitious targets, evaluating crazy ideas, or saying "this is impossible because…", "the timeline is insane", "we don't have the resources", "no one has ever done this", "it would take years", "we'd need to invent X", or "the experts say it's not feasible". Also trigger on roadmap reviews where deadlines are being pushed out because something seems blocked, on architecture debates where a constraint is being treated as a wall, and on any pitch where you smell argument-from-authority instead of argument-from-physics. The skill forces a first-principles decomposition: what does this literally require — building, power, cooling, networking, atoms, joules, dollars, people, days — and then attacks each constituent. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - do-things-in-parallel
  - set-aggressive-timelines
  - timeline-is-wrong-if-long
  - speed-is-both-offense-and-defense
---

# Break Down the "Impossible"

> "Often, we were told something was impossible, but once we broke it down into its constituent elements, we could solve those."
> — Elon Musk, *The Book of Elon* (Chapter: Break Down the "Impossible")

## What this skill captures

"Impossible" is almost always a compound claim hiding behind a single word. Break it apart and you get a list of concrete sub-problems, most of which turn out to be merely hard, expensive, or annoying — not impossible. The Colossus story is the canonical instance: xAI was told 100,000 H100s in a training cluster would take 18-24 months. They needed 6. So they decomposed the goal into building + power + cooling + networking + power-smoothing, attacked each (used Memphis factory, rented generators, rented a quarter of US mobile chillers, added Tesla Megapacks for sub-100ms power variation, ran 24/7 four-shift cabling). 122 days to first light. Doubled in 92 more.

The principle generalizes: software, hardware, distribution, regulation, hiring, fundraising.

## When to use this skill

- The user (or someone they're pitching to) said "impossible", "infeasible", "not in that timeframe", "we'd have to invent X first"
- A timeline is being padded because a single sub-problem is unsolved
- An expert estimate is being accepted without decomposition
- A moonshot, founder pitch, OKR, or roadmap looks audacious and you're tempted to nod politely
- You catch yourself or the user reasoning by analogy ("nobody has done X before") instead of by physics/economics
- Evaluating a crazy idea where the right question is "what would it actually take?"

## The how-to

1. **Restate the goal in physical/economic terms.** Strip the verbs that hide complexity ("scale", "deliver", "build a platform"). What atoms move? What joules are needed? What dollars, what people-hours, what bits transferred? If you can't restate it physically, the goal is still vapor.

2. **List the constituent elements.** Force a flat list of the literal things required.
   > "We need a building; we need power; we need cooling."
   > — *The Book of Elon* (Break Down the "Impossible")
   No level of abstraction higher than that. Aim for 5-15 items.

3. **For each element, find the current ceiling and the required level.** Quantify the gap.
   > "The input power was 15 megawatts and we needed 150 megawatts."
   > — *The Book of Elon*
   Numbers. Not "more power". Numbers.

4. **For each gap, ask: rent, buy, build, modify, or route-around?** Most "impossible" elements have a rental market or an unused asset somewhere.
   > "We found a factory in Memphis that was no longer in use… we rented generators… we rented about a quarter of the mobile cooling capacity of the US."
   > — *The Book of Elon*
   Renting an existing thing collapses months into days.

5. **Identify the second-order failure modes the naive decomposition missed.** The first pass solves the static problem; reality has dynamics.
   > "Power can drop by 50 percent in 100 milliseconds, which the generators can't keep up with. So then we added Tesla megapacks and modified the software in the megapacks to smooth out the power variation."
   > — *The Book of Elon*
   Ask: what happens under load, under failure, under burst, under adversary?

6. **Parallelize the remaining gestation periods.** Once each element is individually solvable, the question is calendar time. Run them in parallel, in shifts if needed.
   > "We ran the networking team to do the cabling in four shifts, 24/7. I was sleeping in the data center and doing cabling myself."
   > — *The Book of Elon*

7. **Restate the new estimate and the binding constraint.** After decomposition, you should be able to say: "It will take N days, and the bottleneck is element X."

## Common failure modes

- **Stopping at one level of abstraction.** "We need infrastructure" is not a constituent element. "We need 150 MW of input power and 100,000 GPU-equivalents of mobile chiller capacity" is.
- **Accepting the supplier estimate.** The 18-24 month quote was an aggregate from people optimizing their own queues, not a physical lower bound.
- **Confusing "nobody has done this" with "this violates physics".** Only the second is a real wall.
- **Decomposing only the technical elements and ignoring regulatory / human / capital constituents.** Permitting, hiring, financing are constituent elements too.
- **Skipping step 5.** First-pass decompositions miss dynamics (power variance, thermal transients, contention, rate limits).
- **Decomposing without then committing to aggressive parallel execution.** A clean decomposition with a serialized timeline is just a prettier excuse.

## When NOT to use this skill

- The constraint genuinely is physics (lightspeed, thermodynamics, information-theoretic lower bounds). Decompose to confirm, then stop.
- The user is venting, not planning. Ask first.
- The "impossible" claim is about ethics, legality, or trust — those don't yield to first-principles engineering.
- Small, well-understood tasks where decomposition is just ceremony. Reserve this for goals that are at least 3x outside the consensus envelope.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Break Down the 'Impossible'" (in "Maniacal Urgency"). Primary source pages 146-148.