Help us improve
Share bugs, ideas, or general feedback.
From sdd
Classifies a feature into XS/S/M/L/XL by asking four questions (PR count, time, new module/API/migration, breaking changes), then writes the result to docs/features/{slug}/.size for downstream skills.
npx claudepluginhub genkovich/sdd --plugin sddHow this skill is triggered — by the user, by Claude, or both
Slash command
/sdd:classify-sizehaikuThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Atomic skill — classifies a feature into XS/S/M/L/XL and fixes the result in
Classifies work into three ceremony levels (Full, Standard, Minimal) to match documentation depth to task complexity before starting the pipeline.
Evaluates feature necessity via worthiness scoring, backlog checks, and branch size limits before implementation to prevent overengineering. Useful in brainstorm-plan-execute workflows.
Refines feature ideas with targeted questions, gathers research signals and acceptance criteria, interviews for decisions, and classifies features in blueprint workflows.
Share bugs, ideas, or general feedback.
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.
PM or Tech Lead (driver of the intake phase). An architect may escalate S → M on spotting a new subsystem.
<slug> — feature slug.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).AskUserQuestion each, phrased per ../_shared/ask-style.md:
1 / 2–5 / 5–15 / 15+.≤1 day / ~1 week / 1–2 sprints / >1 month.none / one of three / two of three / all three.no / internal only / public clients.../_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.AskUserQuestion: «Classifying as <size> (). Lock it in?» — Yes / No, I want <X> / Reclassify..size. One line, plain text, only XS/S/M/L/XL — no comments, no frontmatter. docs/features/<slug>/.size.docs/features/<slug>/spec.md exists, check its feature_size: field. Same value → OK. Conflict → WARN and resolve with the user (update one side). Missing → suggest adding feature_size: <size>.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.docs/features/<slug>/.size holds exactly one of XS/S/M/L/XL.spec.md exists, its feature_size: is in sync (no drift)..size without asking..size with comments. Wrappers grep it cheaply — keep it one bare word.User: «classify size rate-limiting-per-user» Skill:
.sizeabsent → 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 → writesdocs/features/rate-limiting-per-user/.size=S→spec.mdnot yet written, skip sync → commitsize: rate-limiting-per-user classified as S.