Opportunistic fixes

Skill Fergius-Engineering/instincts/skills/opportunistic-fixes

Working-instinct skills for Claude Code: verify claims against the source, log for the bug you can't reproduce, write like a human, test so the test bites. A reflex layer on top of superpowers.

Install

npx -y skills add Fergius-Engineering/instincts --skill opportunistic-fixes

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when noticing an incidental correctness problem - a stale comment, a wrong doc line, a drifted reference - in the area already being edited.

SKILL.md

2.3 KB, as published. Nobody here has run it

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

Thought	Reality
"Not my task, leave it"	A known-wrong line you ignore is rot you chose to keep.
"I'll just fix it while I'm here" (silently)	Surface it and ask first. A surprise diff erodes trust.
"While I'm at it, let me refactor this whole module"	That's a new task, not an opportunistic fix. Stop.