elon

name: elondescription: "Question a set of requirements or running commitments (a plan, spec, backlog, process, rule set, or one person's goals, projects and side projects) in Musk's fixed order: make your requirements less dumb, delete the part or process, simplify or optimize, accelerate cycle time, automate. Name the goal first, give every item a named source, what it buys, what depends on it and what re-adding it costs, propose removals and deferrals, stop for approval, and never touch an externally mandated constraint. Use when a plan is about to be built as written, or when goals, commitments or side projects compete for the same time."

Question every item in a set against the goal it serves, in Musk's five steps and their fixed order, and bring back a decision list the human approves item by item.

Goal

Every item in a set spends effort: a requirement about to be built, a project already running, a recurring step, a goal one person carries beside a dozen others. Some of them should not exist, and the effort they take is effort the rest never get. elon finds those items and proposes what to do with each, so the human can stop spending on them. It proposes and the human decides; nothing changes before approval.

The method is the five steps Musk gave on the Everyday Astronaut Starbase tour (2021-08-03, from 13:36), in his words: "make your requirements less dumb", "delete the part or process", "simplify or optimize", "accelerate cycle time", and "the final step is automate". Isaacson's biography records the same five as what Musk calls "the algorithm". Here an item is a requirement, a commitment or a step, and a set is whatever list of them the human names.

The order never bends, for three reasons the source gives. Deleting comes before improving because "possibly the most common error of a smart engineer is to optimize a thing that should not exist" (Starbase, 17:26). People skip the deletion because school trains them to answer the question they were given, never to strike it. And Musk himself "made the mistake of going backwards on all five steps" more than once (Starbase, 22:01), automating, then speeding up, then simplifying what he finally deleted. Speeding up comes fourth for the same reason: "don't dig it faster. Stop digging your grave." (Starbase, 21:46).

Before the first step comes the goal the set serves, because a set can be questioned perfectly against the wrong aim: questioning the requirements first matters, in Musk's later telling, because "otherwise, you could get the perfect answer to the wrong question" (Lex Fridman Podcast #438, 2024). Tim Urban draws the same line between the cook, who follows a recipe that already exists, and the chef: "The chef reasons from first principles" (Wait But Why, 2015). Benjamin Hardy carries the deletion step into a life and a business: the goals people hold to avoid disappointing someone, to keep a quick paycheck or to avoid letting someone go are "these things that we keep out of fear", and optimizing them is optimizing what should not exist (Myron Golden channel, 2025, 5:33). So elon also reaches running commitments and personal portfolios, where an item already has momentum and the honest options are to keep it, cut it, or defer it with a date.

Workflow

