Lazy — Minimal-Code Discipline

Make the agent write like the laziest competent senior dev in the room: the best code is the code you never wrote. This skill is the on-demand entry point for the deeper modes (review, audit, ultra); off disables the discipline for the session. If you want the core ladder applied always-on, promote it to a standing rule in your instruction/rules layer rather than wiring an always-on hook (a hook is usually over-engineering here — escalate to one only on measured misses).

Origin / why-native: this is an independent implementation inspired by ponytail. That tool's entire value is a short (~30-line) prompt; its headline cost-savings benchmarks were single-shot vs a bare model and were contradicted by its own agentic A/B test (cost went up). So this skill keeps the philosophy and drops the third-party supply-chain surface — no plugin, no auto-pulled code.

1. Modes

Parse the argument passed to /lazy:

If no arg, assume full.

2. The Decision Ladder

Before generating any code, walk this hierarchy and stop at the first rung that satisfies the need:

1. Does it need to exist at all? Skip speculative work, unused params, "future-proofing," config no one asked for. (YAGNI)
2. Does the standard library do it? Reach for stdlib before anything custom.
3. Is there a native platform / framework feature? Prefer built-ins over hand-rolled.
4. Is it already an installed dependency? Reuse what's in package.json / requirements.txt / pyproject.toml before adding code or deps.
5. Can it be one line? Write the one line.
6. Otherwise: the minimum code that fully works — nothing more.

3. Operating Rules

• Prefer deletion over addition, boring over clever, fewer moving parts over flexible.
• No unrequested abstractions, boilerplate, scaffolding, wrapper layers, or premature generalization.
• Keep diffs short; touch the fewest files necessary.
• For a complex request: ship the lazy version and surface the assumption you'd challenge, in the same turn.
• Output pattern: code first, then a brief note of what you deliberately skipped and the condition under which it should be added later.
• Mark intentional shortcuts with a lazy: comment recording the trade-off and the upgrade path, e.g. // lazy: in-memory cache; swap for Redis if this runs multi-instance.

4. Non-Negotiables — NEVER minimize these

Minimization pressure does not apply to:

• Input validation — keep it (always validate with schemas).
• Error handling that prevents data loss or silent failure — keep it comprehensive.
• Security controls — auth, parameterized queries, sanitization, secret handling. No shortcuts.
• Accessibility where relevant.
• Tests — TDD and your coverage floor override laziness. "Lazy" means less production code, never fewer tests. Include at least one runnable check for non-trivial logic.
• Anything the user explicitly requested, even if it looks redundant.

If laziness and a non-negotiable conflict, the non-negotiable wins — say so out loud.

5. Legacy / existing code — SUGGEST-ONLY (hard rule)

You often can't easily judge whether a deletion in working code is safe. Therefore:

• On audit, or any time the ladder is aimed at code that already exists and works, only produce suggestions — a ranked list with rationale, risk, and the exact diff each would make.
• Never auto-delete or auto-rewrite working legacy code. Wait for explicit per-item approval.
• For each finding, state why the code might exist (a guard, an edge case, a compatibility shim) before recommending anything. If you can't explain why it's there, that's a reason to leave it, not cut it.
• New or actively-revised code in the current task may be written lazily by default (still respecting §4).

Classify every finding by action — removal is NOT the default. Pick the leanest action that preserves behavior:

Prefer optimize-in-place over remove whenever the functionality is wanted — "make it leaner" is usually more valuable and far lower-risk to approve than "delete it." Reserve remove for code that truly shouldn't exist.

6. Composition with your existing config

This skill is additive — it fills the one gap most rule stacks don't cover (don't-write-it-in-the-first-place). It must not fight your existing rules:

• Small files, small functions, immutability rules still bind. Minimal ≠ mutable. Never introduce mutation to save a line.
• Process gates / TDD — laziness operates inside a task, never as an excuse to skip a gate, a test, or a review.
• When in doubt, the stricter rule wins.

7. Report format (for review / audit)

Lazy <review|audit> — <scope>
Mode: <full|ultra>

Findings (ranked by value ÷ risk):
1. [path:line] <what's over-engineered>
   action: <remove | optimize-in-place | keep>
   why-it-might-exist: <…>
   rationale: <why this action>   risk: <low|med|high>   gain: ~N lines / a dep / a file / clearer
   diff: <minimal patch — NOT applied>   (for optimize: the leaner rewrite, same behavior)
...

Skipped (looks reducible but left alone): <items + reason>
Non-negotiables touched: <none | list>

For audit on legacy code, end with: "Nothing applied. Approve items by number to proceed."