best-part-is-no-part — quality + safety report

---
name: best-part-is-no-part
description: Force a subtraction-first reflex on any artifact, plan, or process the user is about to add to. Trigger eagerly when the user says "let's add", "we need a new", "should we add a flag", "I'm scoping a feature", "review this PR", "this design has X components", "simplify this", "we have too many parts", "the pipeline has 12 stages", "let's wrap this in another abstraction", "let me factor out a helper", "add a config option", "build a new service", "introduce a new table", "another microservice", "another middleware", "another hook", "another team handoff", "another approval step". Also fire on code reviews that grow line count, designs that compose more parts to fix a flaw, and processes that bolt on a checklist instead of deleting a step. The maxim: the best part is no part, the best process is no process — every part and step must justify its existence or be deleted, even at the cost of putting one in ten back later. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - delete-line-of-code
  - dilbert-test
  - tolerance-stack-analysis
---

# Best Part Is No Part

> "The best part is no part. The best process is no process."
> — Elon Musk, *The Book of Elon* (Chapter: Simplicity Wins)

## What this skill captures

Musk's strongest bias in design is subtraction, not addition. Parts, code, processes, approval steps, services, abstractions — each one is a liability until proven otherwise. "Fewer components means fewer components to buy and fewer components that can go wrong." This skill exists to interrupt the human instinct to add — a flag, a service, a checklist step, a helper, a meeting, a config option — and force the question: *can this be deleted entirely?*

The standard Musk holds is concrete and falsifiable: "If you're not adding deleted things back in 10 percent of the time, you're not deleting enough." Use this skill to push past the comfort of "just in case" and into a deletion-first stance. The value: smaller surface area, fewer failure modes, lower cost, faster cycles — and a design where every remaining part has earned its place.

## When to use this skill

- The user is reviewing a PR and the line count is going up rather than down.
- The user is scoping a feature, a flag, or a config option ("should we add…").
- The user is designing a process, pipeline, or workflow with N stages.
- The user is debugging a flaky system by *adding* a retry, fallback, or guard rather than removing the broken step.
- The user is bolting on a new service, microservice, abstraction, or middleware to fix a flaw in an existing one.
- The user is proposing a new approval gate, checklist item, sign-off, or handoff.

## The how-to

1. **Name every part and process on the table, then ask of each one: "Can this be deleted entirely?"** Not simplified. Not optimized. *Deleted.* List them; do not skip any.
   > "I look at every tiny part of each process and ask, 'Is this process necessary?'"
   > — *The Book of Elon*

2. **Demand a named human owner for every part that survives.** If nobody currently working will defend the part, it is dead weight from a prior era.
   > "Whatever requirements or constraints you do have must come from a person, not a department… You must know the name of the real person who made every requirement."
   > — *The Book of Elon*

3. **Delete past the comfort line — overshoot on purpose.** If your deletions all stick, you did not delete enough. Aim for ~10% rollback as proof of healthy aggression.
   > "If you're not adding deleted things back in 10 percent of the time, you're clearly not deleting enough."
   > — *The Book of Elon*

4. **Refuse "just in case" as a justification.** It is the universal excuse to keep dead parts alive. A part survives because it is *currently load-bearing*, not because it might one day be.
   > "The bias tends to be very strong for adding this part or process step 'just in case we need it.' But you can make 'just in case' arguments for many, many, many things."
   > — *The Book of Elon*

5. **When you find dissimilar parts glued together to compensate for being separate, collapse them into one.** Multi-part tolerance stacks and inter-part seams are the failure surface itself.
   > "It's way better to have a single piece, casted. Then you have no gaps, no sealant, no dissimilar metals."
   > — *The Book of Elon*

6. **Treat deletion as a campaign, not a one-time pass.** Say it out loud, ugly: nothing is sacred. Then go again.
   > "We are on a deletion rampage!! Nothing is sacred. We will delete any remotely questionable tubes, sensors, manifolds, etc. tonight. Please go ultrahardcore on deletion and simplification."
   > — *The Book of Elon*

7. **Do not optimize before you delete.** Optimizing a part that should not exist is the most common smart-engineer mistake; you will end up shipping a faster, leaner version of nothing.
   > "The most common mistake of smart engineers is to optimize a thing that should not exist."
   > — *The Book of Elon*

## Common failure modes

- **Optimizing the doomed part.** Making the turntable faster, more reliable, better-greased — when the right move is robot-to-robot handoff with no turntable at all.
- **"Just in case" accretion.** Every flag, hook, sensor, approval, and config kept because *someone might want it someday*. Musk explicitly names this as the dominant bias to overcorrect against.
- **Zero rollback.** Bragging that "nothing we deleted had to come back." This is failure, not success — it means you were too conservative.
- **Adding to fix flakiness.** Wrapping a broken step in retries, queues, and circuit breakers instead of deleting the broken step.
- **Counting parts (or robots, or services, or lines of code) as a figure of merit.** "The number of lines of code is not a figure of merit. I consider a large number of lines of code to be bad, not good."

## When NOT to use this skill

- The user is auditing a full plan or design and wants the entire 5-step algorithm (requirements → delete → simplify → accelerate → automate). Route to `the-algorithm` instead; this skill is *only* the deletion maxim.
- The part in question is genuinely load-bearing for a safety- or life-critical function (avionics, medical, structural). Subtract elsewhere; here, prove necessity first.
- The user is in early exploration / divergent ideation where adding options is the point. Subtract at convergence, not divergence.
- The "part" is a person or a team being discussed in headcount terms — this skill is about artifacts and processes, not human decisions.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Simplicity Wins" (in "Designing the Organization"), plus supporting passage on the "deletion rampage" and the 10% add-back rule.