skills.rest
MaiconGambini
MaiconGambiniCOMMUNITY
Explore all skills by this author →
WebsiteGitHub

domain-modeling

Builds and maintains project domain glossaries and architectural decision records.

Updated Jul 29, 2026
Search Tags:#domain modeling#adr#domain-driven design#glossary#bounded context#ubiquitous language#architecture decisions
One-click install
npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill domain-modeling-maicongambini
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/MaiconGambini/opencode-harness-guide/tree/main/skills/domain-modeling
Command: npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill domain-modeling-maicongambini

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose alignment when domain terms drift, decisions go unrecorded, and code contradicts the language people use. This Skill actively sharpens a project's domain model by challenging fuzzy terminology, stress-testing concepts with concrete scenarios, and writing down the glossary and decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with opinionated canonical terms and explicit "avoid" lists, updated inline as terms are resolved. - Architectural Decision Records: Creates lightweight ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Multi-Context Support: Handles single-context repos with one CONTEXT.md or multi-context repos via a CONTEXT-MAP.md describing contexts and their relationships. - Use Case: While designing an ordering system, the user says "account" ambiguously; the Skill asks whether they mean Customer or User, records the resolved term in CONTEXT.md, and offers an ADR when the team decides Ordering and Billing communicate via domain events instead of synchronous HTTP. ## Quick Start Ask the assistant to help define the domain terminology for your project and record any significant architectural decisions as ADRs.

Frequently Asked Questions about domain-modeling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a ubiquitous language glossary for my project?▼

Create a CONTEXT.md file at the repo root listing each domain term with a one or two sentence definition and an Avoid list of rejected synonyms. Update it inline whenever a term is resolved during design discussions, and keep it free of implementation details.

When should I write an architectural decision record?▼

Write an ADR only when all three conditions hold: the decision is hard to reverse, it is surprising without context, and it resulted from a real trade-off between genuine alternatives. If any condition is missing, skip the ADR to avoid documentation noise.

How do I handle multiple bounded contexts in one repository?▼

Create a CONTEXT-MAP.md at the repo root listing each context, where its CONTEXT.md lives, and how contexts relate to each other, such as event flows or shared types. Each context keeps its own glossary and context-specific ADRs.

What format should an ADR follow?▼

An ADR is a sequentially numbered Markdown file in docs/adr containing a short title and one to three sentences covering context, decision, and rationale. Optional sections like Status, Considered Options, and Consequences are added only when they add genuine value.

What are the limitations of a CONTEXT.md glossary?▼

CONTEXT.md is a glossary only and must not contain implementation details, specs, or scratch notes. It should only include terms specific to the project's domain, not general programming concepts like timeouts or error types.

Related Skills

Explore More Software Engineering Skills→
ishandutta2007ishandutta2007
13

Skill: Grill with Docs

Stress-test plans against CONTEXT.md terminology and ADR decisions.

Community
Intermediate
trungenglishtrungenglish
1

grill-with-docs

Runs a structured interview to refine a design while generating ADRs and a glossary.

Community
Basic
MudraMartinMudraMartin

grill-with-docs

Cross-reference glossary, ADR log, and domain model documents to verify design consistency.

Community
Advanced
taiyousan15taiyousan15

sdd-event-storming

Guide Event Storming workshops and generate Markdown domain reports.

Community
Advanced