lean-code

---
name: lean-code
description: "Simple, not lazy: the simplest code that fully solves the task, understood first, finished, and checked. Use when writing, changing, fixing or reviewing code: features, bug fixes, refactors, scripts, game code, build tools; also for 'review this', 'is this over-built', or before a pull request. NOT for films, visual design, brand, copy, writing, research or planning, where the person's references and ambition set the bar and cutting is the wrong instinct. Made by Nicolo Gallia 2026-10-26 to keep ponytail's good idea and fix its execution."
---

# Lean code: simple, not lazy

Ponytail had the right goal, simpler and better code, and the wrong word for it. Told to be "lazy", a model does less: it skims the code, skips the edge case and the test, answers in a cryptic line, and calls a fragile one-liner done. This skill keeps the goal and drops the word.

**Simple is the result, never the effort.** Spend the thinking it takes to make the code smaller. Never take that thinking out of understanding the problem, finishing every part, or checking the result.

## House rules come first

If the project has a `LEAN.md` at its root, or the session names a house-rules file, read it before anything else. House rules hold what is true for this person and these projects, and they win over everything below.

## When this applies

Code only. A film, a page's look, a logo, a post or a plan is not code work, even when it is built in code: there the job is to meet the references at full strength. The scripts and pipeline that make a creative piece are code work again.

## The work

1. **Understand it fully.** Read the code the task touches. List every place the change must reach: callers, tests, fixtures, config, docs, and every other copy of the same cause. That list is the scope.
2. **Choose the simplest design that fully works.** Fewest moving parts, not fewest keystrokes. In order:
   - Does it need to exist at all?
   - Does the project already have it?
   - Does the platform or standard library do it?
   - Only then, the least new code. A clear five lines beat a clever one.
   - Deleting beats adding. Fixing the cause once in shared code beats patching each symptom.
3. **Build all of it.** Everything that was asked, every caller the change breaks, and the edge cases at the boundaries. Never cut these to make the code shorter:
   - validation where outside input comes in;
   - error handling that prevents data loss;
   - security and accessibility.
4. **Leave out what nobody asked for:** options, config, abstractions and "for later" code. Say in one line what you left out, so it is a decision rather than an omission.
5. **Prove it works.**
   - Run it.
   - Look at UI rather than assume it renders.
   - Play a game change.
   - Logic that can break quietly gets one small test that fails when it breaks: a branch, a parser, money, security, a data write, a bug fix.
   - A known limit gets a comment: `shortcut: <the limit>, <when to upgrade>`.
6. **Say it plainly.** Short sentences: what changed, how you checked it, and `Not checked:` for anything that mattered and was not checked. Brevity is for the reader. It never hides what you skipped.

## When simpler takes more work

Often the simple version is the harder one: replacing a workaround with the real fix, deleting dead code after proving it dead, merging two near-copies, writing the test that pins a bug. Do that work. It is the point.

## Review mode

Use it when asked for a review, or before a pull request.
1. Read the diff, then the callers and the code it calls.
2. Report only findings with a concrete case: "this input leads to this wrong result". Order them: wrong result, data loss or security, risky logic with no test, real slowness, then code that should not exist.
3. Give at most 10, numbered, in plain English. Each finding has four parts: what it is, the problem, the smallest fix, and what happens if we skip it.
4. End with a one-line verdict.

If nothing changed since the last review, say so instead of repeating it.

A whole-project audit runs only when asked. It reads everything and uses a lot of the plan, so say that first.