musk-5-step — quality + safety report

---
name: musk-5-step
description: Apply Elon Musk's 5-step engineering/design algorithm — (1) make requirements less dumb, (2) delete the part or process, (3) simplify or optimize, (4) accelerate cycle time, (5) automate — to plan new things or audit existing ones (projects, designs, processes, proposals, codebases, workflows, org structures). Use this skill when the user asks to plan, design, audit, critique, review, evaluate, simplify, optimize, streamline, de-risk, or rethink something — especially if they mention "first principles", "Musk", "5-step", "5 step", "the algorithm", "delete", "simplify", "cut waste", "what should I cut", "is this overengineered", or want a sharp contrarian review rather than a generic checklist. Trigger eagerly even if the user does not name the framework; if their request is "should we build X this way?", "review my plan", "what's missing here?", or similar, this skill applies.
---

# Musk's 5-Step Algorithm — for planning and evaluating

## What this is

A thinking tool, not a template. The user wants to either **plan** something new or **evaluate** something existing through Elon Musk's 5-step "algorithm" (his term, from the 2021 Everyday Astronaut interview at Starbase). The steps are:

1. **Make the requirements less dumb**
2. **Delete the part or process**
3. **Simplify or optimize** what remains
4. **Accelerate cycle time**
5. **Automate**

**The order matters more than the steps themselves.** Musk's stated lesson is that almost every failure he's witnessed came from doing these in the wrong order — optimizing something that should have been deleted, automating a broken process, accelerating a doomed direction. So the job here is not to dutifully list five bullets; it is to *force the order*, and to refuse to advance until earlier steps have done their work.

This skill works for almost anything that has parts and processes: a product, a system, a service, a meeting, an org chart, a deployment pipeline, a codebase, a contract, a workflow, a startup plan.

## Step 0 — Choose mode and gather the subject

When this skill triggers, do this first, in one short turn:

1. **Identify the subject.** What concrete thing are we operating on? A plan? A running process? A draft document? An existing system? Get one sentence describing it.
2. **Identify the goal.** Why does the user care? Cost? Speed? Reliability? Clarity? Strategic fit? Without a goal, every "delete" or "simplify" suggestion is unmoored.
3. **Pick a mode.** If the user has already signaled a preference, use it. Otherwise ask once:
   - **Socratic mode** — walk one step at a time, ask the user sharp questions per step, wait for answers, then move on. Slower; produces real thinking. Best for things the user owns and is mid-decision on.
   - **One-shot mode** — take everything the user has provided and produce a full 5-step report in a single response. Faster; best for evaluating something already documented, or when the user wants a critique to react to.

Default to Socratic if the subject is a *plan in progress* and to one-shot if the subject is an *existing artifact being evaluated*. Always tell the user which you picked and let them flip.

## The five steps — what each one actually demands

These descriptions are for *you*, the model running the skill. They are not the script you read to the user. Read them, internalize them, then apply them in whichever mode is active.

### 1. Make the requirements less dumb

> "Your requirements are definitely dumb. It does not matter who gave them to you. It is particularly dangerous if a smart person gave you the requirements, because you may not question them enough." — Musk

The mistake to avoid: treating the brief as fixed and optimizing inside it. The real lever is usually in the brief itself.

What to do:
- Enumerate the *stated* requirements. Force the user to list them, or extract them from the artifact.
- For each requirement, attach **a person's name**, not a department. "Marketing said" is unfalsifiable. "Alex on 2025-09-03 said X because Y" is debuggable.
- For each, ask: *Why this exactly? What goes wrong if it's 50% looser? Or removed?* Many requirements are inherited from a constraint that no longer applies.
- Surface the **invisible requirements** — assumptions nobody wrote down. ("Must work in a browser." "Must integrate with our current CRM." "Must use the existing team.") These are often the dumbest ones, because nobody examines them.
- Distinguish **physics-level constraints** (truly immovable: thermodynamics, regulation, contractual obligation, signed customer commitments) from **convention-level constraints** (everything else). Most "requirements" are convention.

Output of this step: a tightened list of requirements where each survivor has a named owner and a defensible reason, and where 1-3 prior requirements have been challenged or removed.

### 2. Delete the part or process

> "If you're not occasionally adding things back in, you're deleting not enough." — Musk

This is the step engineers and product people skip. It feels destructive. Push through that.

What to do:
- List the **parts** (components, features, services, line items, sections, meetings, steps, fields, roles) the thing has.
- For each, propose deletion. The default question is not "should we keep this?" but "what breaks if it's gone?"
- A part survives only if removing it causes a *specific, named* failure tied to a *surviving requirement* from step 1. Generic answers like "we might need it later" or "users might want it" do not count.
- Apply Musk's calibration test: if you are not, in the course of this exercise, deleting something that you later have to add back, you are not cutting hard enough. Tell the user this explicitly. Expect over-cutting; you will repair it in later steps.
- Be specific about *what* gets deleted. "Simplify the dashboard" is not a deletion. "Delete the secondary nav, the export menu, and the per-row action column" is.

Output of this step: a list of specific deletions, with the named failure mode that would justify keeping each item.

### 3. Simplify or optimize what remains

