maptasks

What this skill does

# maptasks — Route Engineering Work to the Right Model

## Overview

Given a specified engineering task (or set of tasks), produce a **routing plan** that:

1. Checks whether the task is broken down enough to route. If not, proposes a finer breakdown first.
2. Categorizes each leaf work unit using a 30-category task taxonomy.
3. Assigns each unit to the best-suited model based on practitioner evidence (April 2026).
4. Explains *why* this model is best for *this* category — citing the rule or evidence.
5. Specifies the **context briefing** each model needs to do its job.
6. Flags model-specific failure modes to watch for.

The skill is evidence-driven, not vibes-driven. Every recommendation traces to a category lookup or a numbered decision rule.

### The Three-Tier Strategy (always implicit)

Every routing plan should distribute work across three tiers in roughly these proportions:

| Tier | Share of work | Models |
|---|---|---|
| **Flagship reasoning** | 5–10% | Opus 4.6, GPT-5.4 Pro, Gemini 3.1 Pro |
| **Balanced mid-tier** | 40–50% | Sonnet 4.6, GPT-5.4, GPT-5.3-Codex, Gemini 2.5 Pro |
| **Cheap / fast** | 30–40% | Haiku 4.5, GPT-5.4 mini/nano, Gemini 3 Flash |

A routing plan that uses only one tier (all Opus, or all Sonnet) is almost always wrong. The two failure modes to avoid:

1. **Verbose model on shallow task** → cache thrashing, quota exhaustion (Opus on boilerplate).
2. **Speed model on hard reasoning** → "fast failure" — race conditions and memory leaks discovered after merge.

The skill prevents both by forcing each unit through category lookup → tier check → model selection.

## When to Use

- You have a fully or partially specified task and are about to execute it with AI assistance.
- You want to assemble a multi-model team (e.g. Architect + Implementer + Reviewer).
- You're choosing between two or more models for a specific piece of work and want the comparison.
- You want a routing plan *before* spinning up subagents or parallel sessions.
- You want to know whether a task description is decomposed enough to be routable at all.

**Do NOT use this skill for:**
- Picking a chat model for casual conversation.
- Reviewing the quality of code (use `kiss`, `solid-principles`, `beyond-solid-principles`).
- Estimating timelines or effort in person-hours.

## Inputs

The user provides one of:

1. A task description (e.g. "Implement OAuth2 login with Google, update schema, add tests, update docs").
2. A pre-broken-down task list (markdown or bullets).
3. A spec / PRD / GitHub issue / file path.

If anything critical is missing, ask for it before routing:

- **Scope**: How many files? What's the language/framework/stack?
- **Constraints**: Privacy (can data leave your infra?), ecosystem (Google/JVM/.NET), latency.
- **Cost posture**: cost-optimized, balanced, or quality-first?
- **Done criteria**: How will you know each unit is finished?

If the user describes a team type or role context (solo MVP dev, senior in production codebase, frontend startup, backend team, migration team, docs team, agentic CLI workflow, privacy-constrained/air-gapped), pre-load the matching default stack from `references/rules.md` Part 3 — Persona-Based Routing Scenarios — and use it as the starting policy before applying category lookups.

## Workflow

```
1. INGEST          → Read task / spec. Identify scope and constraints.
2. SUFFICIENCY     → Run Breakdown Sufficiency Check on each unit.
3. DECOMPOSE       → If any unit fails, propose finer breakdown BEFORE routing.
4. CATEGORIZE      → Map each leaf unit to one of the 30 task categories.
5. SELECT          → Apply category lookup, then decision rules to pick a model.
6. BRIEF           → Build the context briefing for each unit.
7. EMIT            → Output the routing plan in the standard format.
```

### Step 2: Breakdown Sufficiency Check

A work unit is **routable** only if all five hold:

| # | Criterion | Failing example |
|---|---|---|
| 1 | Belongs to exactly **one** task category | "Implement and test" — split |
| 2 | Requires exactly **one** model tier | "Plan and write docs" mixes flagship + mid — split |
| 3 | Produces a **single artifact** (one file, one plan, one review) | "Build OAuth flow" — split |
| 4 | Fits in **one context budget** (no mid-task re-injection) | "Migrate the whole repo" — chunk by module |
| 5 | Has **measurable done criteria** | "Make it better" — define done |

