Run any Skill in Manus with one click

classify-size

Stars78

Forks25

UpdatedJuly 2, 2026 at 11:08

Use to classify a feature into XS/S/M/L/XL and write docs/features/{slug}/.size plus the pipeline route docs/features/{slug}/.route (quick|standard|full) so later skills know how much of each artifact to produce and how handoffs resolve skips. Triggers on "classify size", "feature size", "is this XS or M for {slug}", "size {slug}", "change route", "/sdd:classify-size {slug}", "класифікуй розмір {slug}", "який розмір фічі", "XS чи M". Asks four AskUserQuestion (PR count / time / new module-API-migration / breaking changes), maps to a size class via the shared size matrix, derives the default route (XS/S→quick, M→standard, L/XL→full), confirms size + route in ONE question, and writes the one-line .size and .route files — the source of truth; the feature_size: frontmatter mirrors in spec.md and sad.md are re-synced to it on every (re)classification.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

genkovich

genkovich/sdd

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

More from this repository

same repository

glossary

genkovich/sdd

Use to capture or update domain terms in CONTEXT.md before their meaning drifts — whenever a fuzzy word shows up in an interview, spec, or review and you want one canonical definition plus a NOT-reference so a homonym can't bite you in six months. Triggers on "add term {X}", "what is {X} in our domain", "add to CONTEXT", "fix the glossary", "define {X}", "/sdd:glossary {term}", "додай термін", "онови глосарій", "що означає {X}". Two-level contract: repo-root CONTEXT.md holds project-wide terms, docs/features/{slug}/CONTEXT.md holds feature-scoped ones; readers read both and the per-feature entry wins. Lazy-bootstraps the target from a template, checks BOTH levels for a conflicting existing entry, asks for a one-sentence definition + the concept it's confused with, and appends one line to ## Glossary. Skip generic tech words (HTTP, queue, cache) — those are not domain terms. Output: created/edited CONTEXT.md. Runs anytime, no input gate; specify, clarify, design and api read its ## Glossary as the canonical so

2026-07-0378

api

genkovich/sdd

Use to derive the API contract for a feature — an OpenAPI 3.1 document at docs/features/{slug}/contracts/openapi.yaml plus a drift/sync report (and an events doc when the feature has async flows). Triggers on "api for {slug}", "openapi for {slug}", "API contract for {slug}", "lock the interface for {slug}", "events for {slug}", "/sdd:api {slug}", "контракт API для {slug}", "OpenAPI для {slug}", "опиши ендпоінти". The contract is never hand-written: it is a derived function of data-model.md (typed fields + constraints), the sad.md §6 sequence diagrams (error branches, async actors), and spec.md acceptance criteria. Runs an inline drift check (does the contract match the model and the sequences?) and a reconcile mode. Hard-refuse if data-model.md is missing AND the feature changes the schema → run `data-model {slug}` first; on a legal no-schema-change skip it derives from the existing schema instead.

2026-07-0378

clarify

genkovich/sdd

Use to run an ambiguity sweep over a written spec.md and close every under-specified point before planning or design proceeds — so two engineers can't reasonably build different things from the same spec. Triggers on "clarify {slug}", "find ambiguities in {slug}", "is the spec ready", "sharpen the spec", "/sdd:clarify {slug}", "прояснити специфікацію", "знайди неоднозначності {slug}", "чи готова специфікація". Re-reads the spec, dispatches a clean-context devil's-advocate subagent to list where the spec forks, then for each ambiguity runs AskUserQuestion to RESOLVE it (tighten §1/§5/§6 in place) or DEFER it (→ §8 Open questions with owner+due). Output: an updated docs/features/{slug}/spec.md with every ambiguity resolved or deferred — none dangling. Hard-refuse if spec.md is missing.

2026-07-0378

data-model

genkovich/sdd

Use to design the data model AND generate the actual forward + rollback migrations in one pass — shippable SQL, not a plan. Triggers on "data model for {slug}", "schema for {slug}", "generate migrations for {slug}", "DB design + migration", "/sdd:data-model {slug}", "модель даних для {slug}", "схема для {slug}", "згенеруй міграції". Reads spec.md §5 + sad.md §5 building blocks + the §6 sequence diagrams, then writes docs/features/{slug}/data-model.md plus paired *.up.sql / *.down.sql migrations STAGED under docs/features/{slug}/migrations/ (NOT the live migrations/ tree — implement promotes them when the feature is actually built) and an audit report. Greenfield-first; brownfield delta via --mode brownfield; drift-only via --drift-only. Hard-refuses if spec.md or sad.md is missing. Stack-agnostic: detects and FOLLOWS the repo's DB + migration conventions and domain layer — it imposes no DB philosophy and writes no rules file.

2026-07-0378

decide-adr

genkovich/sdd

