# Boy Scout Rule

> Leave every file you touch marginally cleaner without expanding the change beyond its purpose. Use when editing code for one task and you notice small decay worth fixing in passing.

- Skill: `amey-thakur/boy-scout-rule` (Agent Skill)
- Install (CLI): `npx skillmds@latest add amey-thakur/boy-scout-rule`
- Raw SKILL.md: https://api.skillmd.com/api/skills/amey-thakur/boy-scout-rule/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Amey-Thakur (https://skillmd.com/u/amey-thakur)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/amey-thakur/boy-scout-rule

---


# Boy Scout rule

The rule borrows a camping maxim: leave the campground cleaner than you found
it. Applied to code, each commit improves the lines it already touches. The
failure mode is not neglect but its mirror: a one-line fix swells into a
refactor no reviewer signed up for, and the original change drowns.

## Method

1. **Scope cleanup to the diff you already own.** Improve only lines the
   primary change forces you to read or edit. A function three screens away
   may be ugly, but if you did not touch it, leave it and note it elsewhere.
2. **Cap the tax at a few minutes.** Rename one unclear variable, extract one
   magic number to a named constant, delete one dead branch. The moment the
   cleanup wants its own tests, stop and split it into a separate change.
3. **Separate cleanup commits from behavior commits.** Commit the rename or
   the reflow on its own, then the bug fix on top. A reviewer skims the
   mechanical diff and reads the real one closely, instead of untangling both.
4. **Prefer reversible, low-risk edits.** Formatting, naming, extracting a
   constant, tightening a type: yes. Reordering call sequences, changing error
   handling, swapping a data structure: no, those are changes in their own
   right.
5. **Format the touched file, not the repo.** Run
   `prettier --write path/to/file` or `ruff check --fix path/to/file`. A
   repo-wide reformat buries your real change under thousands of unrelated
   lines and poisons the blame history.
6. **File larger rot, do not chase it.** Open a tracking issue naming the file
   and line, or add a comment linking that issue number. The rule improves what
   you pass through; it does not license a detour into a rewrite.

## Litmus tests

- Can a reviewer state the commit's single purpose after reading the diff?
- Would reverting the cleanup while keeping the fix leave both still working?
- Did the touched-file count grow only because the real change reached there?
- Could you drop the cleanup entirely and still ship the fix on its own?

## Boundaries

On code you had no other reason to open, the rule does not apply: a dedicated
refactoring pass is a planned task with its own review, not an opportunistic
edit. Defer to team convention when a file is mid-migration or under a freeze.