Minimal Code Discipline

Use this skill to apply a minimal-code (YAGNI-ladder) discipline while planning and writing code changes. It keeps diffs small and obviously correct without sacrificing the checks that keep users safe.

This skill complements ai-slop-cleaner: that skill cleans slop after it lands; this one keeps it from being written.

When to Use

Use this skill when:

• the user asks for a minimal, lean, YAGNI, or smallest-possible-diff implementation
• a plan or in-flight change is growing beyond the stated request
• writing new code where scope creep, reinvented helpers, or speculative generality are likely
• reviewing a proposed diff for size before implementation

When Not to Use

Do not use this skill when:

• the user explicitly asks for a broad, feature-rich, or future-proofed build (their explicit scope wins)
• the task is exploratory scaffolding the user has marked as throwaway
• minimization pressure would touch protected behavior (see Non-Negotiables)

The Discipline

Existence first. Ask whether the change needs to exist at all; skip work that serves only a speculative future need.

Reuse before writing. Search the codebase for an existing helper, type, or pattern before writing anything new. Never copy a helper that already lives a few files away, reuse it or extract it to one shared location.

Dependency ladder. Reach for the standard library first, then platform-native capability, then an already-installed dependency. Hand-written code is the last resort. Do not introduce a new dependency when a few lines of code suffice, unless the user explicitly requested or approved it.

Understand before minimizing. Read the affected code and follow its execution path first. Ship the shortest correct diff once the problem is understood, code you never write never breaks.

Boring over clever. Prefer boring, obviously-correct code over clever code.