zadanthony/meta-workflow/task-classification

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)

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