Necessity First

Purpose

The cheapest code is code that never gets written. This skill is a gate that runs after you understand the problem and before you implement: climb a short ladder and stop at the first rung that solves it. The goal is the smallest change that actually works, not the most impressive one.

Be lazy about the solution, never negligent about correctness or safety. Hardening, extra layers and "best practice" beyond what the task needs are an option to offer, not a default to impose.

When to Apply

TRIGGER when:

• About to write new code, a new file, a new module, or a new abstraction
• About to add a dependency, config option, flag, or extension point
• A request sounds bigger than the problem it describes

SKIP (use the named skill instead):

• Ordering the steps of a plan once the approach is chosen — planning-methodology
• Scoring a ResearchPack or plan against quality gates — quality-validation
• Proving finished work is done by executing it — verification-before-completion
• Writing OpenSpec design.md / tasks.md — spec-design
• Matching the existing code style once you do write code — pattern-recognition

Boundary in one line: this skill decides whether and how little to build; the others plan it, score it, style it, or verify it.

Step 0: Understand First

The ladder is only valid on top of understanding. Before climbing it, read the code you would touch and trace the real flow (caller, data, failure path). Without that, "it already exists" and "one line is enough" are guesses.

The Ladder

Climb in order. Stop at the first rung that works.

Rules of thumb:

• No speculative generality: no interface with one implementation, no option nobody asked for, no "we might need it later".
• Three similar lines beat a premature helper.
• Rung 5 still gets a test when it has branches, loops, parsers, money, or security. One-liners with no logic do not need one.

Non-Negotiable Carve-Out

Never cut these in the name of minimalism. They are part of "works", not extras:

Minimal means no unnecessary code. Safe-by-necessity code is necessary.

Closing Note (every implementation)

End each implementation with a short, honest note:

**Skipped / deferred / risks**
- Skipped: [what you deliberately did not build, and why]
- Deferred: [what could be added later if it becomes real]
- Risks: [what the user should know — limits, assumptions, untested paths]

Keep it to a few lines. "Nothing skipped" is a valid answer when true.

Anti-Patterns

Quality Checklist

• Read the touched code and traced the real flow before deciding
• Rungs 1-4 each considered, stopped at the first that works
• No unrequested abstraction, option, or dependency
• Carve-out items (validation, data loss, security, a11y) intact
• Small test added where logic branches/loops/parses or handles money/security
• Closing "Skipped / deferred / risks" note included