PRD-01 · SEC. 04 Product & Planning

Complexity-Gated Scoping Before Any Build

Classify a task's complexity first, then gate execution behind your approval so agents stop over- or under-building.

FORMAT: workflow
DIFFICULTY: intermediate
TIME: 15 min
TOOLS: claude-code · cursor · codex-cli
MODELS: any
COPIES: 0 so far

When to use this

You're about to hand an agent a task and you don't yet know if it's a 10-minute tweak or a multi-file redesign. Skip this and you either get a five-line fix for something that needed a migration plan, or a full rewrite for something that needed a one-liner.

The pattern

Pastes as plain text

Before writing any code, classify the complexity of the task I describe below the line.

Pick one tier and justify it in 2-3 sentences:
- TRIVIAL: single file, no new dependencies, no schema or API changes.
- MODERATE: multiple files or one new dependency, no breaking changes to existing contracts.
- COMPLEX: schema changes, new APIs, cross-cutting changes, or anything that breaks an existing contract.

Then list exactly what you'd touch (files, schemas, APIs) for this tier. Do not write any implementation code yet. Stop and wait for my go-ahead.

My task:

Real example output

"CLASSIFICATION: MODERATE. This touches the `orders` table (new `refund_status` column) and two files (`api/orders.ts`, `components/OrderCard.tsx`). No breaking changes to existing endpoints since the column is additive and nullable.

Files to touch: `db/migrations/`, `api/orders.ts`, `components/OrderCard.tsx`.

Waiting for approval before implementing."

Why it works

Naming three fixed tiers gives the model a forced choice instead of open-ended judgment, which is what keeps a "fix this typo" request from turning into a refactor. The explicit stop-and-wait step is the actual gate: it moves the scope decision to you before any code exists, so rework happens on a plan, not a diff.