domain-modeling

Build and maintain project glossaries and architectural decision records during design sessions.

Updated Jul 16, 2026
One-click install
npx skills add https://github.com/The-Focus-AI/walking-thoughts --skill domain-modeling-the-focus-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/The-Focus-AI/walking-thoughts/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/The-Focus-AI/walking-thoughts --skill domain-modeling-the-focus-ai

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 domain model by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording glossary entries and ADRs the moment decisions crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with opinionated canonical terms and explicit _Avoid_ lists, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Architectural Decision Records: Creates numbered ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Live Model Sharpening: Challenges conflicting terminology, cross-references claims against actual code, and invents edge-case scenarios to force precision during design discussions. - Use Case: While designing an ordering system, a user says "cancel the account" — the Skill flags that the glossary defines cancellation for Orders, not Accounts, resolves the term inline, updates CONTEXT.md, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the assistant to use the domain-modeling skill to define the term "Order" in CONTEXT.md and record why we chose Postgres for the write model as an ADR.

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 domain terms with one-to-two sentence definitions and an _Avoid_ list of rejected synonyms. Update it inline whenever a term is resolved during design discussions rather than batching changes.

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 genuine trade-off between alternatives. Easy-to-reverse or obvious decisions 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 how contexts relate to each other. Each context then gets its own CONTEXT.md and context-specific docs/adr directory for local decisions.

What belongs in CONTEXT.md versus an ADR?

CONTEXT.md is purely a glossary of domain terms 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 obvious approaches.

What are the limitations of lightweight ADR formats?

A minimal ADR format records that a decision was made and why, but omits structured sections unless they add genuine value. Teams needing rigorous audit trails or formal status tracking may require heavier templates.