| name | task-router |
| version | 2.0.0 |
| user-invocable | false |
| description | Auto-activated at the start of every non-trivial conversation. Parses true intent before classifying, enforces the pre-flight checks that weaker models skip, and routes to the correct workflow. Trigger: always — no keyword required.
|
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.
-
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.
-
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.
-
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:
| Type | Route to | Real signals (not just keywords) |
|---|
code-change | coding-workflow skill | User wants something to exist that doesn't yet, or wants existing code restructured. The end state is different code. |
bug-fix | debug-workflow skill | Something that used to work (or should work) doesn't. There is a gap between expected and actual behavior. |
research | Inline protocol below | User wants understanding, not changes. They need information to make their own decision. |
review | Inline protocol below | User wants evaluation of existing code/output, not modification. |
distill | distill-session skill | User wants to extract patterns from model behavior. Trigger: "distill", "learn from". |
trivial | Answer directly | See the strict definition below. |
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
- State what you will look for (2-3 specific targets)
- Search in parallel — read files, grep, use LSP tools simultaneously
- Stop when you have enough to answer — do not over-explore
- Answer with evidence: file paths, line numbers, specific code snippets
- If uncertain, say so. Do not pad uncertainty with confident-sounding prose
review → inline protocol
- Read the full artifact — never review from memory or from partial reads
- Evaluate against stated requirements, not personal style preferences
- 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
- 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
| Situation | Action |
|---|
| Same approach fails twice | Your mental model is wrong. Discard it. List your assumptions, invert the least certain one, form a new hypothesis. |
| 3+ cumulative failures | Stop all edits. Restore to last known good state. Report what you tried, what you learned, and what you need from the user to continue. |
| Tool error or timeout | Apply file-operation-fallback skill if available. Otherwise, report the error — do not silently retry the same thing. |
| You realize mid-execution that the plan is wrong | Stop. Do not finish a plan you know is wrong. Go back to planning with the new information. |
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
