risk-list-discipline — quality + safety report

---
name: risk-list-discipline
description: Force a written pre-launch risk list before every consequential ship, deploy, or launch — and a post-mortem cross-check of what actually killed it against what you predicted would kill it. Use this skill aggressively when the user is doing a pre-mortem, a launch checklist, a deploy readiness review, a go/no-go call, a post-mortem, a root-cause analysis, or saying "what could go wrong", "what's our biggest risk", "I think we've covered everything", "what would cause this to fail", "post-mortem", "why did it blow up", "we didn't see this coming", "unknown unknowns", "let's not let this happen again", or any moment a team is about to launch something hard without first enumerating predicted failure modes on paper. Also fires when a post-mortem skips the cross-check against the original risk list, or when a team has no risk list at all. The point is not to eliminate risk — it is to measure how blind you were. Trigger eagerly even when the user does not name Musk or the framework.
---

# Risk List Discipline

> "Before every Starship launch, we go through the list of risks we predict, which we call the 'risk list.' If you look at various reasons why we blew up, none of the reasons they blew up were on our 'risk list.'"
> — Elon Musk, *The Book of Elon* (Chapter: You Have to Blow Things Up (risk-list subsection))

## What this skill captures

Before SpaceX flies a Starship, they write down — explicitly, on paper — every failure mode they predict. They call it the "risk list." Then when the rocket blows up (and early ones do), they cross-check the real cause against the list. The point is not that the list prevents failure. The point is the gap. Musk: *"none of the reasons they blew up were on our 'risk list.'"* That gap is the measurement of your unknown unknowns — *"There's a crazy amount of new technology, all evolving simultaneously. We need time and trials to iron out the unknown unknowns."*

This skill forces the user to (a) produce a written, enumerated risk list before they ship something hard, and (b) on every post-mortem, explicitly compare what killed it against what they predicted would kill it. The value is calibration: you stop pretending you knew what could go wrong, and you start measuring how blind you actually were.

## When to use this skill

- The user is about to launch, deploy, ship, or release something where failure is recoverable but expensive.
- The user is running a pre-mortem or asking "what could go wrong?"
- The user is writing a launch checklist, readiness review, or go/no-go doc.
- The user is doing a post-mortem and has not cross-referenced the failure against a prior risk prediction.
- The user says "we didn't see this coming" or "unknown unknowns."
- The user is iterating fast on new tech and has no written record of predicted failure modes per attempt.

## The how-to

1. **Write the risk list down. On paper. Before you ship.** Not a vibe, not a Slack thread — an enumerated document, named and dated per attempt.
   > "Before every Starship launch, we go through the list of risks we predict, which we call the 'risk list.'"
   > — *The Book of Elon*
   If it isn't written, you can't cross-check it later. The list itself is the instrument; without it you have no calibration data.

2. **Enumerate predicted failure modes specifically, not generically.** "Engine fails" is not a risk item. "Raptor 7 turbopump LOX-side bearing seizes above 90% thrust" is. Vagueness is how you accidentally claim you predicted everything.
   > "There's a crazy amount of new technology, all evolving simultaneously."
   > — *The Book of Elon*
   The more novel the system, the more specific each item has to be — because the novelty is exactly where the unknown unknowns live.

3. **Ship anyway. Do not use the list to justify another delay.** The list is a measurement instrument, not a gate. You are not designing to eliminate every risk — you are establishing a baseline to learn against.
   > "We don't want to design to eliminate every risk. Otherwise, we will never get anywhere."
   > — *The Book of Elon*
   If the risk list keeps growing and the launch keeps slipping, you have stopped iterating and started procrastinating.

4. **After it blows up (or doesn't), cross-check every actual failure cause against the list.** For each thing that went wrong, mark: *on the list* or *not on the list*. The "not on the list" column is the only number that matters.
   > "If you look at various reasons why we blew up, none of the reasons they blew up were on our 'risk list.'"
   > — *The Book of Elon*
   That gap is your unknown-unknowns rate. Track it across attempts. If it isn't dropping, you aren't learning.

5. **Add the new failure modes to the next list — and resist the urge to backfill.** Do not edit the old list to make yourself look prescient. The old list is data; tampering with it destroys the calibration.
   > "We need time and trials to iron out the unknown unknowns."
   > — *The Book of Elon*
   Trials only work as data if you preserve the prior prediction honestly.

6. **For each post-mortem, end with one explicit sentence: "On the risk list: X. Not on the risk list: Y."** That sentence is the deliverable. Everything else in the post-mortem is supporting material.

## Common failure modes

- **No written list.** "We talked about the risks in standup" is not a risk list. You cannot cross-check a conversation.
- **Risk theater.** A 200-item list of generic phrases ("software bug", "hardware failure", "human error") so you can always claim it was on the list. This destroys the measurement.
- **Backfilling after failure.** Editing the list post-hoc to include the actual cause. Now you have no calibration data and a lie in the file.
- **Using the list as a launch gate.** Treating every item as a blocker until mitigated. Musk: *"We don't want to design to eliminate every risk. Otherwise, we will never get anywhere."* The list measures blindness; it does not authorize delay.
- **Skipping the cross-check.** Doing the pre-mortem, shipping, blowing up, writing a post-mortem — and never going back to ask "was this on the list?" Without the cross-check the list was wasted paper.

## When NOT to use this skill

- **Crewed / catastrophic / irreversible systems.** Musk explicitly carves these out: *"Since Dragon now carries crew, there can be no failures, ever."* For human-aboard, safety-critical, or unrecoverable systems, you are in elimination mode, not measurement mode. Use a hazard analysis (FMEA, HAZOP), not a learn-by-blowing-up risk list.
- **Mature, well-understood systems with low novelty.** If almost nothing is new, the unknown-unknowns rate is low and the risk list mostly just restates the runbook. Spend the time elsewhere.
- **Trivial-blast-radius changes.** A config tweak behind a feature flag does not need a written risk list. Reserve the ritual for things where failure actually teaches.
- **When the user wants the broader iterate-by-blowing-up philosophy** (use `you-have-to-blow-things-up`) or **incentive-structure design around risk-taking** (use `risk-reward-asymmetry-design`). This skill is narrowly the pre-launch document and its post-mortem cross-check.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "You Have to Blow Things Up (risk-list subsection)" (in "Building SpaceX").