adaptive-model-routing/SKILL.md

name, description

name

description

adaptive-model-routing

Route project and software work between gpt-5.6-terra and gpt-5.6-sol according to complexity and risk, using Terra for most execution and Sol only for bounded planning or independent acceptance. Use for non-trivial implementation, refactoring, debugging with code changes, architecture work, project planning, code review, acceptance, or whenever the user asks to reduce token usage or cost through Sol/Terra model selection.

Adaptive Model Routing

Minimize expensive reasoning and duplicated context without weakening correctness. Keep the workflow continuous: completing a plan is not a reason to pause for user approval.

Classify the Request Intent

Classify intent before scoring risk:

• Plan-only: Produce only the requested plan. Use Terra for R0 and a bounded Sol planner for R1/R2. Ending after the requested plan is task completion, not an approval pause. Do not implement.
• Review or acceptance-only: Use a fresh gpt-5.6-sol reviewer with fork_turns="none" when the user requests independent review or acceptance. Apply the audit limits below: at most 1,200 words of prose input and a normal response under 500 words. Report findings or PASS/FAIL. Do not implement fixes unless the user authorizes changes.
• Implementation: Follow the R0/R1/R2 lifecycle below and continue automatically through its required verification.

Do not expand a plan-only or review-only request into implementation.

Route the Task

Score the task before changing files:

• Add 2 for a public API or incompatible schema change.
• Add 2 for security, privacy, money, data integrity, concurrency, destructive actions, or live external state.
• Add 2 when a missing user choice could materially change the product or architecture.
• Add 1 for a cross-module change, unfamiliar architecture, or a new external integration.
• Add 1 for ambiguous requirements, weak tests, or a historically fragile area.
• Add 1 after two unsuccessful implementation or test-fix attempts.

Choose the smallest sufficient route:

• R0 (0-1): Terra execution. Execute and self-verify. Do not create a planning or review agent.
• R1 (2-3): Sol plan, Terra execution. Use one bounded Sol planning pass. Let Terra implement and verify. Add a Sol audit if evidence is incomplete, execution departs materially from the plan, or the user explicitly requests acceptance.
• R2 (4+): Sol plan, Terra execution, fresh Sol audit. Require an independent Sol audit after tests.

Use R2 regardless of score for incompatible public API or schema changes; security, privacy, money, data-integrity, or concurrency risk; destructive actions; or writes to live external state.

Override the score when the user explicitly requests a particular model or workflow, but do not weaken the mandatory R2 safety floor unless the user knowingly accepts the reduced assurance after the risk is stated. Prefer the safer route when classification is genuinely uncertain.

Delegate with Bounded Context

For every implementation route, use gpt-5.6-terra as the executor. If the active agent is not Terra, explicitly delegate execution with fork_turns="none", including for R0.

For R1 and R2, explicitly delegate the planning task to gpt-5.6-sol. Use fork_turns="none" and send only a compact planning packet. Use medium reasoning for R1 and high reasoning for R2 unless the task requires otherwise. Keep the prose packet under 1,200 words, reference repository paths instead of pasting large files, and never forward the full conversation.

Use this planning packet:

Goal:
Relevant repository state:
Constraints and non-goals:
Likely files or components:
Known risks:
Requested output: concise implementation plan and executable acceptance criteria only.

Limit the normal Sol plan to 800 words and ten implementation steps.

After receiving the plan, delegate implementation to gpt-5.6-terra unless the active agent is already Terra. Use fork_turns="none" and send the plan plus only the task-local evidence needed to edit and test safely. Keep the Terra prose packet under 1,600 words, reference repository paths instead of pasting large files or diffs, and do not forward the full conversation.

For R2 auditing, create a fresh gpt-5.6-sol agent with fork_turns="none". Give it the original goal, acceptance criteria, changed-file list, diff statistics, and test evidence. Let the auditor inspect repository paths directly instead of pasting a large diff. Keep the audit packet under 1,200 words and the normal audit response under 500 words. Ask for PASS or FAIL, blocking findings, and missing evidence. Do not tell the auditor the expected conclusion.

If an exact model override or subagent facility is unavailable, keep the same planner, executor, and auditor roles with the available model and state the limitation briefly.

Execute and Verify

Require the Terra executor to:

1. Inspect the relevant source before editing.
2. Preserve unrelated user changes.
3. Implement only the user-authorized or requested scope. The generated plan does not require separate user approval unless a pause condition below applies.
4. Run proportionate lint, typecheck, tests, and targeted runtime checks.
5. Return a compact evidence packet:

Changed:
Validation commands and results:
Acceptance criteria status:
Deviations from plan:
Remaining risks:

Keep the normal Terra evidence response under 600 words. Summarize command results and reference saved logs rather than pasting large outputs.

Never treat a plan, a diff summary, or a passing mock alone as acceptance evidence.

Handle Audit Failures

Send concrete blocking findings back to Terra for correction. Once a Sol audit is required, send every corrected candidate to a fresh Sol auditor and do not declare acceptance until it returns PASS. Allow at most two normal fix-and-verify-and-audit rounds before asking Sol to re-plan. Ask the user only when the remaining blocker requires new authority, an irreversible action, or a product choice that cannot be inferred safely.

Continue Without an Approval Pause

Proceed automatically from planning to implementation to verification. Pause only when:

• the user explicitly asks to approve the plan first;
• an irreversible or materially destructive action needs approval;
• the task would expand materially beyond the requested scope;
• a missing user decision would change the outcome substantially.
• required credentials, tool authorization, or other new authority are unavailable.

Report the Route

In the final handoff, state the route used (R0, R1, or R2), summarize validation evidence, and identify any unresolved risk. Report measured token or cost savings only when usage data is available; never infer savings merely from using Terra.