classify-size

Skill: classify-size

Atomic skill — classifies a feature into XS/S/M/L/XL and fixes the result in docs/features/<slug>/.size. This is the single source of size-aware behaviour for the rest of the pipeline: later skills read .size to decide MVP vs Full output depth.

This skill is the canonical owner of the size matrix → ../_shared/size-matrix.md. The classification rules, the MVP-vs-Full table, and the one-sentence rule all live there; this skill only runs the dialogue and writes the file.

Owner

PM or Tech Lead (driver of the intake phase). An architect may escalate S → M on spotting a new subsystem.

Inputs

• <slug> — feature slug.
• (Optional) the idea / intake note — for a rough starting hint. The skill works without it.

Protocol

1. Check existing. test -f docs/features/<slug>/.size. If it exists, read the value and ask «.size is currently <X>. Reclassify?». On «no» — STOP (suggest editing, don't overwrite silently).
2. Ask the four signals — one AskUserQuestion each, phrased per ../_shared/ask-style.md:
   • PR count — 1 / 2–5 / 5–15 / 15+.
   • Time to merge the main part — ≤1 day / ~1 week / 1–2 sprints / >1 month.
   • New module / new API / DB migration — none / one of three / two of three / all three.
   • Breaking changes for consumers — no / internal only / public clients.
3. Map to a class using the table in ../_shared/size-matrix.md. On an edge case, name the dominant signal aloud («M because it adds a new API + 1–2 sprints, even though PR count is on the S/M border»). For an all-maximums answer, ask explicitly «needs a separate roadmap?» → yes = XL.
4. Confirm with the user. AskUserQuestion: «Classifying as <size> (). Lock it in?» — Yes / No, I want <X> / Reclassify.
5. Write .size. One line, plain text, only XS/S/M/L/XL — no comments, no frontmatter. docs/features/<slug>/.size.
6. Re-sync the frontmatter mirrors (.size is the source of truth). feature_size: lives in up to three places: the .size file (canonical) plus the spec.md and sad.md frontmatter (human-readable mirrors). For each of the two files that exists: same value → OK; different (a reclassification, or a hand-edited mirror) → update the frontmatter to the new .size value and say so — never leave a mirror stale; missing field → suggest adding feature_size: <size>. If the user insists a mirror is the right value, that's a reclassification — loop back to step 4 and re-confirm, then re-sync.
7. Propose commit + handoff. size: <slug> classified as <size> (or fold into the intake commit if a wrapper called this). Then emit the stage-handoff block per ../_shared/handoff.md (utility variant) — What I did + Review (.size) + Run next: resume your backbone stage (e.g. /sdd:specify <slug>); /clear optional.

Definition of Done

• docs/features/<slug>/.size holds exactly one of XS/S/M/L/XL.
• The user confirmed the classification (never silent).
• If spec.md / sad.md exist, their feature_size: mirrors match .size (no drift; .size is the source of truth).

Anti-patterns

• Self-classify without confirmation. The skill proposes; the user locks it.
• Optimistic «it's probably S». Run the four questions — a week later the skipped design hurts.
• Skipping the module/API/migration and breaking-change questions. They are what separates S from M.
• Overwriting an existing .size without asking.
• A multi-line .size with comments. Wrappers grep it cheaply — keep it one bare word.

Example invocation

User: «classify size rate-limiting-per-user» Skill: .size absent → asks the four questions (2–5 PR, ~1 week, one of three — new API, internal only) → maps to S (rationale: one API endpoint + ~1 week + internal breaking) → confirms → writes docs/features/rate-limiting-per-user/.size = S → spec.md not yet written, skip sync → commit size: rate-limiting-per-user classified as S.