domain-modeling
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.
- Kind
- Skill
- Works with
- Claude Code
- Source
- mattpocock/skills @ 24fe0ef7737e
- Path
- skills/engineering/domain-modeling/SKILL.md
- License
- MIT
- Jobs
- Documentation, Planning
InstallCopy it from the source repository, or sign in and let the assistant adapt it for your project.
# 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* `GLOSSARY.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.) ## File structure Most repos have a single context: ``` / ├── GLOSSARY.md ├── docs/ │ └── adr/ │ ├── 0001-event-sourced-orders.md │ └── 0002-postgres-for-write-model.md └── src/ ``` If a `GLOSSARY-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives: ``` / ├── GLOSSARY-MAP.md ├── docs/ │ └── adr/ ← system-wide decisions ├── src/ │ ├── ordering/ │ │ ├── GLOSSARY.md │ │ └── docs/adr/ ← context-specific decisions │ └── billing/ │ ├── GLOSSARY.md │ └── docs/adr/ ``` …