The template, the context reads, and the acceptance bar are all type-dependent — so a cheap classifier must decide the kind-of-thing before the expensive planner opens its mouth.

Principle

Classification Precedes Planning

Why classification is first

The plan's shape is the type.

Three issue types. Three different templates. The planner's first decision is which one to fill.

/chore

task listvalidation cmds— no user story— no root cause

/bug

steps to reproduceroot-cause analysis— no user story— no phases

/feature

user storythree-phase implacceptance criteria— no repro steps

Different templates demand different context reads and different acceptance bars.

If the planner doesn't know the type, it cannot know which template it's filling in.

The division of labor

Cheap agent decides. Expensive agent executes.

Step 1 · Classifier

/classify_issue

reads✓ title✓ body

✗ no codebase

✗ no architecture docs

outputs/chore``/bug``/feature``0

cheap · small prompt · Sonnet

→

Step 2 · Planner

/plan (template pre-selected)

reads✓ full issue

✓ codebase structure

✓ architecture docs

outputsplan.md — sharp, single-template

expensive · big context · no wasted reasoning

Expensive reasoning on a cheap question is waste.

A three-field JSON output buys the planner its entire template — before it loads a single file.

Why the order is load-bearing

Classify after the plan and the classifier can only rubber-stamp.

Same two agents. Run them in reverse and everything collapses.

Plan → Classify✗ broken

1.planner guesses a template

↓

2.plan commits to it

↓

3.classifier rubber-stamps

Scope creeps at template-selection time. What should have been a chore becomes a refactor. The classifier has no decision left to make.

Classify → Plan✓ correct

1.classifier picks template

↓

2.planner fills the template

↓

3.plan matches the type

Template is fixed before the plan is written. The planner cannot drift into feature-shaped work while solving a bug-shaped issue.

The separation is not bureaucracy — it's the only way the planner's reasoning can stay on the work instead of on the wrapper.

What violation looks like

Four ways to skip the gate — all produce template soup.

Every one of these collapses into the same failure mode.

✗

Feed a generic "plan it" prompt to every issue.

The planner hedges — "appears to be a bug, so I'll add steps to reproduce, but I'll also add a user story just in case." Every section from every template, none sharp.

✗

Classify after the plan is written.

The plan already picked a template. The classifier can only confirm the mistake.

✗

Ask the planner to self-select its own template.

Expensive reasoning pass consumed on a question a three-field classifier answers for pennies.

✗

Use the same template for chore, bug, and feature.

Scope creeps. A chore grows a three-phase implementation. A bug grows a user story. The template is doing the drifting.

The discipline

Decide the kind-of-thing before you decide what to do about it.

The classifier is a gate, not a formality. Skip it and the planner pays for both decisions with the expensive agent — and still ships a plan that fits no template sharply.