domain-modeling

Build and maintain a project domain model with CONTEXT.md glossaries and ADRs.

4|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/staticaland/skills --skill domain-modeling-staticaland
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/staticaland/skills/tree/main/plugins/grilling/skills/domain-modeling
Command: npx skills add https://github.com/staticaland/skills --skill domain-modeling-staticaland

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and architectural decisions get forgotten, leaving future readers guessing why the code looks the way it does. This Skill actively sharpens a project's ubiquitous language and records hard-to-reverse decisions as they happen. ## Core Features & Use Cases - Glossary maintenance: Resolves fuzzy or conflicting terms during design discussions and updates CONTEXT.md inline with canonical definitions and avoided synonyms. - Architecture Decision Records: Offers 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 linking per-context glossaries and ADRs. - Use Case: While designing a billing feature, the user says "account" ambiguously; the Skill challenges the term, pins down "Customer" versus "User", updates the glossary, and records an ADR for the event-sourced write model decision. ## Quick Start Ask the assistant to help pin down 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-to-two sentence definition and avoided synonyms under an _Avoid_ line. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an Architecture 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. Skip ADRs for easily reversed or obvious choices.

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

Create a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships with other contexts. Each context then keeps its own CONTEXT.md glossary and context-specific docs/adr/ directory.

What belongs in CONTEXT.md versus an ADR?▼

CONTEXT.md is a glossary only: domain term definitions with no implementation details, specs, or scratch notes. ADRs capture decisions and their rationale, such as technology lock-ins, integration patterns, and deliberate deviations from the obvious path.

Does this approach require special tooling or dependencies?▼

No external tools or packages are required. The Skill works entirely with plain Markdown files (CONTEXT.md, CONTEXT-MAP.md, and numbered ADR files) created lazily only when the first term or decision needs recording.