delete-line-of-code — quality + safety report

---
name: delete-line-of-code
description: Force a complexity-bias correction on any code review, refactor debate, or "should we add this abstraction" moment. Use this skill aggressively when the user is doing PR review, debating a new layer of indirection, considering a wrapper or helper, justifying a framework, evaluating dead code, or saying "should we add this abstraction", "should we keep this helper", "the codebase grew 20% this quarter — that's progress", "let's not delete it, we might need it", "what's our LOC velocity", "this PR is +2000/-50, looks productive", "refactor to make it more extensible", or any moment a team is treating added lines as output and deleted lines as loss. Also fires on architecture reviews that reward surface area, retros that celebrate "code shipped", and any reviewer letting a +600 LOC PR through without asking what could be deleted instead. The rule: award one point for adding a line, two points for deleting one. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - best-part-is-no-part
---

# Delete Line Of Code

> "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. I would award one point for adding a line of code and two points for deleting a line of code."
> — Elon Musk, *The Book of Elon* (Chapter: Simplicity Wins)

## What this skill captures

Most engineering cultures silently reward adding code. PRs are measured in additions, sprints are measured in features shipped, and reviewers feel awkward asking "can we delete something instead?" Musk inverts the scoreboard: a line added is a tax, a line deleted is a gift. "Simplicity both improves reliability and reduces cost. Fewer components means fewer components to buy and fewer components that can go wrong." The same logic applies to code: every line is a component that can break, drift, get misread, or need migrating.

The value to you: a sharper bar for new code, a default toward subtraction in refactors, and a reviewer's license to challenge any PR that ships net-positive lines without justifying why deletion was not an option. This skill is about *code and abstractions* specifically — for hardware and process, use `best-part-is-no-part`.

## When to use this skill

- A pull request is net-positive lines and the reviewer is about to wave it through on volume alone.
- Someone proposes a new abstraction, base class, helper, wrapper, config layer, or plugin system to "make things more extensible."
- A refactor debate is framed as "should we restructure this?" when the real question is "what can we delete?"
- A team retro or status update cites "lines shipped" or "code velocity" as a proxy for progress.
- Dead code, unused branches, feature flags long past their decision, or legacy helpers are being preserved "just in case."
- A junior engineer is justifying a 600-line PR for a feature that could be 80 lines.

## The how-to

1. State the scoreboard out loud, in the review.
   > "I would award one point for adding a line of code and two points for deleting a line of code."
   > — *The Book of Elon*
   Make the bias explicit. Reviewers default to additive thinking because added code feels like productivity. Naming the +1/-2 rule changes what the room considers a "good" PR.

2. Reframe the PR diff before discussing the change.
   > "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."
   > — *The Book of Elon*
   Before evaluating *what* the code does, evaluate *how much* of it there is. Ask: is the line count justified by the requirement, or is it the first thing that worked?

3. Hunt for what could be deleted alongside what is being added.
   > "Fewer components means fewer components to buy and fewer components that can go wrong."
   > — *The Book of Elon*
   Every PR is an opportunity to subtract. If the author added 200 lines, ask which 200 existing lines this change makes obsolete. If the answer is "none," push back: that is a code-base growing without consolidation.

4. Refuse new abstractions until concrete duplication forces them.
   > "Every decision we made in early SpaceX designs has been with simplicity in mind."
   > — *The Book of Elon*
   A base class introduced for "future flexibility" is a line-of-code tax with no current payoff. Wait until you have three real callers, not two imagined ones. Premature abstraction is the most expensive way to add lines.

5. Delete dead code on sight; never archive it "just in case."
   > "Simplicity is our mantra. It creates both reliability and low cost."
   > — *The Book of Elon*
   Commented-out blocks, unused helpers, stale feature flags, and "we might need this later" branches are lines that can break, mislead, or rot. Git history is the archive. Delete and move on.

6. Apply common sense over rule-following when "the framework requires it."
   > "In general, always pick common sense as your guide. If following a 'company rule' is obviously ridiculous in a particular situation, such that it would make for a great Dilbert cartoon, then the rule should change."
   > — *The Book of Elon*
   If a style guide, framework, or convention is forcing you to add lines that do nothing for the system, the rule is the bug. Push to change it, or break it locally with a comment explaining why.

7. Measure the delta and report subtraction as a win in standup.
   > "I would award one point for adding a line of code and two points for deleting a line of code."
   > — *The Book of Elon*
   When you ship a PR that is net-negative LOC, say so. Make subtraction visible. Culture changes when the team starts celebrating the -800 PR more than the +800 one.

## Common failure modes

- **Treating LOC as throughput.** Dashboards that chart "lines added per engineer per week" reward exactly the wrong behavior. Stop measuring it; if you must measure it, invert the sign.
- **Premature abstraction in the name of extensibility.** Adding a plugin system, base class, or config layer for "the future" almost always adds more lines than the eventual concrete duplication would have. Wait for the third caller.
- **Keeping dead code "just in case."** The case never comes. The dead code rots, confuses new readers, and survives migrations it should not have. Delete it; git remembers.
- **Reviewer cowardice on big PRs.** A +2000/-50 PR feels too expensive to push back on, so it gets approved. That is exactly when the +1/-2 rule should fire hardest — ask what 1500 of those lines could become.
- **Refactors that grow the codebase.** A "cleanup" that ships net-positive lines is not a cleanup. Name it for what it is: a rewrite. Hold it to the same bar as new code.

## When NOT to use this skill

- The added lines are tests covering previously untested critical paths. Test code earns its lines.
- The change is genuinely new functionality with no existing equivalent to delete, and the line count is already minimal for the requirement.
- You are debating *hardware parts or process steps* rather than code — use `best-part-is-no-part` instead, which is the physical-world sibling of this rule.
- The codebase is so new there is nothing to delete yet; focus on not over-building rather than on subtraction.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Simplicity Wins" (in "Designing the Organization").