domain-modeling

Build and sharpen project domain models by updating CONTEXT.md glossaries and ADRs inline.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams lose shared understanding of domain terminology as codebases grow, leading to ambiguous terms, contradictory code, and undocumented architectural decisions. This Skill keeps the project's domain glossary and decision records accurate by challenging fuzzy language and capturing resolutions the moment they happen. ## Core Features & Use Cases - Glossary Maintenance: Challenge terms against docs/resources/CONTEXT.md, sharpen vague language into canonical terms, and update the glossary inline as terms are resolved. - Scenario Stress-Testing: Invent edge-case scenarios to probe domain relationships and cross-reference stated behavior against actual code to surface contradictions. - Selective ADR Recording: Offer Architecture Decision Records only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: While designing an order system, a user says "cancel the account" — the Skill flags that the glossary defines cancellation for Orders, not Customers, proposes precise terms, updates CONTEXT.md, and offers an ADR for the partial-cancellation trade-off. ## Quick Start Ask the agent to review the domain terminology in docs/resources/CONTEXT.md and record any newly resolved terms or architectural decisions as we discuss the order cancellation flow.

Frequently Asked Questions about domain-modeling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I maintain a domain glossary for my codebase?

Keep a CONTEXT.md glossary in docs/resources/ with one-sentence definitions, aliases to avoid, relationships, and flagged ambiguities. Update it inline whenever a term is resolved during design discussions rather than batching edits.

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 alternatives. If any condition is missing, skip the ADR.

How do I handle multiple bounded contexts in one repository?

Create a docs/resources/CONTEXT-MAP.md listing each context, its location, and how contexts relate. Each context gets its own CONTEXT.md, and context-specific ADRs live under that context's own docs/adr/ directory.

Can the glossary live outside the repository?

Yes. Set CONTEXT_DOCS_DIR in project.env at the repo root to redirect the glossary to $CONTEXT_DOCS_DIR/<source-repo>/CONTEXT.md. Record the origin repo in the file header since the location no longer identifies the source.

What belongs in a domain glossary versus general documentation?

Only terms specific to the project's domain belong in CONTEXT.md — general programming concepts like timeouts or error types do not. The glossary must stay free of implementation details; it defines language, not specs or design decisions.