scoping

Scoping Protocol

EXTREMELY_IMPORTANT: This is a MANDATORY protocol, not a suggestion. Follow every step. Do not skip steps. Do not combine steps. Do not summarize. Work through each gate in order.

Scope creep is not a discipline failure — it is a definition failure. If nothing was declared OUT, everything is arguably IN. This protocol forces the boundary before a line of code makes it expensive to move.

STEP 1 — Enumerate candidate capabilities

List every capability the request could plausibly include — including the ones the user did not say but would expect, and the ones they might be assuming are free but are not. A short list here means you are scoping your first idea, not the problem.

STEP 2 — Classify each MUST / SHOULD / WON'T-THIS-VERSION

Every capability gets exactly ONE label:

• MUST — the thing is useless or incoherent without it.
• SHOULD — real value, but the thing works and ships without it.
• WON'T (this version) — explicitly deferred or excluded, on purpose.

If everything is a MUST, you have not scoped — you have re-listed the request.

STEP 3 — The WON'T list must be non-empty

Look at what you cut. If the WON'T list is empty, either the scope is genuinely tiny (say so and show why) or you have not drawn a boundary — draw one now. A scope with no edges is the thing that ships three months late.

STEP 4 — Write an acceptance criterion for every MUST

Each MUST needs an observable acceptance test — "a user can X and sees Y", checkable by someone other than you. A MUST you cannot write acceptance for is not defined yet; refine it until you can, or it is not actually a MUST.

STEP 5 — Report

SCOPE: [what is being built]
├── MUST: [capability → acceptance criterion, one line each]
├── SHOULD: [deferred-but-valuable capabilities]
├── WON'T (this version): [explicitly excluded — non-empty]
├── The cut line: [one sentence: what makes this version done]
└── Confidence: [HIGH / MEDIUM / LOW]

Confidence: HIGH — MUSTs all have acceptance criteria, cut line is unambiguous. MEDIUM — some boundaries depend on unvalidated user need. LOW — you cannot tell a MUST from a SHOULD without input the user has not given; ask before building.

Do NOT proceed to design or build until: - Every enumerated capability is labeled exactly MUST, SHOULD, or WON'T - The WON'T (this version) list is non-empty, or its emptiness is explicitly justified - Every MUST has an observable acceptance criterion someone else could check - A one-sentence cut line states what makes this version done

Starting to build with an all-MUST list and no stated exclusions is a protocol violation, even if the user said "just build it".

Red flags that this skill catches:

• "It's all essential" — then nothing is prioritized. Something ships first; name it.
• "We'll figure out the boundary as we go" — the boundary found under deadline pressure is drawn by panic, not judgment. Draw it now.
• "The user will obviously want X too" — then it is a candidate capability. Label it, do not silently build it.
• "Acceptance criteria are for QA later" — an unwritten acceptance criterion is a MUST no one can confirm is met. Write it.

Handoff

Once the scope is agreed, hand the MUST list to project-planning to sequence, and to estimation if a number is needed. Re-run this skill whenever a new capability is proposed mid-build — that is scope change, and it gets a label like everything else.