# Route > 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. - Skill: `mehrad-dm/route` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add mehrad-dm/route` - Raw SKILL.md: https://api.skillmd.com/api/skills/mehrad-dm/route/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: mehrad-dm (https://skillmd.com/u/mehrad-dm) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/mehrad-dm/route --- # MasterMind: Wayfinder 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. ## Method 1. **Name the destination.** One line: what is this task actually producing? Scope before routing. 2. **Right-size the map.** If it's a one-line diff, a typo, or obviously covered by what's already in context: say *"no map needed, just do it"* and **exit.** Ceremony on a trivial task is waste (this is the same instinct as `~/.mastermind/engineering/core/rigor.md`'s refuse-list and "keep the always-on layer tiny"). 3. **Detect the field**: `package.json`/configs/file types (usually free and decisive). 4. **Build the load manifest: links only, no summaries.** Consult `~/.mastermind/engineering/ROUTER.md` and pick, by matching the task to each node's `route_when`: - which **field-pack file(s)** to load (and their token cost: budget it), - which **skill(s)** fit: pick from the index at `~/.mastermind/skills/README.md` (which also names the isolated-context **agents** in `~/.mastermind/agents/`): read that index, since memory goes stale, - which **core docs** the task genuinely needs (`mindset`/`principles`/`rigor`/`agent-loop`/`product-sense` in `~/.mastermind/engineering/core/`), - which **codebase areas** to read first. The manifest **points** to files to open; it links instead of paraphrasing (so it can't drift out of sync). 5. **Load progressively.** For a big/foggy task, load the entrance set only; name the next files *after* the first decisions resolve. Front-load only the context this step uses. ## Offer what fits: at most once, and only when it changes the outcome 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: - **It changes the outcome, not the ceremony.** "This is a risky unknown, want a throwaway prototype first?" earns its line. "You could also run qa" does not. - **They didn't already ask for it**, and haven't turned it down this session. One decline retires that offer for good. - **One per task, maximum.** If two fit, offer the one with the larger consequence and stay quiet about the other. - **Say the value, not the tool.** *"There's client data in this repo. I can quarantine it so it can't be committed"* lands; *"invoke the lab skill"* is homework. 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. ## Seat the task as well as the knowledge (model economics) 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. ## Rules - **The manifest is a list of things to load, not a plan of work.** Wayfinder chooses *what knowledge to bring*; the actual building is `build` (which can call this first). - **Load a file for a reason you can name.** Every entry earns its tokens or it's cut. - **If `ROUTER.md` is missing/stale, fall back** to the active field's `engineering/fields//field.md` load-on-demand map: routing is a speed-up over a fallback that already works. ## Gotchas - **A load manifest, not a ticket/issue system.** Wayfinder routes knowledge for one session; it is not a project tracker. Keep it to a load manifest. - **Over-routing is as bad as under-routing.** A three-file task needs no map: the right-size step is a feature, not a formality. - **Points to the source.** The moment the manifest starts summarizing a doc's contents, it will drift and lie. Link to the file; let the reader load the source of truth.