boy-scout-rule
Boy Scout Rule
Before Applying
If .agents/stack-context.md exists, read it first. Apply this principle using idiomatic patterns for the detected stack. For framework-specific details, use context7 MCP or web search — don't guess.
Principle
Leave every file you touch a little better than you found it. Not a lot better — a little better. Incremental improvement compounds into a clean codebase over time.
Why This Matters in Production
Codebases don't rot overnight. They degrade one shortcut at a time — a hardcoded value here, a skipped rename there, a TODO that lives for three years. The Boy Scout Rule is the antidote: it makes improvement the default, not a scheduled event.
Teams that practice this never need "cleanup sprints." Their code stays healthy because maintenance happens continuously, embedded in regular feature work.
But this only works with discipline: improvements must be small, safe, and scoped. A "cleanup" that touches 40 files and breaks two features is worse than leaving the mess.
Rules
More from jordancoin/codingskills
kiss
When writing or reviewing code to reduce complexity and improve readability. Use when the user says "simplify this," "too complex," "hard to read," "clean up," "what does this do," or "can't follow this code." For over-engineering concerns, see yagni. For structural clarity, see separation-of-concerns.
21yagni
When writing or reviewing code to prevent over-engineering and speculative features. Use when the user says "is this over-engineered," "do we need this," "should I add," "future-proof," or "just in case." For simplicity concerns, see kiss. For abstraction design, see solid.
17dry
When writing or reviewing code to eliminate duplicated knowledge and business logic. Use when the user says "this is duplicated," "we have this in two places," "single source of truth," "DRY this up," or "shotgun surgery." For premature abstraction concerns, see yagni.
12solid
When designing module boundaries, interfaces, or class hierarchies for maintainable architecture. Use when the user says "how should I structure this," "too coupled," "hard to test," "dependency injection," "single responsibility," or "interface design." For simpler structural concerns, see separation-of-concerns.
12law-of-demeter
When reviewing code for excessive coupling and deep object chains. Use when the user says "too coupled," "train wreck," "chained calls," "feature envy," "mocking is painful," or "this reaches too deep." For broader structural coupling, see solid.
11convention-over-configuration
When organizing project structure, establishing patterns, or reducing configuration overhead. Use when the user says "how should I organize this," "what's the convention," "too much config," "project structure," "naming pattern," or "standardize this." For code-level structure, see separation-of-concerns.
11