Adaptive Task Routing

View saved version →

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

Referenced files: 1

View saved version →

---
name: research-model-router
description: Model-only child router for substantial coding, debugging, architecture, validation, research, or analysis, and for conversational inspection or changes of the model-routing mode. Use when the user explicitly asks only for model/reasoning advice or mode control, when adaptive-task-routing delegates with a resolved context, or at a later model-only phase transition. For a general task needing both context and model routing, dispatch to adaptive-task-routing instead. Skip ordinary chat and tiny operations; do not choose context.
---

# Research Model Router

Match an upcoming work phase to enough model capability for reliable work without unnecessary time or compute. The historical name is retained for compatibility; the scope includes implementation and validation as well as research and analysis. This skill routes configuration; it does not perform the task itself.

For Traditional Chinese guidance, read [references/zh-TW.md](references/zh-TW.md) only when the user prefers Chinese or the Chinese explanation is needed.

## Required shared runtime policy

Before making a routing decision, read and follow [../../shared/runtime-routing-policy.md](../../shared/runtime-routing-policy.md) and [../../shared/defaults.yaml](../../shared/defaults.yaml). They define environment detection, preference precedence, executor selection, persistence boundaries, and fallback behavior for every router in this plugin.

If the host cannot load a plugin-level reference, preserve these minimum invariants: separate user intent from runtime capability; lightly revalidate capability at every routing gate; treat saved capability as a non-authoritative hint; default unknown capability to user operation; and claim `applied` only after verified host execution.

## Direct-selection dispatch guard

Before doing model discovery or emitting output, determine why this Skill was loaded. Continue locally only when the user explicitly requested model/reasoning-only routing or model-mode control, the `adaptive-task-routing` coordinator supplied a resolved effective context and marked this call as coordinator-delegated, or a previously completed coordinator gate is being revisited for a genuine model-only phase transition. Handle a model-mode inspection/change immediately under the shared policy: confirm the effective value and scope without model discovery or a recommendation. For any general substantial task where Context and Model routing have not both been resolved, stop this child workflow, read [adaptive-task-routing](../adaptive-task-routing/SKILL.md), and follow that coordinator once. Do not emit a standalone model result before dispatch. Pass an internal `delegated_from: research-model-router` marker; when the coordinator reads this Skill again with its coordinator-delegated resolved-context marker, continue here and never dispatch again.

## Routing gate

Run after the plan or preceding analysis for the upcoming phase and the effective working context are known, before that phase begins. For a plan-only or analysis-only request, the recommendation follows the requested deliverable and applies to its concrete substantial next phase. For an execution request, a concise actionable plan appears first, and this gate runs before mutation or substantial execution. A caller can supply the resolved context. Direct use stays model-only only under the direct-selection guard above.

When delivering an improvement plan with a concrete substantial next phase, include a model/effort recommendation for that phase before yielding, even if execution awaits approval. Advice does not authorize implementation. If a final answer has no substantial next phase, do not invent one or add a new routing gate just to end the response. Before difficult final evidence synthesis, route before doing that synthesis.

Re-run only at a meaningful stage transition: pilot to expanded workload, retrieval or execution to interpretation, robustness or adversarial testing, routine transformation to difficult reasoning, or final evidence synthesis. Do not re-route for every tool call or ordinary chat.

## Decide

First describe `task_requirements`: the phase's capability needs, relative reasoning demand, quality/validation needs and latency/usage constraints. This judgment does not depend on knowing the current model. Then produce two independent task-based results: `minimum_sufficient_setting`, the least costly pair likely to meet those requirements, and `recommended_setting`, the best-value pair after considering ambiguity, error cost, validation depth, latency and usage. The two pairs may be identical. Always record `upgrade_value` in structured evidence (`low`, `medium`, or `high`) and a concrete `upgrade_reason` describing what the recommended pair is expected to add over the minimum. Do not suppress useful task guidance when discovery is incomplete.

