← Files Adaptive Task RoutingARCHIVED FILE

skills/adaptive-task-routing/SKILL.md

11.3 KB · Sep 30, 2026 · 23:16 UTC

↓ Download file

---
name: adaptive-task-routing
description: Primary routing entrypoint for substantial multi-step coding, debugging, architecture, validation, research, analysis, audits, and scans, and for conversational commands that inspect or change both routing modes. Use after a requested analysis or plan identifies actionable next work, or before executing a substantial phase, when both conversation context and model/reasoning should be assessed. Prefer this coordinator over either child router for general tasks. Skip brief explanations, status checks, tiny edits, and ordinary plugin-only questions.
---

# Adaptive Task Routing

Coordinate two independent decision skills. Do not choose a context, model, or reasoning effort yourself. Host-native startup context or prompt hooks may remind the model to invoke this entrypoint, but all eligibility and routing decisions remain in this Skill. Mentioning the plugin is not evidence that this Skill ran.

Read [references/zh-TW.md](references/zh-TW.md) when Chinese guidance is needed.

## Gate and controls

Before testing gate eligibility, handle direct mode-inspection or mode-change commands under the shared policy. A user can switch `ask`, `auto`, or `off` in normal conversation. A command naming Context or Model changes only that child; an unqualified Adaptive Task Routing mode command changes both independent modes. Confirm the two effective values and scope concisely without emitting a routing note. If the same turn also requests substantial work, apply the new mode before routing that work. A mode change by itself does not authorize the work discussed earlier.

Route a substantial next phase only after its plan or preceding analysis is ready and before that phase begins. Substantial multi-step analysis, inspection, audits, scans, research, and planning qualify even when the user requested findings only and did not authorize implementation. Complete that authorized deliverable first; when its findings identify actionable changes, validation, or follow-on research, treat those actions as a concrete substantial next phase and append routing advice. A cross-file release-flow, cross-platform consistency, or test-gap scan is not a merely informational query. When the user already authorized execution, first prepare a concise actionable plan, using bounded non-mutating discovery when needed, then route before mutation or other substantial execution. Do not invent extra work after a complete answer with no concrete follow-on phase. Reuse a gate already completed for the same phase, context, catalog, preferences, and capabilities.

Read [shared policy](../../shared/runtime-routing-policy.md) and [defaults](../../shared/defaults.yaml), except when the generated Gemini dependency appendix is present: that appendix is the self-contained runtime contract and no external shared read or sibling activation is needed. Outside that generated package, resolve these paths from the directory containing this `SKILL.md`: the plugin root is three directories above this file, and shared resources are under `<plugin-root>/shared`, never `<plugin-root>/skills/shared`. Resolve the two user modes independently: `off`, `ask`, or `auto`. There is no third coordinator mode or separate fixed-routing policy. If both are `off`, skip routing, capability probing, and routing output. For one disabled router, skip its decision and continue with the other; the context stays current when context routing is off.

## Sequence

1. Establish the plan that the routing decision will govern. For a plan-only or analysis-only request, finish and present the requested findings and plan before the routing note. For an execution request, present a concise actionable plan first, but do not begin mutation or substantial execution.
2. For an enabled context gate, load and follow [task-context-router](../task-context-router/SKILL.md) as a coordinator-delegated call. The generated Gemini package appends a dependency appendix to this file because one Skill activation grants access only to that Skill directory; when that appendix is present, use its complete context-router instructions directly and do not attempt a second Skill activation. Otherwise read the packaged child file or use the host-provided Skill resource. Supply the fact that the full coordinator is active so the child's direct-selection guard does not dispatch back. It alone owns `CURRENT`, `HANDOFF`, `CLEAN`, and any handoff. A later model-only phase transition can reuse the resolved context.
3. Resolve the effective working context under that router's mode. In `ask`, continue immediately when the recommendation is `CURRENT`; when a change is recommended, pause and ask whether the user wants it. If declined, retain the current context and continue. If accepted, perform callable and verifiable operations; for `user_only` parts, provide the necessary handoff and let the user resume naturally in the destination without requiring a confirmation word. If a destination is awaiting confirmation, combine recommendations only when its model options are known; otherwise report model routing as deferred pending destination confirmation, with currently observable model/effort or `unknown`. Recheck in the destination before execution.
4. For an enabled model gate, load and follow [research-model-router](../research-model-router/SKILL.md) as a coordinator-delegated call, explicitly supplying the resolved effective context and completed or proposed plan so its direct-selection guard does not dispatch back. When the generated Gemini dependency appendix is present, use its complete model-router, host, registry, and shared-policy instructions directly. It alone owns model/effort judgment. Load the child even if the host did not independently select it. If neither packaged content, generated appendix, nor a host Skill resource is accessible, report that component as unavailable rather than inventing its result. Never synthesize a child result from the coordinator description or memory.
5. Present the requested findings and plan before one compact routing note. Read and follow [routing UX](../../shared/routing-ux.md), or its embedded Gemini copy. Start the note with a divider and plain `Adaptive Task Routing` heading, then lead with the combined action and reason. Keep one enabled conversation sentence visible before useful AI settings. Both routers still compute their own results; presentation does not select settings or hide unavailable components.
6. In `ask`, pause only before a proposed environment change or for a material blocker. Retain and nonblocking defer continue already authorized work without a routing confirmation. A plan-only request never authorizes implementing the plan. In `auto`, apply only justified, authorized, callable and verifiable changes; use the actual fallback and stop if a material blocker remains. Do not require a fixed confirmation word. Revalidate after manual changes. Context and Model modes remain independent; a retained model never overrides a pending context decision.

