| 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 ①).
