Run any Skill in Manus with one click

glossary

Stars78

Forks25

UpdatedJuly 3, 2026 at 12:51

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

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

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

More from this repository

same repository

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

fix

genkovich/sdd

Use to fix a reported bug spec-first: reproduce it, trace the symptom to the owning feature's acceptance criteria, pin it with a failing (RED) test, apply the minimal GREEN fix through the same per-task gate implement uses, then patch the spec so the bug class can't silently return. Triggers on "fix {bug}", "fix the bug in {slug}", "bug in {feature}", "/sdd:fix {slug}", "regression in {slug}", "полагодь баг", "виправ багу", "регресія в {slug}", "чому зламалось". Triage is three-way: AC exists and is violated (regression) / AC is ambiguous (spec-bug — patch the wording) / no AC covers it (gap — add one, marked added-by-fix). Works on a repo with no specs at all (soft mode — code-first, recommends survey after). Writes a fix record under docs/features/{slug}/_fixes/ and commits with an SDD-Fix trailer.

2026-07-0378

name	glossary
model	haiku
effort	low
agents	[]
description	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 source of role and domain-term names.

Skill: glossary

Lazy utility that fixes the meaning of a domain term in CONTEXT.md the moment it first surfaces, so its sense doesn't drift across the pipeline. For each term it captures a one-sentence canonical definition and — when the word is ambiguous — a NOT-reference naming the concept it's confused with. Runs anytime, with no upstream gate: a single term mid-interview, an undefined-term finding clarify resolves mid-sweep, or a batch handed over by specify. The output feeds specify (role + domain-term names) and design (invariants), which treat ## Glossary as canonical and override anything that contradicts it.

This is a capture utility, not a Socratic stage — it does not run the shared Socratic loop or critic. The one shared dependency is question phrasing: → ../_shared/ask-style.md

Term definitions follow artifact_language — the ## Glossary heading and the other H2s stay English, the frontmatter stays the template's (status: Living + updated_at: — never write artifact_language or any other settings key into the file) → ../_shared/artifact-language.md.

Owner

Whoever drives the conversation — anyone who spots ambiguity. Tech Lead approves the canonical form when a term is contested.

Inputs

<term> — the domain word/phrase to fix. If not given, ask for it.
(Optional) <slug> — feature slug; targets docs/features/<slug>/CONTEXT.md. Absent → repo-root CONTEXT.md.
(Optional) pending_glossary_terms — a batch handed over by specify after it writes the spec. Process each term in turn.
(Optional) an undefined-term finding from clarify — clarify invokes this skill mid-stream, one term at a time, the moment such a finding is Resolved (it never invents a meaning inline; the canonical definition lands here).
(Optional) proposed phrasings already surfaced in an interview/brainstorm — offer them as definition options instead of asking blank.

Protocol

