Run a cheap classifier before the planner — it labels the task so template, context, and model tier adapt downstream, instead of forcing your expensive planner to do categorization work it's not built for.

Guide

How to classify work before planning

Why a classifier step

Don't make your planner also be your classifier.

Planner-onlytwo jobs, one call

inraw task input

↓

01infer task type + planexpensive

↓

outgeneric plan, wrong template

Categorization burns planning capacity. One template fits all — so nothing fits well.

Classifier-firstright tool per step

inraw task input

↓

01classify → labelcheap

↓

02plan with matched templateexpensive

↓

outlabel-shaped plan, right context

Label first, plan second. Planning capacity goes to planning — nothing else.

If you skip the classifier, every plan is a generic plan — the planner has to infer task type from task content and wastes tokens doing it.

The reading path

Six nodes, in order — principle first, artifact last.

01

Classification Precedes PlanningPrinciple

The foundational rule. Classification is a dedicated prior step — not an inference the planner makes. Establishes why the ordering matters.

02

Cost-Quality Is a KnobPrinciple

Classification is a small-label decision — cheap models are correct here. Reserves high-capability tiers for the planning step that follows. Right model per step, not cost-cutting.

03

Adaptive Template ActivationPattern

How the label is consumed. Template sections become conditional on the classification result — a bugfix plan activates different sections than a feature plan.

04

Classification GatePattern

The deployment shape. A gate that holds the pipeline until classification completes, then routes to the matching planning path. Turns the label into a structural decision.

05

CommandPrimitive

The classifier is a slash command — defined scope, output contract, hand-off shape. Clarifies how invocation and hand-off to the planner happen without ambiguity.

06

PlanPrimitive

The artifact classification shapes. Read last to see concretely what varies by label: section presence, context bundle, model selection, constraint set.

Read top-to-bottom. Each node earns the next — skip ahead and the later nodes lose their justification.

What the pipeline actually looks like

One classifier, three downstream paths.

/task — raw request, no label

↓

/classify

small-label decision — bug | feature | refactor

cheap tier

↓

label: bug

• repro section
• root-cause ctx
• regression test
• narrow scope

label: feature

• intent section
• design ctx
• acceptance tests
• broad scope

label: refactor

• invariants
• behavior-equivalence
• existing test suite
• no-new-behavior

The label is a structural decision, not a hint. It selects which template sections render, which files load, which constraints bind.

What actually varies per label

Four dimensions — section presence, context, model, constraints.

Sections

repro + fix

intent + design

invariants

Context

failing file + callers

adjacent features, APIs

full module + tests

Model tier

mid

high

high

Constraints

minimize diff

match existing patterns

preserve behavior

Same planner, same agent — different instructions, context, and tier per label. The classifier is the switch.

The discipline

Label first, plan second — never the same call.

A planner fed unclassified work produces generic plans. A cheap classifier upstream turns one label into four downstream decisions: which sections render, which files load, which tier runs, which constraints bind. Planning capacity stays on planning.