LexAI/.cursor/skills/model-routing/SKILL.md

name, description

name	description
model-routing	Ask which models this project should run on, then bind the four routing lanes (lead, strong, mid, fast) into docs/MODEL_ROUTING.md and the model line of every .cursor/agents/*.md. Use at first initialization of a project, when the model lineup or plan changes, when a Task call fails with an unknown model, or when the sessionStart hook reports the lead model has drifted from the recorded lane.

Bind this project to real models exactly once, in one place, from what the operator can actually select — then let every other file refer to lanes. The kit ships unbound on purpose: every subagent carries model: inherit, so the roster works out of the box, but it also means the "cheap" scout costs exactly what the lead costs until this skill has run.

Refuse to guess. Every ID written here must come from the operator's answer or from Cursor's model picker — never from the example families in docs/MODEL_ROUTING.md, and never from what a model was called at training time.

1. Read the current state

1. docs/MODEL_ROUTING.md — the lane table and its Status block. If Routing filled is already yes, this is a re-run: report the diff before writing anything.
2. .cursor/agents/*.md — the current model: and lane: of each subagent. Count how many are still inherit.
3. Whether the sessionStart hook reported a lead-model mismatch this session; if it did, that mismatch is the reason you were invoked and belongs at the top of your report.

Never read, echo, or write an API key, and do not touch ~/.cursor/ — this skill's authority stops at the project.

2. Ask the operator — one round, four questions

Ask all four at once; do not interview one question at a time. Lead with what step 1 found so the operator is confirming, not composing.

1. Budget shape. "Four distinct models, two, or one?" — this decides whether lanes collapse. One model in all four lanes is a valid, supported answer.
2. Strong lane. "Which model should judge — critic, security-auditor, and any parity verdict?" Note that Auto is not eligible here: a router that may downgrade under load cannot be the independent judge the quality gates assume.
3. Lead lane. "Which model do you want to drive the session yourself?" You cannot set this — it lives in the picker. Ask them to select it now so you can record what they actually chose.
4. Ceiling. "Any cost, latency, or data-residency constraint that should keep work off a particular model?" A yes moves default lanes down; it never moves the gates.

If the session is non-interactive (a Cloud Agent run, a headless cursor-agent invocation) and no answers were supplied, do not invent a routing: leave the kit unbound, record the request as a decision-ready item in docs/PROGRESS.md → Waiting on you, and stop. An unbound kit degrades to "everything runs on the lead's model," which is expensive but correct; a model ID that does not exist is a hard failure on the first Task call.

3. Resolve real model IDs

• Have the operator open the model picker and read back the exact IDs, or confirm the ones you propose from the profile table in docs/MODEL_ROUTING.md.
• Availability follows the plan, not the docs: a model in the table that their account cannot select is not an option. Ask rather than assume.
• Prefer Cursor's own Composer family for mid/fast unless the operator has a reason otherwise — it is trained for the builder loop and is usually the cheapest capable option.
• The gauntlet-critic rides the strong lane and never a cheaper one: a referee weaker than the builder rubber-stamps. If the strong lane collapsed into mid, say so in the report and flag that every parity verdict now needs owner sign-off.
• Cross-vendor lanes are a feature, not an inconsistency: a strong lane from a different vendor than mid gives you a genuine cross-model critic for free. Say so if the answers land that way.

4. Write the routing everywhere it has to agree

Two files must match, and the third place is a human action you cannot perform.

1. docs/MODEL_ROUTING.md — replace [LEAD] / [STRONG] / [MID] / [FAST], fill the Status block (plan, date, "verified against the model picker"), note any collapsed or degraded lane, and add a Change log row.
2. .cursor/agents/*.md — for each file, read its lane: key and set the model: line from that lane. Change nothing else: not name, not description, not readonly, not lane, not the body. Leaving a file on model: inherit is a legitimate outcome when the operator wants that role to follow the lead — it is not a skipped file, and you must say which ones you left.
3. The model picker — you cannot write it. Tell the operator plainly which model to select for the lead lane, and record their answer in the table.
4. docs/DECISIONS.md — one ADR entry only when the routing embeds a real trade-off: a collapsed strong lane, a residency constraint, Auto on the lead. Skip it for an unremarkable four-lane fill.

5. Verify before reporting

Verification is mechanical — run it, do not assert it.

1. grep -rn "\[LEAD\]\|\[STRONG\]\|\[MID\]\|\[FAST\]" docs/MODEL_ROUTING.md returns nothing.
2. Every file in .cursor/agents/ has a model: line whose value matches its lane:, or is deliberately inherit. List every mismatch.
3. No model ID appears anywhere outside docs/MODEL_ROUTING.md and the agent frontmatter — grep -rn the four chosen IDs across AGENTS.md, .cursor/rules/, and .cursor/skills/. A hit there is the exact drift this kit is built to prevent.
4. One live dispatch: send scout a trivial read-only task with the Task tool. A successful return proves the model ID, the account's access to it, and project-subagent discovery in one shot. An unknown-model error means step 3 used an ID this account cannot select — fix it now, not on the first real task.

Return

Routing (the four lanes as written) · Left on inherit (which agents, and why) · Files changed (paths) · Picker action for the operator (the exact lead model to select) · Verification (the four checks and the live dispatch result) · Degradations (collapsed lanes, Auto on lead, unavailable models) · Next action.