When observations are missing or stale, follow the matching [host discovery guide](../../shared/host-discovery.md). Resolve `../../shared` from the directory containing this `SKILL.md`: it is `<plugin-root>/shared`, not `skills/shared`. In a permitted Codex environment the guide links to [the optional read-only probe](scripts/probe_codex.py); do not run that helper on Claude/Gemini or assume ChatGPT has access to the user's CLI. Excluding a subagent menu only rejects that source: continue to an applicable host read path or fresh, scoped observation. Do not conclude that the main-context catalog is unavailable merely because the visible menu is for subagents. If the Codex helper identifies a project-sandbox state-access failure, stop after that attempt and follow the host guide's versioned bundled-registry fallback without requesting extra read permission. In a positively identified OpenAI host, including ChatGPT desktop/web and Codex App/CLI, unavailable runtime metadata does not suppress the two concrete settings: use the unexpired bundled registry as a cross-surface recommendation reference and label account availability `unverified` only in structured evidence. Its CLI observation proves availability only for that observed CLI, while its dated official capability source supports recommendations on the listed OpenAI surfaces. Do not ask the user to transcribe selector options before giving those recommendations. Record any attempted read and outcome before falling back. Prefer an applicable runtime catalog, use official model descriptions only as scoped capability evidence, and use relevant task evaluations when available. Keep inferred recommendations distinct from measured results.

For verified runtime decisions, recommend only a `model` and `reasoning_effort` supported by the current environment. For a matching unexpired registry fallback, recommend only pairs recorded in that registry and label their account availability `unverified`. Never invent identifiers.

Reasoning controls are platform-native. The rubric's `low`, `moderate`, and `high` task demand is internal analysis, not proof that those strings are selectable settings. On Gemini CLI, use an exact observed `thinkingBudget` or `thinkingLevel` only when it is configurable in the effective session. Otherwise render `Reasoning: model default`, localized to the user. Never output bare Codex-style `low`, `medium`, or `high` as a Gemini setting without matching Gemini control evidence.

Resolve the catalog's scope instead of copying a probe's initial `unverified` label. Follow the host guide's surface-specific invocation and criteria. In an identified Codex CLI task, invoke the helper with `--surface codex-cli`. When CLI versus App is not explicitly identified, invoke it with `--surface auto`; do not guess App. Automatic detection may use a standalone CLI process ancestor or the exact thread's stable `source: cli` when tool isolation hides that ancestor; the latter identifies the interface without treating saved model/effort as live. Accept a fresh successful CLI catalog marked `applicability: verified` unless positive evidence shows an availability-changing launch mismatch. The helper's separate process, unreadable live settings, absence of an App bridge, or inability to prove that no hidden override exists must not invalidate that CLI catalog. Runtime descriptions and supported effort options can support a capability-based recommendation without benchmarks. If scope is still unresolved, name the actual conflicting evidence; neither unknown current values nor an unrelated failed metadata read is a catalog failure.

Judge technical difficulty, ambiguity, dependent reasoning steps, evidence volume and heterogeneity, validation needs, consequence of subtle errors, synthesis or critique demands, latency and compute cost, and whether the phase is execution-heavy or interpretation-heavy.

- Prefer fast, economical settings for clear retrieval, formatting, extraction, and deterministic transformations.
- Prefer balanced settings for ordinary multi-step research and analysis.
- Prefer stronger capability and higher effort for ambiguous methodology, difficult synthesis, robustness review, consequential conclusions, or tightly coupled technical decisions.
- Reassess after the demanding phase ends; lower settings only when the expected remaining-phase benefit justifies switching cost.
- Treat missing source data, unavailable history, unresolved definitions and external bottlenecks as limits on upgrade value: more model capability cannot manufacture evidence.

Treat model and effort as a pair. Use the lowest effort likely to satisfy the task for the minimum setting. A stronger model does not automatically require maximum effort, and most tasks do not require `max` or `ultra`. Keep both internal settings task-based even when the current pair is suitable; report retention separately rather than overwriting the minimum or recommendation with the observed pair. Do not hide concrete recommendations behind `CURRENT / CURRENT`.

### Assess whether to switch

Follow the shared policy's [phase continuity and switching value](../../shared/runtime-routing-policy.md#phase-continuity-and-switching-value) contract after selecting both task-based settings and before applying either model or effort. Route at task boundaries, not every prompt. The coordinator supplies the effective context and continuity rationale; a declined handoff or disabled context router must not be treated as a new destination.

