Task Intake Router

Task Intake Router

Copilot CLI gives you multiple execution paths: interactive mode, Plan Mode, Autopilot, task agents, /fleet, background delegation, and per-agent model selection. This skill turns an incoming request into an explicit routing decision so you do not default to the wrong mode out of habit.

Why This is Copilot-Exclusive

The value is not generic triage. The value is mapping work onto Copilot CLI primitives that can be combined in one session:

• Plan Mode for structured decomposition
• Autopilot for execution after approval
• task agents for typed delegation (explore, task, general-purpose, code-review)
• /fleet for parallel fan-out
• Background delegation for cloud execution on GitHub
• Per-agent model overrides for cost/quality optimization

When to Use

• A new request arrives and it is unclear whether to answer, plan, implement, review, or delegate
• The task could be handled in several ways and you want the highest-leverage path
• You need to decide between local execution, /fleet, or cloud background delegation
• You want an explicit model plan before spending premium tokens on the wrong step

When NOT to Use

Routing Dimensions

Every request should be classified on five dimensions:

1. Intent — explain, investigate, implement, review, or operate
2. Scope — one file, many files, or cross-cutting
3. Dependency shape — sequential or parallelizable
4. Risk — low, medium, or high consequence if wrong
5. Runtime fit — local-only, GitHub-native, or cloud-friendly

Core Routing Matrix

Workflow

1. Classify the Request

Use a short intake prompt:

> Route this request before acting:
> - Goal
> - Scope
> - Risk
> - Parallelizable? yes/no
> - Best Copilot CLI mode
> - Best agent type
> - Recommended model

Aim for a routing output like:

Mode: Plan Mode
Agent type: general-purpose
Model: gpt-5.3-codex
Parallelism: none until scope is confirmed
Reason: multi-file implementation with ambiguous boundaries

2. Pick the Execution Mode

3. Pick the Agent Type

If one task needs multiple types, split it:

1. explore for discovery
2. general-purpose for implementation
3. code-review for a quality gate

4. Pick the Model Tier

Use multi-model-strategy for detailed guidance, but the default routing rule is:

Use model pairs when that reduces risk:

• Implementer: gpt-5.3-codex
• Reviewer: claude-sonnet-4.6 or gpt-5.4

5. Decide Whether to Fan Out

Ask two questions:

1. Can subtasks be assigned clear file or domain ownership?
2. Would two agents need to edit the same files?

If the answer to the second question is yes, do not fan out yet.

Good fleet candidates:

• one test file per module
• one review lens per concern
• one migration unit per directory

Bad fleet candidates:

• a tightly coupled refactor in the same files
• a debugging task with unknown blast radius
• anything waiting on a still-unclear design choice

6. Store the Decision in SQL

For larger sessions, make the route explicit:

CREATE TABLE IF NOT EXISTS intake_routes (
  id TEXT PRIMARY KEY,
  request_summary TEXT NOT NULL,
  mode TEXT NOT NULL,
  agent_type TEXT,
  model TEXT,
  parallelism TEXT,
  next_skill TEXT,
  rationale TEXT
);

INSERT INTO intake_routes (
  id, request_summary, mode, agent_type, model, parallelism, next_skill, rationale
) VALUES (
  'route-auth-refactor',
  'Refactor auth flows across API, tests, and docs',
  'plan-mode',
  'general-purpose',
  'gpt-5.3-codex',
  'sequential-then-fleet',
  'sprint-workflow',
  'Multi-file change with early ambiguity, then parallelizable test/doc work'
);

7. Hand Off Cleanly

A routing decision is only useful if it hands off to a concrete next move:

• Plan Mode → create or approve the plan
• Autopilot → execute the approved plan
• task agent → launch the right typed agent
• /fleet → define task boundaries and ownership
• Background delegation → prepare the prompt for a GitHub branch or PR workflow

Examples

Example 1: Ambiguous Feature Request

Request: "Add rate limiting to our API"

Route:
- Mode: Plan Mode
- Agent type: general-purpose
- Model: gpt-5.3-codex
- Next skill: sprint-workflow
- Why: cross-cutting change with design choices and test requirements

Example 2: Large Batch of Independent Docs

Request: "Add JSDoc to all exports in src/utils/"

Route:
- Mode: /fleet
- Agent type: general-purpose
- Model: gpt-5-mini
- Next skill: fleet-parallel
- Why: many independent files with low coupling

Example 3: Security Review of a Risky PR

Request: "Review this auth PR before merge"

Route:
- Mode: task delegation
- Agent type: code-review
- Model: claude-opus-4.7
- Next skill: pr-multi-perspective-review
- Why: high-risk review deserves a specialized pass

Common Rationalizations

Red Flags

• The request changes multiple systems but has no explicit route
• A high-risk task is being handled with the cheapest possible model by default
• /fleet is chosen before ownership boundaries are defined
• A cloud delegation is started even though local context or uncommitted state matters
• Routing output says "we'll decide as we go"

Verification

• The request has an explicit mode, agent type, and model choice
• The chosen route matches the task's dependency shape
• High-risk work includes a stronger review path than low-risk work
• Any fan-out plan names file or domain boundaries
• The route points to a concrete next skill or action

Tips

• Route before you execute: 30 seconds of intake can save hours of rework
• Split hybrid work: one route for discovery, another for implementation, another for review
• Prefer clear handoffs: every route should name the next skill, mode, or agent
• Re-route if the facts change: new complexity means the original route may no longer fit

See Also

• multi-model-strategy — choose the right model once the route is known
• team-planner — design specialist teams for large multi-domain work
• background-agent — delegate long-running GitHub-side work
• fleet-parallel — parallel execution once ownership is clear
• sprint-workflow — end-to-end feature delivery after routing