Skill v1.0.0
currentLLM-judged scan90/100version: "1.0.0" name: task-classification description: Use at the very start of a task, before anything else, to decide how much process it deserves — chat / trivial edits / simple docs get done immediately; design / build / exploration enter the loop. Judge by blast radius, not by how long the request was. Part of meta-workflow (Step 0).
Step 0 — Classify the task (the throttle)
Why this exists: the cost of process must stay below the cost of the mistake it prevents. There are two opposite failures here, and most workflows only guard against one:
- Running a full loop on a typo — process as theater.
- Straight-lining a one-line change to shared infrastructure — a real mistake shipped fast.
This step is the throttle that avoids both.
The pre-check (do this first, it's the one people skip)
Is this message starting a new task, or pushing forward / signing off an in-flight heavy one? A short reply — "yes", "do B first", "ship the second one too" — that advances heavy work inherits that work's weight. Do not re-classify it by the literal size of the sentence.
(Inheriting weight ≠ re-running the full loop for every sub-action; a sign-off or wrap-up sub-step runs at its own actual risk, but the acceptance bar stays at the original task's level.)
Then classify (only for genuinely new tasks)
| Type | Examples | Weight | |
|---|---|---|---|
| Chat / Q&A | explain a concept, look up a value, "what is X / will Y happen" | answer directly | |
| Trivial edit | typo / config / single line, and the change touches nothing shared | just do it, no self-check | |
| Simple doc / code | one small function, doc wording, touching nothing shared | do it + light wrap-up check | |
| Design | mechanism / architecture / skill design, selection, design docs | full loop ①→⑤, weight ①②④ | |
| Build | multi-stage feature / pipeline, cross-file change, or any "fix" whose change lands on shared infra | full loop, weight ② per-stage acceptance + ④ per-stage verify | |
| Exploration | the goal itself can only be set by exploring | open loop (if budgeted) |
The iron rules
- Judge by where the change lands, not by how long the message is. Anything touching shared
infrastructure — hooks, schedulers, pipelines, eval, rules, automation, persistent state docs — is heavy even if it looks like "a small bug." Definition/architecture → Design; concrete feature/fix → Build; both run the full loop.
- A metric claim (a number + a metric word: recall, precision, cost, coverage, latency…)
appearing → heavy by default, when this turn will actually produce a change. Pure explanation / diagnosis / questions about infra do not escalate — unless that diagnosis will drive a heavy decision or act as a quality gate.
- When unsure, go heavier.
Output
State the task class and the weight you'll run at. Then proceed: trivial → do it; design/build → go to clarify-intent (Step ①).