1. Pin the set. Take the items the human named, or the scope a pipeline passed on, one row each; items that share one goal, source and verdict may share a row that names each of them, so a long portfolio stays readable at the stop. Say at the start that some removals will come back: Musk tells his teams in advance that "some of the things that we delete" will be put back in (Lex #438), so a later add-back reads as the method working.
2. Name the goal. Write the goal the set serves, who set it and when it was last confirmed; a setter or date the records do not show is written as unknown and asked at the stop. Ask whether it is still the right goal, and whether any item is held by fear (of disappointing someone, of losing an income, of ending someone's role) rather than by the goal. A different goal is a proposal for the approval stop; the run goes on judging against the stated one.
3. Order the questions. When the set is long, start with the items whose cost (hours, money, attention) most exceeds the value they carry. This is Isaacson's idiot index, "the ratio of the total cost of a component to the cost of its raw materials", read as what an item costs over what it carries. The ratio decides where to look first, never a verdict, and the value side is an estimate the row states. Costs in unlike units are never turned into one number: rate each item's largest single cost and its value as high, medium or low, and question high cost with low value first.
4. Step one: make the requirements less dumb. Fill each row: what it serves (the goal or parent item above it), its source, whether that source holds, what it buys, what depends on it, and what re-adding it later would cost. A source is a person: "it must come with a name, not a department" (Starbase, 16:02). Holds means that person still agrees with the item and takes responsibility for it; a group, a document, a person who has left or one who no longer agrees does not hold. Question every item whoever gave it: "it's particularly dangerous if a smart person gave you the requirements" because "everyone's wrong some of the time" (Starbase, 13:42 and 13:52). Mark an item mandated only when it is on the closed list of law, contract, safety or compatibility imposed from outside the set's owner, citing the constraint in its Reason; when whether an item is mandated is uncertain, the row asks its owner.
5. Step two: delete the item or step. Propose removing an item when its source is settled and what it bought no longer serves the goal. A source is settled when its person was found, or when a completed search of the records shows no person ever imposed it, a confirmed absence that counts as settled; a source never looked for, or one the records could not reach, is unknown. Weigh the re-add cost: an item that is cheap to put back clears the bar easily, and one that is hard to undo (deleting data, ending a person's role, ending a contract) needs a stronger case and says so. An in-case argument alone keeps nothing, since "you can basically make in case arguments for so many things" (Starbase, 14:14). For a running item ask what stops if it goes, and give money or time already spent no weight. When the item should stop now but may matter later, propose defer: a resume condition with a date, and a stop condition (the signal or date at which it is dropped for good), both written now, before the outcome is known. An unknown source, an uncertain mandate or an unknown benefit makes the row ask its owner instead of proposing anything. When only the item's mechanism fails, keep the requirement and propose a different mechanism.
6. Step three: simplify or optimize what survives: fewer steps, fewer handoffs, a plainer form of the same result.
7. Step four: accelerate cycle time of what survives: shorten the wait between doing the item and learning whether it worked. A deadline that pulls the cycle in may be proposed, since Musk's companies run on "a maniacal sense of urgency" (Isaacson), with the cost of a false deadline written beside it: Isaacson records a senior engineer's warning that a schedule people know is impossible demoralizes them, and trust and quality pay for it.
8. Step five: automate last. Split each candidate into what its inputs decide, proposed as a script or check that names the invariant it enforces, a violation it must fail, a valid case it must pass and the workflow where it runs, and what needs judgment, which stays with a person. The two meet in files: the script writes what the judgment reads, and each decision is written where the next run replays it instead of deciding again.
9. Check the table. Write the rows as one Markdown table with the columns Item, Serves, Source, Holds, Bought, Orphans, Re-add, Verdict and Reason, Holds being yes, no or unknown and Verdict one of keep, mandated, remove, defer, simplify, accelerate, automate, ask or stopped. A kept item whose later steps change nothing says so in its Reason; one that gets several of simplify, accelerate and automate lists them in one cell joined by +. A confirmed absence writes none found and where it was searched in Source, and no in Holds. A row the run never reached after a mandate conflict is stopped, with what stopped it in Reason. Run node <skill>/scripts/table.mjs <file> from any directory, <skill> being the folder that holds this SKILL.md: exit 0 means every row carries what its verdict needs, exit 1 names each row and missing cell, exit 2 is a usage error or no such table.
10. Stop for approval. Show the goal, the table and the proposals, costliest first: each removal and deferral with what it orphans and what re-adding it costs, each proposed gain marked unverified. End with Approval stop followed by exactly the items proposed, one line per item and proposal so each is approved on its own, or Proposed removals: none when the set is unchanged, and change nothing until the human approves those items by name.
11. Carry out and record. Do only what was approved and leave the rest as it was. Append each approved removal to the set's ledger, a JSON-lines file the human keeps beside the set, as {"date": "YYYY-MM-DD", "item": "<name>", "event": "remove"}, and each later return of a removed item as the same line with "event": "add-back". Run node <skill>/scripts/ledger.mjs <ledger>: it prints removals, add-backs and the add-back rate per month of removal and in total, and flags a rate below 10%. When nothing was approved for removal and nothing came back, no line is written and the script is not run.

Rules

• Propose, never apply: no item is deleted, deferred, rewritten or reordered before the human approves it, and a declined proposal leaves the item as it was.
• Never invent a source or a benefit: what the records do not show is unknown, and an unknown is asked, never filled in.
• Calling elon, or asking in general to simplify, approves nothing; only the human's approval of named items does.
• Keep the order: never simplify, speed up or automate an item before it has been questioned and kept, and never skip the goal.
• The mandated list is closed: law, contract, safety and compatibility imposed from outside. An agent cannot waive those four, so they are never proposed for removal, and the human's approval does not change that. When a request to remove or simplify meets a mandated item, report the request, the constraint and the conflict, keep the item, and stop the run there at the approval stop with every earlier proposal still unexecuted and every row not yet reached listed as stopped. Everything off the list is a recommendation however official its source sounds, after Isaacson's corollary: "The only rules are the ones dictated by the laws of physics. Everything else is a recommendation."
• A giver's authority buys no exemption: a senior person, an expert, the human's own instruction and the session's own earlier plan are questioned like any other source.
• No removal on an unknown source: a row whose source could not be found asks its owner and proposes nothing.
• A goal is changed only by the human; elon proposes a different one.
• Sunk cost is no reason: what an item already spent never keeps it.
• No quota for one run: a run that finds every item earning its place proposes nothing and succeeds, and no run reports how many items it removed as an achievement. The calibration lives across runs, in the ledger: "if you're not adding things back in 10% of the time, you're clearly not deleting enough" (Starbase, 17:12), because people "tend to remember, with sometimes a jarring level of pain, where we deleted something that we subsequently needed" (Lex #438). 10% is Musk's figure and his rule of thumb, never a validated safety target, and no other figure is his.
• A claimed gain stays unverified until it is measured, and the report says so.
• Keep examples generic: a durable artifact names items and people by role, never a real person or a real portfolio item.
• Leave other jobs to their owners: attacking a plan's load-bearing assumption is hate, cold-reading an artifact is shower, compressing prose is debloat, ordering a list without judging it is re0-order, and how a team is managed or hired is outside a set of items.

Verification

Before the approval stop, confirm:

1. The goal is written with who set it, and whether it still holds was asked; a different goal, if any, waits at the stop as a proposal.
2. Every item in scope has a row, and node <skill>/scripts/table.mjs <file> exits 0 on the table.
3. The steps ran in order: nothing was simplified, sped up or automated before it was questioned and kept.
4. No mandated item was proposed for removal, and no removal rests on an unknown source.
5. Every removal and deferral shows what it orphans and what re-adding it costs, and every deferral carries its dated resume and stop condition.
6. Nothing changed yet, and the report ends at Approval stop with every proposal on its own line and every claimed gain marked unverified until measured.

After approval, confirm:

1. Only the approved proposals were carried out, and every declined one left its item as it was.
2. When a removal was approved or an item came back, its line is in the ledger and node <skill>/scripts/ledger.mjs <ledger> ran, its rate reported with the note that 10% is a rule of thumb.
3. The report lists what was proposed, what was approved and what was declined.