During an active coordinated run, child routers do not call this coordinator or each other. A child selected directly by the host may dispatch once to this coordinator under its direct-selection guard; the coordinator-delegated marker prevents recursion. Read only the children needed for the gate, and reuse an already loaded policy without repeating identical work. Keep gate state in the current session and persist only capability/catalog cache records allowed by the shared policy; do not create persistent activity logs.

Identify the effective host surface once and carry that evidence into both children. For OpenAI surfaces, never default to Codex App merely because the prompt does not name the interface. If host metadata or the user does not identify CLI versus App, the model router must use the bounded automatic surface check in the OpenAI host guide before choosing a probe scope.

When combining results, preserve task requirements, discovery limits, both task-based settings and the separate switch assessment in structured evidence. Never show those English enum tokens or source/probe diagnostics in ordinary output. Use `Task-fit setting` / `任務適配設定` for the internal `recommended_setting`; it is not an instruction to switch. Unknown current settings require provisional language, not a claim that the setup is suitable. Context-off and model-only do not imply an assessed conversation.

For Traditional Chinese the shared UX contract uses `### Adaptive Task Routing`, a localized action and reason, then a plain conversation sentence such as `對話:留在目前對話,不需開新對話。`. Localize every label and description to the user's language. Compact retains that line even when no model change is advised. Detailed adds minimum needed, task-fit setting and upgrade rationale without rerunning an unchanged gate. No third routing mode is introduced.

## Later phases and limitations

Pass the effective context decision and continuity rationale, including handoff/setup cost, to the model router. A declined handoff uses the current conversation; context-off passes current placement with no suitability claim. Route at task boundaries, not every prompt. Do not infer cache locality from the context enum. Preserve the model router's separate `switch_assessment` as well as both task-based settings: its `upgrade_value` is not the value of changing from the current setup. Express its practical consequence in the action-first reason; keep switch scoring internal under the UX contract. In `auto`, a router-initiated model/effort change additionally requires `decision: change`; retain or defer keeps the configuration while authorized work continues. User-selected settings take precedence. Reuse an unchanged gate; no persistent phase or activity log is needed.

Revisit model routing when implementation becomes validation, a pilot expands, mechanical processing becomes interpretation, or difficult evidence synthesis begins. Revisit context routing only when there is also a genuine context boundary. Do not repeat a routing note on every tool call or unchanged follow-up.

Resolve every host operation separately. A desktop/web/mobile App may allow automatic context creation while keeping current-model or effort changes user-only; a CLI can also expose mixed capabilities. Act only through available, authorized operations and verify the outcome. An interactive command intended for the user is not agent capability. Shared settings and injected reminders are instructions, not proof that the host invoked the Skill; the packaged host integrations make the reminder deterministic where those integrations are supported.

## Compact presentation invariants

Use the exact heading `### Adaptive Task Routing` without a subtitle. Verified model keep shows
only the observed current pair in compact; reserve task-fit alternatives for detailed output.
Context advice is one sentence stating whether to open a new conversation, not a window field.
For analysis/plan-only output, the complete findings and plan precede the divider; the routing
note is the final section. Action-first applies inside the note. Use the shared canonical action
line unchanged, with a separate short reason; any proposed implementation remains conditional.
An ordinary change asks only about the target setting. Provisional keep also covers uncertain
switch costs or benefits, not just an unknown current model. Follow the shared UX contract for
independent modes, pending context decisions and task authorization.

SHA-256: a61201c05ca96c72040784e35052fb5bf6f0150e2505b948e40020b51c06e164