Prefer model stickiness when the observed current pair meets the quality floor. Evaluate remaining-phase gains against switching cost and context locality, including setup, latency, retries and rework. Unknown cache evidence is not zero cost or certain cache loss. Conversation retention does not establish cache reuse; reasoning-only changes also require assessment. Quality deficits can justify a change despite cache uncertainty. A new context still has setup costs and does not force a new model.

Produce `switch_assessment` separately from `upgrade_value`: compare the observed current pair with `recommended_setting`, record `switch_value` (low, medium, high, or unknown), `decision` (retain, change, or defer), and a reason. Unknown current settings require unknown switch value and deferred automatic switching, without suppressing the two concrete task settings. If uncertain costs could reverse the decision, retain or defer rather than fabricating net savings. An already matching pair has low switch value and is retained. Only `decision: change` permits a router-initiated change in `auto`; explicit user setting requests take precedence and still require callable, verifiable controls.

Use the shared UX contract to express the switch assessment in the action and its reason. Keep scoring internal; detailed output adds concise comparison rationale. Retain/nonblocking defer do not require routing confirmation; a material blocker does. A task-fit recommendation is not an applied change.

Read current configuration and available options separately from exposed runtime metadata or user-provided settings. A catalog of supported models is not evidence of which model is running. Mark each unreadable current field `unknown`; use `unsupported` only when the host confirms that reasoning effort is not configurable.

Resolve the recommendation independently of whether it can be compared or applied:

| Available evidence | Decision |
| --- | --- |
| Applicable candidates, supported effort options and capability evidence are sufficient; current pair is unknown | Give concrete minimum and recommended pairs. Current values and whether a switch is needed remain unknown. Do not substitute `CURRENT / CURRENT` solely because live settings cannot be read. |
| Current pair is known and supported by capability evidence | Give both task-based pairs by their concrete names, compare the observed pair with them, and assess switching value. Retain the current pair when justified. Recommend an alternative only with sufficient evidence. |
| A model recommendation is supported, but its effort options are unknown | Record the model in both internal settings, retain effort as `CURRENT` with uncertainty in evidence, and use native supported controls in the visible task-fit setting. Relative task demand is not an invented selector value. |
| Runtime discovery is blocked on a recognized OpenAI surface, but the unexpired bundled registry has model descriptions and effort options | Stop after the failed read and give concrete minimum and recommended fallback pairs without asking the user to transcribe the selector. Treat the registry as cross-surface recommendation evidence, while keeping account availability and current settings unverified. Apply only through independently verified switch controls in `auto`; follow routing-ux.md for authorized continuation, a justified change or a material blocker. |
| Gemini CLI live selector metadata is unavailable, but the unexpired Gemini CLI registry applies | Recommend only its stable aliases (`auto`, `pro`, `flash`, or `flash-lite`) using the recorded task guidance. Never guess a concrete backend model because alias resolution is account-dependent. Use the model's default reasoning behavior unless an exact native thinking control is observed. Do not ask for `/model` before giving the fallback recommendation. |
| Relevant bounded discovery leaves insufficient catalog or capability evidence to choose a pair, and no recognized-product bundled reference applies | Show task requirements, the attempted source and outcome or concrete access limitation, and the missing evidence. Provisionally retain `CURRENT / CURRENT` with `assessment: unverified`, or ask once for selector options when an exact choice is necessary. Do not call this proof of suitability. |

Lack of an automatic switching tool affects execution, not the ability to recommend evidenced pairs. `upgrade_value` compares the recommended pair with the minimum sufficient pair, never with an unknown current setting. In `ask`, present the recommended pair as task guidance and defer automatic switching when the current pair is unknown; do not describe it as an upgrade or downgrade from the unknown setting.

## When the user questions a recommendation

Do not request broader read permission during the normal fallback path. If the user says the recommended model or effort looks wrong, asks why it was chosen, or explicitly requests an account-specific check, then disclose the useful diagnostic facts: whether the recommendation used runtime data or the bundled reference, the reference observation and expiry dates, that account availability is unverified when applicable, and the task factors that led to both pairs.