Only the survivors of step 2 get this treatment. Otherwise you are polishing things that should not exist — Musk's most-cited error.

What to do:
- For each remaining part/process, ask: is there a simpler implementation that meets the (now-tightened) requirements? Fewer states, fewer dependencies, fewer code paths, fewer approvers, fewer special cases.
- Look for **combinations** — two parts that can collapse into one. Two meetings, two roles, two services, two database tables.
- Look for **standardization** — bespoke things that could use an off-the-shelf or already-existing component.
- Resist re-architecting for elegance. Simpler ≠ prettier. Simpler = fewer moving pieces.

Output: a concrete simplification proposal per surviving part.

### 4. Accelerate cycle time

Now — and only now — speed up the loop. Speeding up a doomed or bloated process is waste.

What to do:
- Identify the **cycle**. What's the unit of iteration? A release? A user test? A weekly review? A build? A decision?
- Measure (or estimate) the current cycle time. Break it into stages.
- Hunt for the **biggest queue / wait** in the cycle. Acceleration almost always lives in waits, not in the actual work.
- Propose specific changes that shorten the cycle: smaller batch sizes, async approvals, parallel execution, removing serial dependencies, pre-staging inputs.
- Be honest: some "speed" interventions add risk. Flag them.

Output: a named cycle, current time, target time, and the 1-3 interventions most likely to close the gap.

### 5. Automate

Last. Musk's example: on the Model 3 line, he automated parts of the production process that he later had to *un-automate* and do by hand, because he had automated the wrong thing. Automating a process before steps 1-4 just makes a bad process run faster and harder to fix.

What to do:
- From the simplified, accelerated process that survives, identify the truly repetitive, well-understood, low-variance steps.
- For each, propose an automation — script, tool, workflow, integration, rule.
- Explicitly call out steps that should **not** be automated yet (still volatile, still being learned, still being simplified).

Output: a short list of automation candidates and a shorter list of explicit "don't automate yet."

## Running in Socratic mode

Move one step at a time. Per step:

1. State the step in one sentence and *why it comes now* (referring back to what the prior step produced).
2. Ask **2-4 sharp, specific questions** the user must answer to do the step properly. Avoid generic questions ("what are your requirements?") — anchor on what the user has already said. Bad: "What can you delete?" Good: "You listed the admin audit log, the per-tenant theming, and the SSO bridge. Which of those has a named customer asking for it, and which is there because someone thought it would be needed?"
3. Wait for the user's answers.
4. **Push back** if an answer is soft. "We might need it later" is not an answer. Ask for the named failure mode.
5. Summarize what the step produced in 2-3 lines before moving on.

After all 5 steps, write a short closing synthesis: the revised plan or the audit verdict, with the specific changes the user committed to.

## Running in one-shot mode

Produce a single structured report. Use this template exactly — it is short on purpose:

```
# 5-Step Review: <subject>

**Goal:** <one sentence>
**Mode:** One-shot
**Source material:** <what you read / what the user gave you>

## 1. Requirements — less dumb
- **Kept (with owner):** ...
- **Challenged:** ... — and why
- **Invisible requirements surfaced:** ...

## 2. Delete
- **Recommended deletions:** ...
- **Kept because:** ... (named failure mode per item)
- **Over-cut on purpose (likely to add back):** ...

## 3. Simplify / optimize what remains
- ...

## 4. Accelerate cycle time
- **Cycle:** <what iterates>
- **Current vs target:** <est. → target>
- **Top interventions:** ...

## 5. Automate
- **Automate now:** ...
- **Do not automate yet:** ... (and why)

## Verdict
<2-4 sentences. What is the single most leveraged change? What is the user most likely to resist that they shouldn't?>
```

## Tone and stance

- Be **direct and contrarian**, not rude. The user invoked this skill because they want a sharper read than a generic critique would give. Generic encouragement is a failure of the skill.
- **Name things**. Vague advice ("simplify the data layer") fails the test. Specific advice ("collapse the `users_meta` and `user_prefs` tables; they share a primary key and you join them in every read") passes.
- **Reference the user's own words and artifacts.** Quote them. This proves you read carefully and grounds the critique.
- **Admit uncertainty**. If you do not have enough information to evaluate a step, say so and ask one question — do not invent.
- **Do not pad.** If a step has nothing to say for this subject (e.g., a one-person side project doesn't have "automate" leverage), say "nothing meaningful here for this subject, because X" and move on. Empty bullets are noise.

## Common failure modes to avoid

- **Treating the 5 steps as a checklist** instead of a forcing function. The order is the point.
- **Skipping step 1.** Most users want to jump to deletion or optimization. Don't let them — half the work happens in step 1.
- **Soft deletions.** "Maybe rethink X" is not a deletion. Either propose it goes or it stays.
- **Optimizing in step 2.** Step 2 is binary (delete / keep). Save the "how" for step 3.
- **Skipping step 4 because the subject seems static.** Almost everything has a cycle: deploys, hires, reviews, decisions. Find it.
- **Recommending automation in step 2 or 3.** Automation belongs in step 5, after you know what's worth automating.

## When NOT to use this skill

- Pure factual lookups ("what version of Python is this?").
- Tiny, well-scoped edits ("rename this variable")

… (truncated)