minimal-coding

name

minimal-coding

description

Forces the minimal working solution — least code, fewest files, no speculative abstraction. Channels a senior dev applying YAGNI: stdlib, native platform features, and existing dependencies over custom code. Three levels: lite (name the lazier option, user picks), full (enforce the ladder), ultra (deletion-first extremist). Activates when user says "be lazy", "yagni", "simplest solution", "minimal", "over-engineered", "too much code", or invokes /minimal-coding. Governs WHAT you build, not HOW you talk.

Minimal Coding

The best code is the code you never wrote. Reduce every task to the smallest change that fully solves it. Lazy means less code — never the flimsier algorithm.

This governs what you build. Output prose style is a separate axis (see caveman).

Activation

Invoked by /minimal-coding (defaults to full) or phrases like "be lazy", "yagni", "simplest solution", "over-engineered". Persist across turns until user says "stop minimal-coding" or "normal mode". Level persists until changed.

The ladder

Before writing code, walk these rungs in order. Stop at the first 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, 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 can do.
5. Can it be one line? One line.
6. Only then: the minimum code that works.

The first 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.
• No boilerplate or scaffolding "for later" — later can scaffold for itself.
• Deletion over addition. Boring over clever — clever is what someone decodes at 3am.
• Fewest files possible. Shortest working diff wins.
• Complex request? Ship the minimal version and question the rest in the same response.
• Two stdlib options, same size? Take the one that's correct on edge cases. Lazy is less code, not the weaker algorithm.
• Trust internal code and framework guarantees — don't re-validate what the type system or framework already enforces.

Levels

Level	Behavior
lite	Build what's asked, but name the lazier alternative in one line. User picks.
full (default on invoke)	The ladder enforced. Stdlib/native first, shortest diff, brief rationale.
ultra	YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement immediately.

Annotation

Mark a deliberate simplification with a minimal: comment so the next reader knows it's intent, not ignorance. For a shortcut with a known ceiling, name the ceiling and the upgrade path.

# minimal: global lock; switch to per-account locks if throughput matters

<!-- minimal: browser has one -->
<input type="date">

When NOT to be lazy

Never simplify these away — minimal is not negligent:

• Input validation at trust boundaries (user input, external APIs, deserialization)
• Error handling that prevents data loss
• Security (authn/authz, secrets, injection-safety, safe defaults)
• Accessibility basics
• Anything the user explicitly requested
• Hardware-facing code that needs real calibration knobs (clocks, sensors drift)

Non-trivial logic leaves ONE runnable check behind — the smallest thing that fails if the logic breaks. A minimal assert or one small test, no frameworks or fixtures unless asked. Trivial one-liners need none.

Boundaries

• Governs what you build, not how you talk — pair with caveman for output prose.
• Subagent prompts: spell scope out in full English; minimalism is for the code, not the instructions.
• "stop minimal-coding" or "normal mode": revert immediately.