After that explanation, ask once for narrowly scoped read permission only when the current host exposes a concrete path that the permission would unlock and that path can query the same effective App/session with `model/list` or equivalent metadata. Name the exact read and why it would improve the answer. Generic filesystem, network, CLI, or approval permission is not useful if it can only inspect another process or cannot reach the current selector; do not request it. If no matching read path exists, say so and optionally ask the user to share the selector only when they still want an account-specific comparison. If the user declines, continue with the reference recommendation and do not ask again until the surface, permission state, or explicit request changes.

## Apply the user's control mode

Resolve this router's mode independently. Follow [routing UX](../../shared/routing-ux.md).

- `off`: skip this router and its output.
- `ask`: ask before a justified model/effort change, or when a material quality blocker needs a user decision. Retain and nonblocking defer require no routing confirmation; continue only already authorized work. An unknown current pair alone does not prove a blocker or suitability.
- `auto`: only `decision: change` permits a router-initiated switch, subject to authorized, callable and verifiable operations. Otherwise retain the actual configuration; continue authorized work only without a material blocker. An unavailable control does not prove that an inadequate configuration is safe to use.

A plan-only request never authorizes implementation. Respect an explicitly selected target without another confirmation. Combine genuine pending questions with the context router only for a known destination.

## Output

Use the [shared UX contract](../../shared/routing-ux.md). Keep `minimum_sufficient_setting`, `recommended_setting`, `upgrade_value` and `upgrade_reason` in structured evidence. `recommended_setting` is displayed as **Task-fit setting / 任務適配設定**. Compute both task-based settings internally. Verified keep requires a reliably observed model and native reasoning configuration, phase-specific quality evidence and evidence supporting retention. A generic model-default label is not a model identity. Use the shared canonical action line on its own line; keep unknown retention provisional without overriding context actions, explicit targets or blockers. Verified keep in compact shows only the observed current pair; task-fit alternatives appear only in detailed output. Provisional keep can still show a useful task-fit pair, including when current settings are known but switching benefit or cost is uncertain. Do not overwrite them with the current pair to justify retention.

Put the requested plan or preceding findings before the routing note. Lead with the action and one-sentence reason, then useful settings. A standalone invocation uses a divider and plain `Adaptive Task Routing` heading (`### Adaptive Task Routing`); a delegated invocation returns its result to the coordinator and must never emit a second divider or heading. Model-only output makes no conversation suitability claim.

Show current settings only when observed and useful; never print `Current: unknown / unknown`. Unless diagnostics are requested, do not mention the probe, fallback/registry source, freshness, scope or internal scores. Never render the schema or internal evidence in ordinary compact output. Read [the evidence schema](references/evidence-schema.md) only for diagnostics or maintenance. Detailed presentation adds minimum needed, task-fit setting and upgrade rationale; it is not a new gate.

### Select the action paragraph

For `retain` or `defer`, do not append `/model`, selectors or invitations to apply the target. Use a positive keep action only with suitability evidence; otherwise use provisional retention. When authorized work can continue, say what continues and proceed without asking. When only a plan was requested, finish the plan without implementing it. When a material blocker exists, identify it and ask a concrete question; do not ask whether to keep current just because metadata is missing.

For `decision: change` or an explicit user-selected target, use controls known for the effective surface:

- ChatGPT desktop/web: 如需採用建議，可使用介面中的模型與推理強度選單調整。Do not include the CLI-only `/model` command.
- Identified Codex CLI: `/model` is a user control, not an agent-callable operation.
- Gemini CLI: 目前環境無法代為切換模型；Reasoning 使用模型預設。Only show `/model` for a justified change or explicit target. Native reasoning is `Reasoning：使用模型預設` unless an exact supported control is observed.

In `ask`, ask only whether to use the named target for an ordinary change; reserve plan changes for a material blocker; do not require a fixed confirmation word. In `auto`, report only verified application or the actual fallback, and continue authorized downstream work only when no material blocker remains. Never say “applying” merely because switching was recommended.

## Coordination boundary

This skill decides **how much model capability the work needs**. `task-context-router` decides **where the work runs**. Keep them separate and use this order:

