Route

---
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."
---

# 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 quarantine 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>/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.