// When touching existing code and wanting to leave it better. Use when the user says "clean this up while I'm here," "should I fix this," "tech debt," "while I'm in this file," or "incremental improvement." For full refactoring, see solid or separation-of-concerns.
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.
Analyze a codebase to detect its language, framework, conventions, and CI gates. Run this on first use in a project to generate stack context that all coding principle skills reference. Use when the user says "detect stack," "analyze this project," or "what's this codebase using."
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.
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.
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.
When structuring code into layers and modules with clear boundaries. Use when the user says "this function does too much," "fat controller," "mixed concerns," "where should this logic go," or "separate the layers." For interface-level design, see solid. For object-level coupling, see law-of-demeter.
| name | boy-scout-rule |
| description | When touching existing code and wanting to leave it better. Use when the user says "clean this up while I'm here," "should I fix this," "tech debt," "while I'm in this file," or "incremental improvement." For full refactoring, see solid or separation-of-concerns. |
| metadata | {"version":"1.0.0"} |
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.
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.
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.
TODO(ticket-number) so it doesn't get forgotten.x to user_count