Smallest Change First
Use before writing any new code, function, file, or dependency, walks a decision...
Install
npx skills add ccplugins/awesome-claude-code-plugins --skill smallest-change-first -g -a claude-code -y- Repository
- ccplugins/awesome-claude-code-plugins991
- Category
- Writing
- Updated
- 3mo ago
- License
- Apache-2.0
- Context cost
- Lightabout 684 tokens
- Runs scripts
- No, instructions only
What it does
Use before writing any new code, function, file, or dependency, walks a decision ladder that prefers reuse over new code, and requires asking before adding anything beyond the literal request.
Smallest Change First
Overview
New code is a liability the moment it's written: it has to be read, tested, and maintained forever after. Most requests don't need new code at all, they need something that already exists, used correctly.
Core principle: the best code is the code you don't write.
The Ladder
Before writing anything, walk this ladder in order. Stop at the first step that resolves the need.
- Does this need to exist at all? Is the request actually solved by deleting something, or by not doing the thing? Some "fixes" are actually removals.
- Is it already in this codebase? Grep/graphify for an existing function, class, or pattern that does this or something close enough to extend.
- Is it in the language's standard library? Don't hand-roll what
stdlibalready provides correctly and tested. - Is it a native platform/framework feature? Check the framework's own docs (see the researcher agent) before writing custom logic, many "custom" needs are a one-line config flag.
- Is it an already-adopted dependency in this project? Check
package.json/pyproject.toml/build.gradle/etc. for a library already in use that does this, before adding a new one. - Can it be one line? If steps 1, 5 don't resolve it, can the need be met in a single expression rather than a new abstraction?
- Only now, write the minimum code that solves the stated problem. No more.
The "ask before extra" rule
If step 5 concludes a new dependency is genuinely warranted, or if satisfying the request would require touching files, adding abstractions, or writing code beyond the literal scope of what was asked, stop and ask the user first. Do not silently expand scope because a better version occurred to you mid-task. Surface it, explain why, let them decide.
