ワンクリックでManusで任意のスキルを実行

classify-size

スター78

フォーク25

更新日2026年7月2日 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.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

genkovich

genkovich/sdd

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

関連職種SOC

SOC 職業分類に基づく

プロジェクト管理専門家ビジネス・金融業務職·SOC 13-1082

SKILL.md

readonly

このリポジトリの他の Skills

同じリポジトリ

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).