task-classification

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