Use to record a post-hoc or asynchronous architecture decision as a MADR ADR when it was NOT captured during the synchronous design pass — a choice made in code, in a chat, on a whiteboard, or one a tasks/review gate flagged as missing. Triggers on "ADR for {decision}", "adr for {slug}", "document the decision on {topic}", "lock in the decision about {X}", "MADR for {topic}", "/sdd:decide-adr {slug} {title}", "створи ADR для рішення", "задокументуй рішення", "ADR на {тему}". Confirms the decision is ADR-worthy via the blast-radius gate, picks the next 4-digit number, copies design's MADR template, and fills context / drivers / considered options / outcome / honest consequences. Supports a Proposed → Accepted review flow. Output: docs/features/{slug}/adr/NNNN-{title}.md. For decisions made live with the user, use `design` — it spawns ADRs inline (Accepted).

2026-07-0378

design

genkovich/sdd

Use to produce a Software Architecture Document for a feature — Arc42 12 sections + C4 L1/L2 inline + ADRs spawned on a blast-radius gate — once spec.md exists. Triggers on "design {slug}", "architecture for {slug}", "SAD for {slug}", "arc42 for {slug}", "C4 context+container for {slug}", "/sdd:design {slug}", "спроектуй архітектуру {slug}", "SAD для {slug}", "архітектурний документ {slug}". Drafts §1–§12 in-memory, batch-validates each section Socratically (4-state machine), spawns an ADR only when a decision crosses the blast-radius threshold (irreversible / multi-module / has legitimate alternatives), writes each resolved section + its ADRs atomically, then runs a clean-context critic before finalizing. Brownfield: dispatches an Explore subagent to map the repo first. Hard-refuse if spec.md is missing; CONTEXT.md is optional (when present its Glossary is canonical).

2026-07-0378

name	classify-size
model	haiku
effort	low
agents	[]
description	Use to classify a feature into XS/S/M/L/XL and write docs/features/{slug}/.size plus the pipeline route docs/features/{slug}/.route (quick\|standard\|full) so later skills know how much of each artifact to produce and how handoffs resolve skips. Triggers on "classify size", "feature size", "is this XS or M for {slug}", "size {slug}", "change route", "/sdd:classify-size {slug}", "класифікуй розмір {slug}", "який розмір фічі", "XS чи M". Asks four AskUserQuestion (PR count / time / new module-API-migration / breaking changes), maps to a size class via the shared size matrix, derives the default route (XS/S→quick, M→standard, L/XL→full), confirms size + route in ONE question, and writes the one-line .size and .route files — the source of truth; the feature_size: frontmatter mirrors in spec.md and sad.md are re-synced to it on every (re)classification.

Skill: classify-size

Atomic skill — classifies a feature into XS/S/M/L/XL and fixes the result in docs/features/<slug>/.size, plus the pipeline route (quick / standard / full) in docs/features/<slug>/.route. This is the single source of size- and route-aware behaviour for the rest of the pipeline: later skills read .size to decide MVP vs Full output depth, and their handoffs read .route to decide how optional-stage skips resolve (auto-skip / offered / never — the Routes table in ../_shared/size-matrix.md).

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.

Called inline by specify. When .size is absent at the start of the backbone, specify step 1 runs this protocol inline (same signals, same file, folded into one bundled question) — this skill stays the standalone utility for classifying up front or re-classifying when scope changes; the protocol is never duplicated elsewhere.

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

Check existing. test -f docs/features/<slug>/.size (and .route). If .size exists, read both values and ask «.size is currently <X> (route <Y>). Reclassify?». On «no» — STOP (suggest editing, don't overwrite silently). Re-running just to switch the route is a legal, common case — mid-flight override per the Routes table.
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.
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.
Confirm size + route — ONE question. Derive the default route from the size (XS/S → quick, M → standard, L/XL → full — the Routes table in ../_shared/size-matrix.md). Then one AskUserQuestion: «Classifying as <size> () → route <route> (). Lock both in?» — options: Yes / Yes, but route <other> / No, I want size <X> / Reclassify. Never a second question just for the route.
Write .size + .route. Each one line, plain text — .size only XS/S/M/L/XL; .route only quick/standard/full — no comments, no frontmatter. docs/features/<slug>/.size, docs/features/<slug>/.route.
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.
Structural self-check — per ../_shared/self-check.md: re-read the written files from disk and verify 3 items: (1) .size holds exactly one of {XS, S, M, L, XL} (one bare word, no trailing content); (2) .route holds exactly one of {quick, standard, full}; (3) both frontmatter mirrors (feature_size: in spec.md and sad.md, for whichever exists) match .size. Fix + re-check ≤2 cycles; surface anything unresolved.
Propose commit + handoff. size: <slug> classified as <size> (route <route>) (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 (incl. «self-check: 3/3 pass») + Review (.size, .route) + 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; docs/features/<slug>/.route holds exactly one of quick/standard/full.
The user confirmed the classification — size AND route in one question (never silent, never two questions).
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 / .route without asking.
A multi-line .size / .route with comments. Wrappers grep them cheaply — keep each one bare word.
A second question just for the route. Size + route confirm together; the route option rides in the same AskUserQuestion.

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 → default route quick → confirms both in one question (rationale: one API endpoint + ~1 week + internal breaking) → writes docs/features/rate-limiting-per-user/.size = S and .route = quick → spec.md not yet written, skip sync → commit size: rate-limiting-per-user classified as S (route quick).