```text
requested analysis or plan → task-context-router → resolve context
→ research-model-router → resolve action and authorization → execute or ask for a real decision
```

The [coordinator](../adaptive-task-routing/SKILL.md) owns this full sequence. This Skill dispatches to it only when the host selected the child for a general task before Context routing; it never performs the Context decision itself. Explicit model-only invocation remains valid. At later substantial phase transitions, re-run only this Skill when a completed Context decision is still valid; use the coordinator when a genuine context-boundary question also appears. Neither router expands permissions or authorizes unrelated external actions.

Referenced files: 3

View saved version →

---
name: task-context-router
description: Context-only child router that chooses CURRENT, HANDOFF, or CLEAN and handles conversational inspection or changes of the context-routing mode. Use when the user explicitly asks only for context advice or mode control, or when adaptive-task-routing delegates. For a general substantial task needing both context and model routing, dispatch to adaptive-task-routing instead. Do not choose a model or reasoning effort.
---

# Task Context Router

Choose the working context before substantial execution. This skill routes the task; it does not perform the task itself.

For Traditional Chinese guidance, read [references/zh-TW.md](references/zh-TW.md) only when the user prefers Chinese or the Chinese explanation is needed.

## Required shared runtime policy

Before making a routing decision, read and follow [../../shared/runtime-routing-policy.md](../../shared/runtime-routing-policy.md) and [../../shared/defaults.yaml](../../shared/defaults.yaml). They define environment detection, preference precedence, executor selection, persistence boundaries, and fallback behavior for every router in this plugin.

If the host cannot load a plugin-level reference, preserve these minimum invariants: separate user intent from runtime capability; lightly revalidate capability at every routing gate; treat saved capability as a non-authoritative hint; default unknown capability to user operation; and claim `applied` only after verified host execution.

## Direct-selection dispatch guard

Before deciding Context or emitting output, determine why this Skill was loaded. Continue locally only when the user explicitly requested context-only routing or context-mode control, or the `adaptive-task-routing` coordinator marked this call as coordinator-delegated. Handle a context-mode inspection/change immediately under the shared policy: confirm the effective value and scope without evaluating Context. For any general substantial task where both Context and Model routing are expected, stop this child workflow, read [adaptive-task-routing](../adaptive-task-routing/SKILL.md), and follow that coordinator once. Do not emit a standalone Context result before dispatch. Pass an internal `delegated_from: task-context-router` marker; when the coordinator reads this Skill again with its coordinator-delegated marker, continue here and never dispatch again.

## Routing gate

When the coordinator delegates a plan-only or analysis-only request, run after that requested deliverable is complete and before its substantial next phase. For an execution request, run after a concise actionable plan exists and before mutation or substantial execution. A direct context-only request may run as soon as the request is understood.

Reconsider at a genuine task boundary: a substantially different objective, the transition from exploration to a stable downstream phase, a context crowded with irrelevant or conflicting history, or a phase requiring isolation or reproducibility. Do not invoke for every small follow-up.

## Decide

Return one recommendation:

- `CURRENT`: keep the current conversation when the task depends on recent discussion and the context remains coherent.
- `HANDOFF`: move to a new context with a compact handoff when the next phase needs selected conclusions and constraints, not the full exploration history.
- `CLEAN`: use a new context without task history when independence, blind evaluation, contamination control, or a truly unrelated task outweighs continuity.

Judge dependency on prior turns, relevance of accumulated context, stale-instruction or anchoring risk, whether a concise handoff preserves all requirements, expected next-phase complexity, isolation needs, switching cost, and actual host capabilities.

Return the effective context and a continuity rationale for the coordinator to pass to model routing: what information remains useful, what must be reconstructed, and any handoff/setup cost. This informs switching value but does not choose a model. A retained conversation is not proof of a prompt-cache hit; a new conversation does not make configuration changes cost-free. If the user declines a handoff, pass the retained context, not the proposed destination. When this router is off, the coordinator reports current placement without claiming it was assessed.

Do not recommend a new context merely because the task is difficult. Do not use `CLEAN` when losing prior requirements creates avoidable risk. If the host cannot create a new context, report the recommendation without claiming it was applied.

