Smart Dispatch

Smart Agent & Model Dispatch (Pro Edition)

Stage input — consume the EXEC-MAP contract if present

If an EXEC-MAP v1 block from senior-prompt-engineer is in context, consume it instead of re-deriving complexity:

• EXEC-MAP.effort seeds the tier (trivial/low → Tier 0; medium/high → Tier 1).
• EXEC-MAP.models is the per-phase routing intent (plan→Opus/quality, impl→Sonnet/balanced, mechanical→Haiku/budget); honor it unless validation proves it wrong.
• EXEC-MAP.executor picks the provider/CLI; map model tiers to that CLI's tiers.
• EXEC-MAP.mcp lists tools to wire up.
• Preserve router, router_mode, router_confidence, and router_fallback losslessly in the dispatch contract; do not rename or recompute them. Treat the map as a starting routing decision, not gospel — escalation rules (Tier 1) still override it when validation keeps failing. With no EXEC-MAP, derive routing from the request as usual.

Optional combination parameter: combine_smart_subagents

When smart-sub-agents is installed, support this parameter in the dispatch request:

combine_smart_subagents: ask | always | never

The default is ask, but ask only when the task has explicit provider/model/effort requirements, needs more than one provider/harness, or would materially benefit from isolated parallel subagents. Use this exact question once:

Combine this dispatch with smart-sub-agents to pin the harness, provider, model, and effort and render a subagent configuration? (yes/no)

• yes or always: invoke smart-sub-agents, consume its ROUTE-MAP v1, and preserve its explicit route unless validation proves it unavailable.
• no or never: continue with the normal smart-dispatch matrix and do not ask again for the same task.
• If the user already supplied combine_smart_subagents, honor it without asking.

The combined route must log both the requested and effective harness/provider/model/effort. A provider fallback is visible and auditable; STOP/Ctrl+C or an explicit cancellation must not retry or fall back.

If smart-sub-agents is unavailable, state that fact and continue with the standard dispatch table. Do not recreate its catalog inside this skill.

Tier 0 — Automated Boilerplate & Verification (RTK Bypass)

0.1 Local-First Rule

Before dispatching to an AI agent for Tier 0 tasks, attempt to solve it using local CLI tools.

• Lint: Run npm run lint --fix or eslint --fix.
• Formatting: Run prettier --write.
• Typecheck: Run tsc and check if errors are trivial.

0.2 RTK Bypass Dispatch (The "Hammer")

If local tools fail or aren't enough, use Gemini-Flash YOLO via RTK.

• Lint/Typecheck/I18n/Tests: Route to rtk gemini --yolo.

0.3 Verification Mandate

Any agent dispatched in YOLO/Bypass mode MUST execute the relevant validation command before completion.

• If it fixed types, it must run tsc --noEmit.
• If it fixed lint, it must run npm run lint.
• If it fixed tests, it must run npm run test <file>.

0.4 Decision-router benefit gate

Do not pay for a separate routing inference when a local command, explicit user route, or obvious static row already decides the task. For substantive or ambiguous turns, smart-sub-agents may use its optional learned decision router. Keep these invariants:

• A typed decision scorer chooses tier, effort, risk, and delegation shape; the selected worker still performs the work.
• Explicit user routes override scorer preferences; without one, low confidence, timeout, malformed output, or missing credentials fails open to balanced.
• Safety floors apply last as a monotonic lower bound and cannot be downgraded.
• Run the learned router once per meaningful phase, not once per tool call.
• Start new policies in shadow mode and calibrate thresholds from validation outcomes; raw confidence is not portable across workloads.
• Log requested/effective route, confidence, latency, validation result, and fallback reason without logging secrets or full prompt bodies.

Tier 1 — Escalation & Intelligence Mapping

1.0 Task-Type → Model Routing (default table)

Always pick the cheapest tier that passes validation; escalate per 1.1. Tiers map per provider:

Use named workers when the harness supports custom agents. Prefer the cheapest worker that still fits the task. Codex: Luna mechanical, Terra implementation, Sol architecture/root-cause. Claude: Haiku / Sonnet / Opus. OpenCode: prefer Go lane when subscribed; else Zen free.

Budget contract (mandatory on every dispatch)

Announce before work:

DISPATCH
worker: <name>
tier: budget|balanced|quality
effort: low|medium|high|xhigh|max
router: heuristic|typed-scorer
router_mode: heuristic|shadow|advisory|enforce
router_confidence: 0.00-1.00|unavailable
router_fallback: ask|static-catalog|balanced|none
tokens: <range from taskRouting>
time: <range from taskRouting>
verify: <command>

Source of truth: plugins/smart-sub-agents/references/provider-matrix.json → taskRouting + workerMatrix. Refresh models: python3 plugins/smart-sub-agents/scripts/sync_provider_matrix.py --write Reinstall workers: python3 plugins/smart-sub-agents/scripts/install_worker_matrix.py

EXEC-MAP's models: {plan, impl, mechanical} maps 1:1 to quality/balanced/budget rows above.

1.1 Auto-Escalation Policy

If a Tier 0 agent fails to resolve the issue (validation still fails) after 2 attempts, the dispatcher MUST:

1. Stop using the "cheap" model.
2. Escalate the task to a Tier 1 model (Claude Sonnet or Gemini Pro).
3. Notify the user: "Escalating to [Model] due to persistent validation failures."

1.2 Capability Matrix

Rules

• Announce & Verify: Always say what you are doing and how you will verify it.
• Token Economy: Prefer Gemini Flash for context-heavy reads but simple edits.
• Fail Fast: Don't loop on cheap models. Escalate early.
• Local First: CLI tools > AI Agents for mechanical fixes.