← Plugin catalog
Productivity

Adaptive Task Routing

哲儀 朱 v0.5.0

Choose when to keep or switch

Create a free account to save this plugin.

From the developer

Not specified in the available declarations: capabilities, limitations, pricing & account requirements.

Onboarding example

Use adaptive task routing before the next substantial phase.
Sources & dates

Developer declarations; not independently tested. Listing last checked Nov 6, 2026. Package observed Nov 6, 2026.

View package source →

Description

From the marketplace listing

Adaptive Task Routing assesses conversation, model and reasoning resources at meaningful task boundaries. It shows the action to take now before a concise reason, distinguishing task-fit settings from whether a switch is worthwhile. Keeping a suitable setup and retaining provisionally under uncertainty are separate outcomes. Default ask confirms proposed changes or material blockers; retention and nonblocking defer continue only already authorized work. Plan-only requests never authorize implementation. Auto applies only justified, authorized, callable and verifiable changes. Compact uses a plain heading and one conversation sentence. Verified keep shows only the observed current AI; detailed adds task-fit alternatives, minimum settings and upgrade rationale. Ordinary changes ask only about the target setting. Actual savings and reliability improvements require evidence.

Language: English · Automatically detected from descriptions.

Matches for “changes”

Exact text from the indicated source. A mention alone does not establish support for your task.

Publisher full description

Adaptive Task Routing assesses conversation, model and reasoning resources at meaningful task boundaries. It shows the action to take now before a concise reason, distinguishing task-fit settings from whether a switch is worthwhile. Keeping a suitable setup and retaining provisionally under uncertainty are separate outcomes. Default ask confirms proposed changes or material blockers; retention and nonblocking defer continue only already authorized work. Plan-only requests never authorize implementation. Auto applies only justified, authorized, callable and verifiable changes. Compact uses a plain heading and one conversation sentence. Verified keep shows only the observed current AI; detailed adds task-fit alternatives, minimum settings and upgrade rationale. Ordinary changes ask only about the target setting. Actual savings and reliability improvements require evidence.

What changed

Keywords

Files & skills

File archives

Plugin package43 files · 354 KBBrowse files →
Skill instructions
adaptive-task-routing11.3 KB

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 o

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

research-model-router21.3 KB

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 ad

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

task-context-router9.51 KB

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

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

Package details

Publisher declarations from the archived package. These are separate from our research and the live service's terms.

Package license
MIT
Package author
Adaptive Task Routing contributors
Keywords
See keywords

Package observed Nov 6, 2026.

Technical details
First seen
Sep 30, 2026 · 22:02 UTC
Last seen
Nov 6, 2026 · 18:00 UTC
Collection status
Collected

plugins_6aa58f86c9588191a1301728fbff6c46

Download plugin data (JSON)

Plugin details: freshly prepared. Prepared . Refreshed when plugin data changes or after 6 hours. Your account and Follow status are live.