domain-modeling

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

Updated Sep 6, 2026
One-click install
npx skills add https://github.com/malikkotb/shellpluscore --skill domain-modeling-malikkotb
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/malikkotb/shellpluscore/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/malikkotb/shellpluscore --skill domain-modeling-malikkotb

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose track of domain terminology and the reasoning behind architectural decisions, leading to inconsistent language in code and repeated debates about settled choices. This Skill captures terms in a CONTEXT.md glossary and records trade-offs as ADRs the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Creates and updates CONTEXT.md files with opinionated term definitions, including avoided synonyms, for single or multi-context repositories via CONTEXT-MAP.md. - Architecture Decision Records: Writes numbered ADRs in docs/adr/ only when decisions are hard to reverse, surprising without context, and the result of real trade-offs. - Language Sharpening: Challenges vague or conflicting terminology during design sessions and cross-references stated behavior against actual code. - Use Case: While designing an ordering system, a 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 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 as you discuss the design.

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 CONTEXT.md glossary for my project?

Define each domain term in one or two sentences, pick one canonical word per concept, and list rejected synonyms under an Avoid line. The file is created lazily at the repo root when the first term is resolved during discussion.

When should I write an architecture decision record?

Write an ADR only when all three conditions hold: the decision is hard to reverse, it would surprise a future reader without context, and it resulted from a genuine trade-off between alternatives. Easy-to-reverse or obvious choices should be skipped.

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, then place a separate CONTEXT.md inside each context directory. System-wide ADRs stay in the root docs/adr folder while context-specific ones live beside each context.

What belongs in a domain glossary versus a spec?

A CONTEXT.md contains only term definitions specific to the project's domain, never implementation details, general programming concepts, or design decisions. Implementation rationale belongs in ADRs, not the glossary.

What ADR format does this approach use?

ADRs use sequential numbering like 0001-slug.md in docs/adr/ and can be as short as a title plus one paragraph covering context, decision, and reasoning. Optional sections for status, considered options, and consequences are added only when they add genuine value.