---
name: write-less-code
description: >-
  Reach for the smallest solution that actually works before writing code: question whether the task
  needs to exist (YAGNI), prefer the standard library, then native platform features, then an
  already-installed dependency, then one line — custom code last. Load proactively before
  implementing a feature, and whenever the user says "write less code", "be lazy", "lazy mode",
  "simplest solution", "minimal solution", "yagni", "do less", "shortest path", or complains about
  over-engineering, bloat, boilerplate, or unnecessary dependencies.
license: MIT
---

# Write Less Code

The best code is the code never written. This skill is the *positive* half of
minimalism — what to reach for first. The `agent-coding-contract` skill owns the
*negative* half (no new dependencies, no speculative abstractions, minimal
diffs); apply both, don't restate it here.

## The ladder

Before writing any code, 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, an HTTP cache header over a cache layer.
4. **Already-installed dependency solves it?** Use it. Never add a new dependency for what a few lines do.
5. **Can it be one line?** One line.
6. **Only then:** the minimum code that works.

The ladder is a reflex, not a research project. Two rungs work → take the higher
one and move on. The first lazy solution that works is the right one.

## Rules

- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
- Deletion over addition. Boring over clever — clever is what someone decodes at 3am. Fewest files; shortest working diff wins.
- Complex request? Ship the lazy version and question it in the same response: "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
- Two stdlib options the same size? Take the one correct on edge cases. Lazy means less code, not the flimsier algorithm.
- Mark deliberate simplifications with a `// less-code:` comment so a shortcut reads as intent, not ignorance. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path: `# less-code: global lock; per-account locks if throughput matters`.

## 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 — every
paragraph defending a simplification is complexity smuggled back as prose.

Pattern: `[code] → skipped: [X], add when [Y].`

## When NOT to be lazy

Never simplify away: input validation at trust boundaries, error handling that
prevents data loss, security measures, accessibility basics, anything explicitly
requested. User insists on the full version → build it, no re-arguing.

Non-trivial logic (a branch, a loop, a parser, a money/security path) leaves ONE
runnable check behind — the smallest thing that fails if the logic breaks: an
`assert`-based self-check or one small test file. No frameworks, no fixtures.
Trivial one-liners need no test; YAGNI applies to tests too.

---

*Inspired by [ponytail](https://github.com/DietrichGebert/ponytail) (MIT, DietrichGebert).*