opportunistic-fixes

The rule

While you're already working in an area, you'll spot small things that are wrong but aren't your task. A comment that describes old behavior, a doc line that drifted from the code. Don't silently ignore them, and don't silently fix them either: point them out, ask if the fix belongs in this change, and only then do it, staying inside the area you're already in. This is not a license to go hunting for unrelated refactors — it's a refusal to leave a known-wrong thing behind without saying so.

Fires when

You're editing a file or area for one task and notice a separate, incidental correctness problem nearby.

How to apply

Name the thing you noticed and where it is. Ask whether to fix it as part of the current change. On a yes, fix it and say what you changed. Keep it to the area you're already touching. If the fix would pull you into unrelated code, that's a new task, not an opportunistic fix. A bug you hit in your own shared code isn't opportunistic either — that's fix-in-the-shared-layer. Check the thing is actually wrong against the code before you flag it, so you don't "correct" something that was already right.

Worked example

You're editing a function to add a parameter. Right above it, the doc comment still says it returns a list, but the code has returned a map for two versions. You're already here, so it's cheap. Say so: "While I'm in this function, the comment above it is stale. It says list, the code returns a map. Want me to fix it in this change?" On a yes, fix it and mention it. Leaving a known-wrong comment because it wasn't the task is how a codebase rots, one ignored line at a time. Silently rewriting nearby code without asking is how a small change turns into a surprise diff the user didn't want. Surfacing it first avoids both.

Red flags