Skill

/domain-modeling

Build the project's shared language and bounded contexts before writing code, so names stay consistent and the agent stops paraphrasing domain concepts. Produces a CONTEXT.md glossary and decision records. Use at the start of a project or feature, or when the codebase and the

One skill from pro-workflow.

shell

$ npx -y skills add rohitg00/pro-workflow --skill domain-modeling --agent claude-code

Installs just this skill. Get the whole plugin for auto-invocation.

How it fires

How this skill gets triggered: by you, by Claude, or both.

Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/domain-modeling

Context preview

The summary Claude sees to decide when to auto-load this skill.

Build the project's shared language and bounded contexts before writing code, so names stay consistent and the agent stops paraphrasing domain concepts. Produces a CONTEXT.md glossary and decision records. Use at the start of a project or feature, or when the codebase and the

Stats

Stars2,638

Forks255

LanguageJavaScript

Ships with pro-workflow

@rohitg00 Get the whole plugin, auto-invoked

SKILL.md

domain-modeling.SKILL.md

---
name: domain-modeling
description: Build the project's shared language and bounded contexts before writing code, so names stay consistent and the agent stops paraphrasing domain concepts. Produces a CONTEXT.md glossary and decision records. Use at the start of a project or feature, or when the codebase and the people describing it speak different languages.
user-invocable: true
---

# domain-modeling

Most misbuilds start as a language gap: the agent is dropped into a project
and left to infer the jargon, so it uses twenty words where the domain has
one. A shared language closes the gap. When code, conversation, and the model
all draw from the same vocabulary, names line up, navigation gets cheaper, and
the model spends fewer tokens reasoning because it has a tighter language to
reason in.

## Method

1. **Harvest the terms.** From the request, the codebase, and the user's own
   words, list the nouns and verbs that carry domain meaning - the concepts a
   newcomer would have to ask about. Prefer the user's word over a synonym you
   like better.
2. **Pin each one.** Write a one-line definition in the project's own language,
   not a dictionary definition. If two terms blur together, force the
   distinction or collapse them - ambiguity here becomes inconsistent names in
   code.
3. **Draw the boundaries.** Where the same word means different things in