skills.rest
DuckKota
DuckKotaCOMMUNITY
Explore all skills by this author →
GitHub

domain-modeling

Build and maintain project domain glossaries and architecture decision records.

3|1|Updated Jul 12, 2026
Search Tags:#documentation#domain modeling#adr#glossary#bounded context#ubiquitous language#architecture decisions
One-click install
npx skills add https://github.com/DuckKota/my-opencode-setup --skill domain-modeling-duckkota
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/DuckKota/my-opencode-setup/tree/main/src/skills/domain-modeling
Command: npx skills add https://github.com/DuckKota/my-opencode-setup --skill domain-modeling-duckkota

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding of domain terminology and forget why architectural decisions were made, leading to inconsistent language in code and repeated debates over settled choices. ## Core Features & Use Cases - Glossary Management: Create and update CONTEXT.md files that define canonical domain terms, flag avoided synonyms, and sharpen vague language during design discussions. - Architecture Decision Records: Write lightweight ADRs in docs/adr/ when decisions are hard to reverse, surprising without context, and the result of real trade-offs. - Multi-Context Support: Handle repos with multiple bounded contexts via a CONTEXT-MAP.md that lists contexts and their relationships. - Use Case: While designing an ordering system, the user says "account" ambiguously; the skill challenges the term, resolves it to "Customer", updates CONTEXT.md inline, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the assistant to help define the domain terms for your project and record them in a CONTEXT.md glossary.

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 domain glossary for my codebase?▼

Create a CONTEXT.md file at the repo root listing canonical domain terms with one or two sentence definitions and avoided synonyms. Update it inline whenever a term is resolved during design discussions, keeping it free of implementation details.

When should I write an architecture decision record?▼

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a genuine trade-off between alternatives. If any of these three conditions 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. Each context keeps its own glossary and context-specific ADRs in its own directory.

What format should an ADR follow?▼

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md and contain a short title plus one to three sentences covering context, decision, and rationale. Optional sections like Status or Considered Options 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 covers only terms specific to the project's domain, excluding general programming concepts like timeouts or error types.

Related Skills

Explore More Software Engineering Skills→
kevinnftkevinnft
13

ubiquitous-language

Extract domain terminology from conversations into a structured glossary file.

Community
Intermediate
a35506322a35506322

grill-with-docs

Stress-test project plans against domain documentation, codebase, and ADRs.

Community
Intermediate
ArcReelArcReel
4.3k

domain-modeling

Build and maintain project glossaries and architecture decision records during design discussions.

Official
Intermediate
rbaumierrbaumier
4

brainstorming

Guide teams through structured ideation and design validation with formal specifications.

Community
Advanced