Menu
Use when a bug surfaces while building on one's own shared code - a library, base class, SDK, or component.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when about to show any prose a human will read - docs, README, commit bodies, UI copy, store text.
Use when building any mechanic that could fail on a machine out of reach - a shipped product, a CLI a user runs, a server.
Use when doing any work in a project that has the instincts plugin installed
Use when touching build scripts, release or packaging steps, publish flows, or CI config.
Use when about to build something someone proposed, especially when the proposer sounds confident and the idea sounds obviously fine.
Use when adding any cross-cutting change - a new gate, limit, permission check, or rule that must apply everywhere.
| name | fix-in-the-shared-layer |
| description | Use when a bug surfaces while building on one's own shared code - a library, base class, SDK, or component. |
A bug you hit while using your own shared code is almost never a one-off. It's a gap in the shared layer, and every other caller has it too, they just haven't tripped it yet. Fix it where it lives so the fix is inherited everywhere, instead of working around it in the one place you happened to notice.
This is a different move than fix-the-root-cause. That rule picks the causal layer of a bad state; this one is about ownership: when the gap is in code you share, fix it there so every caller inherits the fix.
While building one feature you hit a bug in a util, base class, component, or SDK that other features also use, and you're tempted to add a local workaround.
When a bug surfaces through shared code, ask "would another caller hit this too?" The answer is usually yes. Fix the shared layer and let every consumer inherit it. Then check the fix against the other callers, not just the one that surfaced it.
A workaround at your call site leaves the trap armed for the next person.
Building the invoices screen, you see due dates render a day early for users east of UTC. The cause is your shared date-format helper: it silently converts to UTC before formatting. The tempting patch is to shift the date back on the invoices screen. But the reports screen and the CSV export call the same helper, so they're quietly wrong too โ nobody has noticed yet. Fixing the helper to format in the user's timezone repairs all three at once. The step that matters afterwards: re-read the other two callers, because one of them may have built its own compensation on top of the old behavior. The local shift would have "fixed" one screen and left the rest of the product lying.
| Thought | Reality |
|---|---|
| "I'll just guard it here" | The same trap is still armed everywhere else. |
| "It only happens in my screen" | It happens wherever the shared code is called. |
| "I don't want to touch the shared util" | That's exactly where the bug is. |
