Menu
Use at the start of a task that spans multiple files, touches unfamiliar areas of a codebase, or where it isn't obvious what to load or where to begin. Skips itself for a one-line change or an already-scoped task.
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 | route |
| description | Use at the start of a task that spans multiple files, touches unfamiliar areas of a codebase, or where it isn't obvious what to load or where to begin. Skips itself for a one-line change or an already-scoped task. |
The front door of substantive work: decide what to load before you start, so you pull the 1โ2 things a
task needs instead of reading the whole brain. It's the skill that operationalizes MasterMind's
token economy (~/.mastermind/engineering/active-field.md) โ and it knows when not to run.
~/.mastermind/engineering/core/rigor.md's refuse-list and "keep the always-on
layer tiny").package.json/configs/file types (usually free and decisive).~/.mastermind/engineering/ROUTER.md
and pick, by matching the task to each node's route_when:
~/.mastermind/skills/README.md (which also names
the isolated-context agents in ~/.mastermind/agents/) โ read that index, since memory goes stale,mindset/principles/rigor/agent-loop/product-sense
in ~/.mastermind/engineering/core/),Most users know three or four skills and never discover the rest, so a capability they already own stays invisible until it's too late to help. Routing is the one moment you can see the whole task and the whole library, so it's the right place โ and the only place โ to say something.
Offer only when every gate holds:
Then continue with your own recommendation either way โ an offer is a sentence they can ignore, never a question that blocks the work. Silence is the default: when it's a close call, skip it. A suggestion that isn't obviously worth its line costs attention, tokens, and trust, and those are the things the routing step exists to protect.
Routing decides what to load; spend one extra second deciding what should run it. Four task shapes
are small-model work billed at top rate only by inertia: classify, extract fields, rename, summarise.
Name the shape when you see it โ on Claude Code that means suggesting the cheap seat (/model, or an
agent whose file pins one); on Cursor/Codex it's advice the user applies. The inverse holds too:
planning is one expensive call at the top, not something to repeat mid-task on the execution seat.
And grading is its own seat โ code-reviewer pins a fixed model so the judge's seat doesn't follow
the writer's (a guarantee of fresh context always, and of a different grader whenever the session runs
another tier). Upgrading the execution seat to the planning seat doubles the bill and changes nothing.
build (which can call this first).ROUTER.md is missing/stale, fall back to the active field's engineering/fields/<field>/field.md
load-on-demand map โ routing is a speed-up over a fallback that already works.Use when implementing any non-trivial feature, change, or fix โ "build me X", "add this feature", "implement this", "make this work", "can you create". Covers new functionality, meaningful changes to existing code, and anything where quality matters. Not for a one-line diff โ just do that.
Use when a bug isn't obvious, resists a quick fix, keeps coming back, or you're about to start guessing โ "why is this broken", "this keeps happening", intermittent or flaky failures, a crash you can't explain, behaviour that makes no sense. Not for a typo or an obvious mistake.
Use when something has to be removed or retired โ a feature, endpoint, table column, config key, feature flag, package or whole service; migrating consumers off an old API or version; code that looks dead but might not be. Symptoms: "can we delete this?", "is anything still using this?", "we need everyone off v1", "kill the old one". Not for restructuring that keeps the interface โ that's the `refactorer` agent.
Use when you are about to tell the user something works, hand over a decision you feel confident about, or make a change that can't be undone โ and when a review came back suspiciously clean. Symptoms: "are you sure?", "you said that was fixed last time", nothing to report, the answer feels too tidy. Not for a routine small change; not for reviewing a finished diff โ that's `code-reviewer`; not for driving a finished change end-to-end to get evidence โ that's `qa`. Doubt tests a claim (a diagnosis, a design call, an answer), which is often not runnable code.
Use when an internal package, module, or shared component has little or no usage documentation and people (or future AI sessions) keep using it wrong โ "document this", "write docs for our library", onboarding someone onto an internal API, or handing a package to another team.
Use when work needs to survive losing context โ before a /clear on a long task, when pausing something unfinished, when handing over to a teammate or the next session, when the context window is filling up on multi-day work, or when a long multi-step task starts re-covering ground it already finished. Not the project's decision history across weeks โ that's `roadmap`.