Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dmmulroy/domain-modeling
Build and sharpen a project's domain model.
Passed 15 of 19 test cases with the skill, and 10 of 19 without it.
and 6 more in the full report
5 fixed10 passed either way4 still failing0 broke3 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
We just agreed that in `SaaS-Metrics`, 'Churn' strictly means a customer non-renewal at the end of a billing cycle, while 'Cancellation' means an immediate mid-cycle stop. Should we wait until the end of our sprint planning session to update our domain file, or write it now?
| Checked | Without skill | With skill |
|---|---|---|
| Instructs that `/CONTEXT.md` must be updated immediately upon term resolution. | Missed | Passed |
The instructions your model reads when the skill loads.
Actively build and sharpen the project's domain model as you design. This is the active discipline: challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely reading CONTEXT.md for vocabulary is not this skill: that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
Most repos have a single context:
/
├── CONTEXT.md
└── src/
Create files lazily: only when you have something to write. If no CONTEXT.md exists, create one when the first term is resolved.## During the session
When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?"
When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account': do you mean the Customer or the User? Those are different things."
When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?"
When a term is resolved, update CONTEXT.md right there. Don't batch these up: capture them as they happen. Use the format in CONTEXT-FORMAT.md.
CONTEXT.md should be totally devoid of implementation details. Do not treat CONTEXT.md as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
test cases passed, vs 10 / 19 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.