Identify the effective execution destination separately from the visible client (web, desktop, phone or terminal). A local shell or a new CLI process does not prove the current App can create or transfer a conversation. Preserve source/time/scope on capability observations; a destination's unreadable model settings must not block context-only advice. Do not fetch a model catalog for this router. A handoff may carry labeled configuration hints, never assume they remain current or supported in the destination.

## Apply the user's control mode

Resolve this router's mode independently of the model router. A current-turn instruction wins over stored preferences. If no mode is available, default to `ask`.

- `off`: do not evaluate; remain in the current context and emit no recommendation.
- `ask`: when the result is `CURRENT`, continue without interrupting. Before a recommended context change, ask whether the user wants it. If declined, continue in the current context. If accepted, perform the approved operation when it is callable and verifiable; otherwise give the user known manual steps and let them resume naturally in the destination without requiring a confirmation word.
- `auto`: apply automatically subject to availability, permissions, and safety constraints.

`off` means the router does not run. `ask` is the default interactive mode. When both routers require confirmation, combine their choices into one concise prompt when accurate, while preserving independent controls.

## Output

Follow [routing UX](../../shared/routing-ux.md): lead with the context action and reason, and always include one localized sentence explaining whether a new conversation is needed when enabled. A recommended change is not an applied change. In a coordinated run, return the result for one combined note; do not emit a separate block. Continue only authorized work, and never let a retained model suppress a pending handoff or missing destination decision.

Use the shared canonical action line unchanged and keep its short reason on a separate line.

Keep `CURRENT`, `HANDOFF`, and `CLEAN` as stable values in structured evidence only. In compact user-facing output, show a plain-language description localized to the user's language and do not append the enum in parentheses. For Traditional Chinese use “留在目前對話,” “切換到新對話並帶入精簡交接,” or “開啟全新對話，不帶入目前脈絡,” as applicable.

```yaml
skill: task-context-router
recommendation: CURRENT | HANDOFF | CLEAN
confidence: 0.00-1.00
reason: one concise task-specific explanation
mode: off | ask | auto
disposition: skipped | awaiting_user_confirmation | awaiting_user_action | applied | kept_current
handoff_required: true | false
runtime_capabilities:
  surface: identified surface or unknown
  create_new_context: agent | orchestrator | user_only | unavailable | unknown
  create_handoff_context: agent | orchestrator | user_only | unavailable | unknown
  evidence: runtime metadata | user-provided settings | cached observation | unavailable
  observed_at: timestamp | unknown
  confidence: 0.00-1.00
execution:
  requested_owner: agent | orchestrator | user | none
  effective_owner: agent | orchestrator | user | none
  status: skipped | awaiting_user_confirmation | awaiting_user_action | applied | retained_current | blocked
  reason: concise explanation
  manual_action: null | surface-specific instruction
```

For `HANDOFF`, also provide only the state needed in the destination:

```yaml
handoff:
  objective: current objective
  confirmed_requirements: []
  decisions_and_rationale: []
  relevant_artifacts: []
  current_state: concise status
  unresolved_questions: []
  next_action: first useful step
```

Never include secrets, irrelevant history, hidden reasoning, or a transcript. For `CLEAN`, do not attach a task handoff.

When the host exposes only user controls, provide the exact action for that surface plus the handoff when needed. An interactive command visible to the user is not an agent capability unless the agent can actually invoke and verify it.

## Coordination boundary

This skill decides **where work runs**. `research-model-router` decides **which model and reasoning effort run it**. Keep them separate and use this order:

```text
requested analysis or actionable plan → task-context-router → resolve context
→ research-model-router → resolve action and authorization → execute or ask for a real decision
```

The [coordinator](../adaptive-task-routing/SKILL.md) owns this full sequence and loads the model router after this Skill returns. This Skill dispatches to the coordinator only when the host selected it for a general task; it never chooses the model itself. A direct context-only request stays context-only.

If context routing awaits the user, the coordinator defers final model selection until the destination is known, unless both recommendations can be presented accurately in one prompt. If the user declines an `ask` recommendation, the effective context stays current. Neither router expands permissions, creates unrelated work, or authorizes external side effects.

Referenced files: 1