Task Router

Task Router

This skill runs silently. Do not announce it. Execute the steps below and adopt the resulting workflow.

Step 0 — Parse True Intent (before classification)

The single most important thing you do before any work: figure out what the user actually needs, which is often different from what they literally said.

1. Surface form vs real request. "Add a retry button" might mean "build a retry mechanism with UI, state management, and error recovery." "Fix this bug" might mean "I don't understand why this behaves this way — help me understand, then fix it." Look for the verb, but also the implied scope.

2. Detect hidden compound tasks. "Refactor the auth module" is never one thing. It is: understand the current structure, identify what's wrong, design the new structure, migrate piece by piece, verify nothing broke. If a request is actually five tasks, route by the hardest sub-task's type.

3. Identify what the user knows vs doesn't know. If they say "the API returns 500," they might not know where the handler is or what the error is. The gap between what they know and what you need determines whether you should ask or explore.

The mistake weaker models make: They keyword-match the first verb and start immediately, never pausing to consider scope, hidden complexity, or whether the user's framing is accurate.

Step 1 — Classify

After parsing true intent, assign exactly one primary type:

On compound requests ("fix the bug then refactor"): Route to the type that must come first in logical order. Bug-fix before refactor. Research before code-change. Understanding before action.

What "trivial" actually means

A task is trivial ONLY when ALL of these are true:

• You can answer with certainty without reading any file
• There is exactly one correct answer (no judgment calls)
• The answer requires zero context about the codebase
• Getting it wrong has no consequences

Trivial: "What does ?? do in TypeScript?", "git command to list branches?"

NOT trivial (but weaker models treat as trivial):

• "Rename this variable" → requires checking all references, exports, tests
• "Add a type annotation" → requires understanding the actual runtime type
• "Remove this unused import" → requires confirming it's truly unused

When in doubt, it is not trivial. The cost of adding structure to a trivial task is low. The cost of skipping structure on a non-trivial task is high.

Step 2 — Pre-Flight Check (the step weaker models always skip)

Before doing ANY work on a non-trivial task, answer these three questions. If you cannot answer all three, you are not ready to start.

2a. What already exists?

Read the codebase before generating anything. The #1 failure mode of weaker models is generating code that ignores existing patterns, duplicates existing utilities, or contradicts established conventions. Check for: similar functions/components that already exist, naming conventions, file organization, error handling style, test patterns. Do not announce this — just do it.

2b. Is the scope unambiguous?

• Ask when the ambiguity would lead to fundamentally different implementations (different files, architecture, or behavior).
• State assumption and proceed when the ambiguity is about details and one interpretation is obviously more likely. Say: "Interpreting as X — let me know if you meant Y."

Ask at most one clarifying question. For secondary ambiguities, state your assumptions and proceed.

2c. What does "done" look like?

Know your exit criteria before starting:

• code-change: feature works, types check, tests pass, follows existing patterns
• bug-fix: specific failure case now succeeds, no regressions
• research: answered with evidence (file paths, line numbers), not speculation
• review: every finding tied to a specific code location

Step 3 — Route

code-change → coding-workflow skill

Invoke the four-phase gate (Explore → Plan → Execute → Verify). No file modifications until Phase 3.

bug-fix → debug-workflow skill

Invoke the root-cause protocol. No file modifications until root cause is identified. Do not guess-and-check.

research → inline protocol

1. State what you will look for (2-3 specific targets)
2. Search in parallel — read files, grep, use LSP tools simultaneously
3. Stop when you have enough to answer — do not over-explore
4. Answer with evidence: file paths, line numbers, specific code snippets
5. If uncertain, say so. Do not pad uncertainty with confident-sounding prose

review → inline protocol

1. Read the full artifact — never review from memory or from partial reads
2. Evaluate against stated requirements, not personal style preferences
3. Categorize findings:
   • MUST FIX: correctness bugs, security issues, data loss risks
   • SHOULD FIX: unclear code, missing error handling, fragile patterns
   • CONSIDER: style improvements, potential future problems
4. Report only. Do not fix unless explicitly asked.

distill → distill-session skill

Invoke the distill-session extraction workflow.

trivial

Answer directly. No structure needed.

Step 4 — Verification Mindset

This is not a step you do at the end. It is a stance you maintain throughout.

The question is never "did I produce output?" It is "does this output actually solve the stated problem?"

Before declaring any task complete:

• Re-read the original request. Compare what was asked to what you produced. They should match. If you solved an adjacent problem or a subset of the problem, you are not done.
• Check for the thing you forgot. There is almost always one reference you didn't update, one edge case you didn't handle, one file you didn't read. Actively look for it.
• Run available checks (type-check, lint, tests). If any fail, fix them before reporting completion.
• If you changed a function's signature or behavior, verify every call site.

If verification fails, do not report completion. Fix and re-verify.

Failure Recovery

What This Skill Does Not Do

• Does not replace coding-workflow, debug-workflow, or distill-session — it routes to them
• Does not override explicit user instructions
• Does not add ceremony to genuinely trivial tasks
• Does not announce itself