domain-modeling

Build and maintain project domain glossaries and architecture decision records.

Updated May 31, 2026
One-click install
npx skills add https://github.com/AlexanderNarbaev/agi --skill domain-modeling-alexandernarbaev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/AlexanderNarbaev/agi/tree/main/.opencode/skills/matt-pocock/domain-modeling
Command: npx skills add https://github.com/AlexanderNarbaev/agi --skill domain-modeling-alexandernarbaev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose alignment when domain terms drift and architectural decisions go unrecorded, leading to inconsistent code and repeated debates. This Skill actively sharpens a project's domain model by challenging fuzzy terminology, resolving contradictions between language and code, and capturing decisions the moment they crystallize. ## Core Features & Use Cases - Glossary Management: Create and update CONTEXT.md files with opinionated, tightly-defined domain terms, including explicit "avoid" lists for ambiguous synonyms. - ADR Authoring: Record hard-to-reverse architectural decisions in numbered ADR files under docs/adr/, only when decisions are surprising, irreversible, and involve real trade-offs. - Multi-Context Support: Handle repos with multiple bounded contexts via a CONTEXT-MAP.md that maps contexts and their relationships. - Use Case: While designing an ordering system, the user says "account" — the Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, 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 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 each domain term with a one-to-two sentence definition and an "Avoid" list of rejected synonyms. Terms are added lazily as they are resolved during design discussions, not batched upfront.

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 real trade-off between genuine 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, its location, and how contexts relate to each other. Each context then gets its own CONTEXT.md and optionally its own docs/adr/ directory for context-specific decisions.

What belongs in a CONTEXT.md glossary file?

Only domain terms specific to the project's context belong in CONTEXT.md, defined in one or two sentences. General programming concepts, implementation details, and specs are explicitly excluded — it is a glossary and nothing else.

What is the format for an ADR file?

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. The minimal format is 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.