Domain modeling skill: what it does and how to install it

Source: mattpocock/skills · Maintainer: community: Matt Pocock · License: MIT · Checked: 23 October 2026

What is the domain modeling skill?

The domain modeling skill makes your coding agent build and police a shared vocabulary for your project while you design: it questions fuzzy or conflicting terms, writes the settled ones into GLOSSARY.md, and records hard-to-reverse decisions as short ADRs. It is for developers who want an agent to use the same words for the same things across conversations, code and tickets.

It comes from mattpocock/skills, which Matt Pocock describes in the README as "My agent skills that I use every day to do real engineering - not vibe coding." The skill's description reads: "Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR."

The README makes the case for a shared language with a quote from Eric Evans's Domain-Driven Design and a plainer point of its own: agents dropped into a project "use 20 words where 1 will do." Its example is a long sentence about lessons being made "real" in the file system, which becomes "the materialization cascade" once the term is in the glossary. As of 23 October 2026, its skills.sh page listed about 874,000 installs.

What does it do?

The skill calls itself the "active" discipline. Reading GLOSSARY.md for vocabulary is something any skill can do; this one is for when you are changing the model. During a session, the SKILL.md tells the agent to:

• Challenge terms against the glossary. If you use "cancellation" in a way that conflicts with its definition, the agent asks which you mean.
• Sharpen fuzzy language. "Account" might mean Customer or User; the agent proposes one precise term.
• Stress-test with scenarios. It invents edge cases that force you to say where one concept ends and another begins.
• Cross-reference the code. If you say partial cancellation is possible but the code cancels whole orders, it points out the contradiction.
• Update GLOSSARY.md inline. Each term is written the moment it is settled, not batched at the end.
• Offer ADRs sparingly. Only when a decision is hard to reverse, surprising without context, and the result of a real trade-off.

What's in the folder:

• SKILL.md: the session rules and file layout.
• GLOSSARY-FORMAT.md: the glossary template. Each term gets a one or two sentence definition of what it is, with rejected synonyms under _Avoid_. General programming concepts don't belong.
• ADR-FORMAT.md: ADRs live in docs/adr/ as 0001-slug.md, 0002-slug.md and so on. The template is a title plus one to three sentences of context, decision and reason, with optional status, options and consequences sections.
• agents/openai.yaml: Codex display metadata ("Domain Modeling").

Files are created lazily. Most repos get one root GLOSSARY.md. A repo with several bounded contexts uses a GLOSSARY-MAP.md at the root that points to a GLOSSARY.md inside each context, with its own docs/adr/.

How do you install the domain modeling skill?

The README offers a plugin or editable files and says to choose one per agent, since both together give you every skill twice.

Claude Code plugin (whole set, updates itself). This installs the collection from Anthropic's official plugin marketplace:

claude plugin install mattpocock-skills@claude-plugins-official

Plugin skills are namespaced as /plugin-name:skill-name, so it appears as /mattpocock-skills:domain-modeling.

Codex plugin. From the README:

codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocock

Just this skill, as editable files. The domain-modeling docs list no prerequisites. With the skills CLI:

npx skills add mattpocock/skills --skill domain-modeling

Add -g for every project or -a claude-code to target Claude Code. The folder lands in .claude/skills/domain-modeling/ in your project, or ~/.claude/skills/domain-modeling/ with -g, the standard Claude Code skill locations. If you also want the interview that usually drives it, add --skill grill-with-docs --skill grilling. Codex and Cursor read the same SKILL.md format; see Codex skills and Cursor skills.

How do you use it?

You can type /domain-modeling, or the agent can load it when you discuss terminology, edit a glossary or record an ADR. In practice it most often runs underneath grill-with-docs, which loads both grilling and domain-modeling. The docs warn that models sometimes load grilling and skip this one; if GLOSSARY.md is unchanged after a grilling session, invoke domain-modeling by name as well.

Example prompts. The first two are suggestions; the last two are quoted word for word from the repo's docs:

• /domain-modeling We keep saying "subscription" for both the plan and the billing record. Sort it out.
• /domain-modeling We've decided to keep orders and invoices in separate services. Should that be an ADR?
• /grill-with-docs help me scaffold my existing repo with a GLOSSARY.md
• /grill-with-docs make my GLOSSARY.md more concise and remove any implementation details from it

There are no packages, CLIs or API keys to install. Other skills in the repo, such as tdd, read the GLOSSARY.md it writes so that names in tests and code match.

Tips and limits

From the repo's docs, not from testing:

• The glossary is a glossary and nothing else. The most reported problem is models treating "write to GLOSSARY.md" as permission to store every answer, so the file grows into a spec. Keep implementation details out.
• A huge glossary is a symptom. Trim it before splitting it with a GLOSSARY-MAP.md; splitting a bloated file gives you several bloated files.
• Brownfield repos need an explicit start. One user reported more than 50 questions before a new glossary was in shape. Incidental use builds it too slowly.
• It only cross-references code, the glossary and ADRs. It doesn't search your issue tracker, so it may reopen a naming debate you settled in a closed issue. The docs suggest putting such rules in your own docs/agents/domain.md.
• Its ADR format is fixed. Teams with their own ADR template can copy and edit the skill or override the conventions in their agent docs.
• It won't invent vocabulary for you. The docs say a domain language you don't understand yourself is meaningless, and that on a one-day build you can skip the glossary.

The skill runs no scripts, but it does create and edit files in your repo, so review its glossary and ADR changes like any other diff. Under the MIT License you can adapt it as long as you keep the copyright notice.

Save it in your Kipt library

In Kipt, open Skills and paste the skill's GitHub folder link into the import box. Kipt reads the SKILL.md and its files, including both format guides; for a repo with many skills it shows a list to pick from. You can also drop the folder or a .zip. Your skills live in your own private GitHub repo and install into Claude Code or Codex with one command:

npx skills add https://github.com/<you>/<repo>.git --all -g

Kipt is not affiliated with Matt Pocock or mattpocock/skills.

Similar skills

• Grill me skill: the interview half of grill-with-docs, usable on any subject without a repo.
• TDD skill: reads your glossary so test names use the project's terms.
• CLAUDE.md guide: where to put the standing project rules the docs suggest for overriding skill behavior.
• Skill creator: build your own skill if you want a different glossary or ADR convention.