domain-modeling-skill

What I do

I 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. I am for when you're changing the model, not just consuming it.

1. Challenge terms against the existing glossary and surface contradictions immediately
2. Sharpen fuzzy language by proposing precise canonical terms
3. Stress-test with scenarios that probe edge cases and force precision about concept boundaries
4. Cross-reference with code — when the user states how something works, verify the code agrees
5. Update CONTEXT.md inline — capture resolved terms immediately, never batch them
6. Offer ADRs sparingly — only when a decision is hard-to-reverse, surprising, and a real trade-off

I am the docs engine (model-invoked). grill-with-docs-skill pairs me with grilling-skill so docs are captured during the interview.

When to use me

Use this skill when:

• The user introduces or disputes domain terminology
• A ubiquitous language needs to be established or sharpened
• An architectural decision has just been made and may warrant an ADR
• Another skill (e.g. grill-with-docs-skill) delegates doc maintenance during a session
• Code contradicts the user's stated understanding of how the system works

Trigger phrases:

• "let's define our terms"
• "that should be an ADR"
• "update CONTEXT.md"
• "is that the right word for"
• "capture this decision"
• "ubiquitous language"

File Structure

Single-context repos (most repos)

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

Multi-context repos

If a CONTEXT-MAP.md exists at the root, the repo has multiple contexts. The map points to where each one lives: