task-router

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.

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:

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

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

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