Domain Modeling

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 the glossary 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.)

The domain model lives in two places:

• Glossary — docs/glossary/, one markdown file per term, in the format uvx disambiguate expects (see below). Never a root CONTEXT.md.
• Decisions — ADRs in docs/adr/, per the writing-adrs skill.

Glossary entries, ADRs, docs: as short as possible, caveman mode preferred (caveman skill) — precision and understandability must not suffer.

Create files lazily — only when you have something to write. If docs/glossary/ doesn't exist, create it when the first term is resolved.

During the session

Challenge against the glossary

When the user uses a term that conflicts with the existing language in docs/glossary/, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"