model-router

Model Router

Turn a task into an explainable, executable provider plan. This skill advises; it does not authorize or invoke paid provider work.

Procedure

1. State the task goal and concrete deliverables.
2. Decompose compound requests into model-sized steps. Keep steps separate when they have different modalities, privacy boundaries, or validation methods.
3. Capture hard constraints: modality, quality, latency, privacy, region, license, budget, local-versus-hosted preference, and required output format.
4. Query all relevant live provider tools. Use the exact provider contract in provider-contract.md.
5. Eliminate candidates that violate a hard constraint. Do not rank an infeasible candidate above a feasible one because its quality looks better.
6. Compare the feasible set. Separate observed evidence from provider claims and unknowns.
7. Select a primary model and ordered fallbacks. A recommendation may remain a Pareto set when quality, cost, privacy, and latency cannot be reduced to one honest score.
8. If the selected provider/model requires a credential, add a plain-language Secret setup section naming the provider-native login or exact host environment variable. Do not ask for the value before model selection, and do not write or echo it.
9. Emit a JSON plan conforming to model-task-plan.schema.json.
10. Set consent.status to pending whenever any step spends credits, transmits data, changes provider state, or creates an externally visible artifact.
11. Hand the plan to model-task-execution; do not call the provider yourself.

Credential Boundary

All provider credentials are optional until the user selects a model and operation that needs one. Public discovery and planning may proceed without any API key. After selection, route hosted providers through their native login and local providers through the exact host environment variable or approved secret storage. Never create a credential value, print it, persist it in a plan, or request it in chat.