How do I install the Domain Model Context skill?

Run npx skillmds@latest add stacklok/domain-model-context in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Domain Model Context safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Domain Model Context?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Domain Model Context free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Domain Model Context?

stacklok (@stacklok) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Domain Model Context by stacklok — Agent Skill

Name: Domain Model Context
Author: stacklok

Domain Model Context

Load a domain model into the working context before a coding task. Use at the start of a session that will touch product concepts, when the user says "use the domain model" or "load the model," or before implementing a feature in a repo that has a *.modelith.yaml. Makes the agent reason in the team's vocabulary — entity names, relationships, and invariants.

stacklok 5ce4169 2.3 KB Updated Sep 17, 2026

File contents

Loading the domain model as context

A well-formed domain model is a type system for the problem space. Loading it before a coding task means you use the team's exact names, respect the declared relationships, and don't violate invariants.

What to load

Find the domain model in the repo — a *.modelith.yaml and its rendered *.modelith.md (often under docs/ or the repo root).
Prefer the rendered Markdown for reading: it's the readable form, with the relationship diagram inline. If it's missing or stale (check with modelith render --check <file> — the file argument is required), regenerate it with modelith render <file> first. (If modelith isn't installed, you can still read the committed .md directly; just note it may be stale.)
Read it in full before writing code. Internalize:
- the canonical names — use Project, never "workspace" or "container";
- the relationships and cardinality — what owns what;
- the invariants — rules your code must not break.
If it has an imports: list, its scope.Name references (in attribute type values) name vocabulary that lives in the imported file, not this one — load that file too before treating a scope.Name term as unknown.

How to apply it while coding

Name variables, types, functions, and UI strings using the model's terms.
When a requirement seems to need a concept the model doesn't have, stop: that may be a real gap. Flag it and offer to capture it with the domain-model-author skill rather than silently inventing a name.
When code would violate an invariant, treat that as a bug in the plan, not a detail to smooth over.

Keep the model honest

If implementing the feature reveals the model is wrong or incomplete — a missing entity, an invariant that can't hold — surface it. The model is meant to be a living source of truth; coding against it is exactly when its gaps show up.

---name: domain-model-contextdescription: Load a domain model into the working context before a coding task. Use at the start of a session that will touch product concepts, when the user says "use the domain model" or "load the model," or before implementing a feature in a repo that has a *.modelith.yaml. Makes the agent reason in the team's vocabulary — entity names, relationships, and invariants.---# Loading the domain model as contextA well-formed domain model is a type system for the problem space. Loading itbefore a coding task means you use the team's exact names, respect the declaredrelationships, and don't violate invariants.## What to load1. Find the domain model in the repo — a `*.modelith.yaml` and its rendered `*.modelith.md` (often under `docs/` or the repo root).2. **Prefer the rendered Markdown** for reading: it's the readable form, with the relationship diagram inline. If it's missing or stale (check with `modelith render --check <file>` — the file argument is required), regenerate it with `modelith render <file>` first. (If `modelith` isn't installed, you can still read the committed `.md` directly; just note it may be stale.)3. Read it in full before writing code. Internalize: - the **canonical names** — use `Project`, never "workspace" or "container"; - the **relationships and cardinality** — what owns what; - the **invariants** — rules your code must not break.4. If it has an `imports:` list, its `scope.Name` references (in attribute `type` values) name vocabulary that lives in the imported file, not this one — load that file too before treating a `scope.Name` term as unknown.## How to apply it while coding- Name variables, types, functions, and UI strings using the model's terms.- When a requirement seems to need a concept the model doesn't have, stop: that may be a real gap. Flag it and offer to capture it with the `domain-model-author` skill rather than silently inventing a name.- When code would violate an invariant, treat that as a bug in the plan, not a detail to smooth over.## Keep the model honestIf implementing the feature reveals the model is wrong or incomplete — a missingentity, an invariant that can't hold — surface it. The model is meant to be aliving source of truth; coding against it is exactly when its gaps show up.

Frequently asked questions