If any criterion fails, **propose a finer breakdown before routing**. Don't route an under-decomposed unit; you'll just push the routing problem onto the model.

### Step 5: Selecting the Model

1. **Category lookup** (Quick Reference table below) gives you a primary + runner-up.
2. **Apply decision rules** (Rules section below) to resolve ties or special cases.
3. **Check constraints**: privacy → local model; ecosystem → Gemini for Google stack; long context → Gemini 2.5 Pro.
4. **Sanity check**: cite the category number AND the rule number in the rationale.

## Model Roster

| Model | Tier | Sweet Spot | Context (usable) | $/M in | $/M out |
|---|---|---|---|---|---|
| **Claude Opus 4.6** | Flagship | Architecture, multi-file refactor, complex debug (race / cross-boundary), security audit, 7h+ autonomous | 1M (~400K reliable) | $5 | $25 |
| **GPT-5.4 Pro** | Flagship | Computer use (75% OSWorld), mid-task steering, native tool chaining | 1M | $30 | $180 |
| **Gemini 3.1 Pro** | Flagship | Frontier reasoning, frontend/UI, Google ecosystem (Go/Dart/Flutter/Angular) | 1M+ | $2-4 | $12-18 |
| **Claude Sonnet 4.6** | Mid | The 80% model: daily features, bug fixes, tests, docs, API/SQL design, frontend components | 1M (~400K reliable) | $3 | $15 |
| **GPT-5.4** | Mid | Structured output (~100% strict), tool/function calling, greenfield iteration | 1.05M | $2.50 | $15 |
| **GPT-5.3-Codex** | Mid | Terminal/DevOps/IaC (77.3% Terminal-Bench), code review, long-horizon autonomous (25h) | 400K | $2.50 | $15 |
| **Gemini 2.5 Pro** | Mid | Long-context analysis, whole-codebase summarization, data analysis, R workflows | 1-2M | $1.25 | $10 |
| **Claude Haiku 4.5** | Fast | Sub-agent workhorse, classification, boilerplate, strict JSON adherence | 200K | $0.80 | $5 |
| **GPT-5.4 mini** | Fast | Routine code, sub-agent, "almost indistinguishable from full" on simple tasks | 400K | $0.75 | $4.50 |
| **GPT-5.4 nano** | Fast | Classification, extraction, guardrails, high-volume pipelines | 400K | $0.20 | $1.25 |
| **Gemini 3 Flash** | Fast | Cost king for coding (78% SWE-bench at $0.50/MTok), default in JetBrains/Replit/Warp | 1M | $0.50 | $3 |
| **Codex-Spark** | Speed | Rapid prototyping drafter (1,000+ tok/s, 15x faster than Codex). Pair with Opus reviewer (Pattern B) | varies | varies | varies |
| **Qwen3-Coder-Next** | Local | Privacy-bound or offline coding (consumer hardware), Apache 2.0 | 128K | free | free |
| **Gemma 4** | Local | Local function calling, structured output, RAG (Apache 2.0) | varies | free | free |

Full profiles, weaknesses, and failure modes → `references/models.md`.

### Context Decay (the "1M Token Myth")

Advertised context windows ≠ usable context. Empirical retrieval accuracy:

| Model | 256K accuracy | 1M accuracy | Decay rate | Practical max |
|---|---|---|---|---|
| **Claude 4.6 Opus** | 92.1% | 78.3% | **15%** | ~400K reliable |
| **GPT-5.4** | 79.5% | 36.6% | **54%** | ~7,500 LoC reliable |
| **Gemini 3.1 Pro** | 35.0% | 25.9% | 26% | ~15,000 LoC (no cross-file reasoning) |

**Routing implication:** Long-context jobs should be routed by *task type*, not by raw window size:
- **Retrieval / summarization >200K** → Gemini 2.5 Pro (1–2M, generous free tier)
- **Cross-file reasoning >200K** → Claude Opus 4.6, but chunk to stay under 400K
- **Whole-codebase analysis with no precision needed** → Gemini 2.5 Pro
- **Anything past Opus 400K threshold** → switch to Gemini 2.5 Pro for that sub-task

### Mixed-Model Workflow Patterns

When more than one model collaborates on a task, use a named pattern. Full