Menu
Use when adding or changing a feature, a data model, or any action that creates, edits, or removes state.
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
| name | project-onto-all-systems |
| description | Use when adding or changing a feature, a data model, or any action that creates, edits, or removes state. |
A feature is never just the function you're writing. It ripples into the cache that now holds stale data and the notification that now says the wrong thing; undo doesn't know the change happened, and no test covers it. Before you call it done, walk the whole system and ask what this change touches.
This is about the consequences of the change you're already making, not a license to add features nobody asked for. You're tracing the ripples of one change, not widening the scope.
Adding a feature, changing a data model, or adding any action that creates, edits, or removes state.
List every subsystem the change could reach: cache and invalidation, notifications and messages, persistence and migrations, undo and history, permissions, search and indexing, tests. For each one, ask "does this change need something here?" Handle it or consciously decide to skip it. Don't just forget it exists.
You add "rename project". The rename function itself is trivial. But the cache still maps the old name, the recent-items list still shows it, the audit log records "created" instead of "renamed", search still indexes the old name, and nothing tests the name-collision case.
The one-line rename was about 10% of the real work. Projecting it across the system surfaced the other 90% before it shipped broken.
| Thought | Reality |
|---|---|
| "It's just a small change" | Small in one file, wide across the system. |
| "The function works" | The function isn't the feature. |
| "I'll handle the cache later" | Later is a bug report from a user. |
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.
