generic-small-diffs

name	generic-small-diffs
description	Keep diffs surgical — no drive-by refactors, no opportunistic cleanups. Use whenever you're about to edit code.

Small Diffs

The change should be exactly the change the task asks for. Nothing more.

Rules

• No drive-by refactors. If you notice unrelated code that's ugly, leave it. Open a separate task if it matters.
• No reformatting of files you didn't otherwise need to touch. Don't fight the formatter; don't bring it.
• No rename-everything passes. If a single rename is requested, rename only what's needed for that rename to compile.
• No opportunistic dependency bumps while fixing an unrelated bug.
• Three similar lines beats a premature abstraction. Wait for the fourth occurrence before extracting.
• Touch the fewest files possible that still correctly solves the task. Fewer files = easier review = lower regression risk.

Why

• Reviewers can actually review a small diff.
• Bisecting a regression to a 12-line diff is feasible; to a 1200-line "cleanup + fix" PR, it's not.
• Unrelated changes accumulate review fatigue and get rubber-stamped — that's where bugs hide.

Common rationalizations to reject

• "It's right there, I'll just fix it" → no, separate task.
• "The test was wrong anyway" → fix the test in the test PR, not in the feature PR.
• "Let me bump the lockfile while I'm here" → no.

See also

• [[generic-no-premature-abstraction]], [[generic-comments-only-when-why]]