lean-code

# Lean Code

Aggressive YAGNI mode, on demand. The always-on baseline is `rules/quality-code.md`; this skill is the **intensifier** you invoke when minimalism matters most. The win is measured ("smallest solution that FULLY satisfies the task"), not a slogan.

## The ladder — stop at the first rung that holds
1. **Does this need to exist at all?** Speculative need → skip it, say so in one line. (YAGNI)
2. **Stdlib does it?** Use it.
3. **Native platform feature covers it?** (`<input type="date">` over a picker lib, CSS over JS, a DB constraint over app code.)
4. **An already-installed dependency solves it?** Use it. Never add a new dependency for what a few lines do.
5. **Can it be one line?** Make it one line.
6. **Only then** — the minimum code that works.

The ladder is a reflex, not a research project: two rungs hold → take the higher one and move on.

## Intensity
- **lite** — build what's asked, but name the leaner alternative in one line; user picks.
- **full** — the ladder enforced; stdlib/native first; shortest working diff. (Default.)
- **ultra** — YAGNI extremist: ship the one-liner and challenge the rest of the requirement in the same breath.

## When NOT to be lean (load-bearing — never simplify these away)
Input validation at trust boundaries · error handling that prevents data loss · security · accessibility · the calibration real hardware needs · anything the user explicitly asked to keep. **Lean ≠ incomplete:** non-trivial logic leaves ONE runnable check behind (assert-demo or one small test). User insists on the full version → build it, no re-arguing.

## Hard boundary — lean targets OVER-building, never completeness
This is orthogonal to thoroughness. "Minimal" means *less code per branch*, NOT *fewer branches done* or *cutting corners with a hack*. It must never be an excuse to under-deliver, skip verification, or leave a required branch — see `rules/finish-the-task.md` (its completeness + quality pillars win) and `rules/quality-code.md` (the no-monkey-patch pole). Mark a deliberate shortcut with a `simplification:` comment naming the ceiling + upgrade path.

## Output
Code first. Then at most three short lines: what was skipped, when to add it. If the explanation is longer than the code, delete the explanation. Read the surrounding code / requirements before pruning — prune to the task, not to a blanket rule.

## Why this works (evidence, not marketing)
AI agents measurably over-produce code (GitClear's 211M-line study: duplication up, refactoring down; Faros: +98% PRs, +91% review time, no velocity gain) — a "do I even need this?" constraint addresses a real, measured problem. But always-on minimalism is non-monotonic (arXiv 2601.22025, "When better prompts hurt": a blanket conciseness wrapper can drop accuracy/completeness), which is exactly why this is an **on-demand skill + an advisory hook**, never a hard gate. Success metric = rewrite/churn rate, not raw lines removed.