Pick the target (the two-level contract). Root CONTEXT.md = project-wide terms (meaningful across features); docs/features/<slug>/CONTEXT.md = feature-scoped terms (meaningful only inside that feature). If <slug> is given → the per-feature file; otherwise → repo-root. A term lives in exactly one of the two files — never split or duplicate it across levels. Readers (specify, clarify, design, api) read both files; on a conflict the per-feature entry wins.
Generic-term filter. Reject words that name infrastructure or transport rather than the business domain (e.g. HTTP, queue, cache, the datastore, the broker, a framework). Refuse: «<term> is technical, not a domain word — its choice belongs in the SAD or an ADR, not the glossary». Continue only for genuine domain vocabulary.
Bootstrap (lazy). test -f <target>. Missing → copy ./templates/CONTEXT.md to <target>. Present → read it.
Conflict check — both levels. grep -i "^- <term>" <target> AND the other level's file when it exists (root CONTEXT.md ↔ docs/features/<slug>/CONTEXT.md).
- Found (either level), identical sense → STOP, report «already in the glossary» + which file holds it — never duplicate a term across levels.
- Found (either level), different sense → escalate via AskUserQuestion (phrasing per ../_shared/ask-style.md): «<term> is already defined as <existing> in <file> — same concept or a different one?». If different: a genuinely feature-scoped narrowing goes to the per-feature file (readers let it win there); otherwise propose a disambiguating pair of names (e.g. a billing-scoped vs a runtime-scoped variant) and fix both.
- Not found in either → continue.
Ask the canonical definition — one AskUserQuestion: «Define <term> in this domain, in one sentence». Offer interview/brainstorm phrasings as options when available; otherwise free text.
Ask the NOT-reference — one AskUserQuestion: «Which concept does <term> get confused with, so a future reader doesn't mix them up?». No plausible homonym → None.
Compose one line. - <term> — <one-sentence definition>. NOT <confused concept + how it differs>. — or, when step 6 = None, - <term> — <definition>.
Append under ## Glossary. Read the file, insert the line in ## Glossary (alphabetical if the section is already sorted, else at the end). Never rewrite existing entries.
Prune empty H2s. On a fresh bootstrap, delete ## Invariants / ## Out of scope if they hold no real content — only ## Glossary is mandatory. (A genuine invariant or out-of-scope note goes in its section, never as implementation detail.)
Structural self-check — per ../_shared/self-check.md: re-read the target file(s) from disk and verify 3 items: (1) the term appears exactly once across both levels combined (grep root CONTEXT.md + docs/features/<slug>/CONTEXT.md — no duplicate, no split); (2) the entry matches the format - <term> — <definition>. (with the optional NOT … tail); (3) no empty H2 sections remain. Fix + re-check ≤2 cycles; surface anything unresolved.
Stamp + commit + handoff. Set updated_at: <today> in the frontmatter. Propose context: + <term> (or context: + <term>, <term2> for a batch). May fold into the caller's intake/spec commit. Then emit the stage-handoff block per ../_shared/handoff.md (utility variant) — What I did (incl. «self-check: 3/3 pass») + Review (CONTEXT.md) + Run next: resume your backbone stage (e.g. /sdd:design <slug>); /clear optional.

Definition of Done

<target> exists and contains <term> under ## Glossary in the «one-sentence canonical + optional NOT-reference» format.
Any conflict with an existing entry is resolved (reported as duplicate, or disambiguated into distinct names).
Generic tech words are refused, not stored.
Empty H2 sections are pruned on bootstrap; ## Glossary remains.
updated_at reflects today; a commit is proposed.

Anti-patterns

Glossary as spec or scratch pad. Implementation detail («counter stored with a 1-minute TTL») belongs in the SAD/ADR, not here.
Empty H2 «for completeness». A heading with no bullets — prune it.
Silent edits. Adding a term without confirming the definition; the author must control the glossary.
Batched «I'll add them later». Capture each term the moment it surfaces — deferral loses it.
Storing generic tech words. HTTP, queue, the datastore name — refuse them.
Rewriting on re-run. The skill reads and appends; it never overwrites the file.
Ambiguous term with no NOT-reference. A homonym without «NOT …» is a six-month confusion waiting to happen.

References & template

./templates/CONTEXT.md — output scaffold; inline comments are the per-section contract (Glossary mandatory, Invariants/Out-of-scope pruned when empty).
../_shared/ask-style.md — phrasing for the definition / NOT-reference / conflict questions.

Example invocation

User: «add term tenant for rate-limiting-per-user» Skill: <slug> given → target docs/features/rate-limiting-per-user/CONTEXT.md. Generic filter: tenant is domain → continue. File missing → copy template. grep "^- tenant" → not found. Definition Q → «a billable customer organisation owning 1+ users». NOT-reference Q → «NOT user — a user is one person inside a tenant». Compose - tenant — a billable customer organisation owning 1+ users. NOT user (a user is one person inside a tenant). → append under ## Glossary → prune empty ## Invariants/## Out of scope → updated_at: 2026-05-28 → commit context: + tenant.