simplicity-review

Simplicity Review — Flag the Over-Build Before It Ships

Law 4 says verify before reporting. "It compiles and the test passes" is a claim about correctness, not about whether the change is the minimum that works. This skill runs a diff-scoped review with one question: could this have been smaller? It reads the change like the laziest senior dev in the room, walks a fixed reuse ladder, and reports what to trim. It never edits code. The best code is the code you never wrote.

When to Activate

• After writing a feature or fix, before opening a PR, when the diff feels larger than the task warranted.
• When you reached for a new file, a new dependency, or a wrapper component and a native or existing option might already cover it.
• As a routed step from proceed-with-the-recommendation at the "Refactor / dead code cleanup" line, as the repo-owned alternative to the built-in simplify.
• Before a release cut, over the diff since the last tag, as a last pass on accreted complexity.

The Ladder

Read each added or changed block and stop at the first rung that holds:

1. Does this need to exist?   -> skip it (YAGNI)
2. Already in this codebase?  -> reuse it
3. Stdlib does it?            -> use it
4. Native platform feature?   -> use it
5. Installed dependency?      -> use it
6. One line?                  -> one line
7. Only then:                    the minimum that works

Most real cuts come from rungs 2 to 4: a hand-rolled helper that duplicates an existing one, a component built where a native input, a stdlib call, or a platform primitive already does the job.

Read Before You Cut

Lazy about the solution, never about the reading. The ladder shortens the solution, not the investigation. Trace the whole change and what it touches first. A "simpler" path proposed without reading the surrounding code is a guess, and a wrong trim is worse than the over-build.

Safety Carve-Out (Never Flag)

Lazy, not negligent. These are never on the chopping block, no matter how many lines they cost: