domain-model

name	domain-model
description	Grill against the existing domain model. Stress-test a plan's terminology against `CONTEXT.md` and ADRs; update both inline as decisions crystallise. Trigger when user proposes a feature/refactor that touches business concepts and the project has documented domain language to honor — or when domain language is missing and needs capture.

Adversarial interview against the documented domain. Walk every branch of the design; resolve dependencies one decision at a time; recommend an answer per question. Ask one question per turn — wait for response before continuing.

When a question is answerable from the codebase, dispatch an Explore agent (fd-first discovery, git grep/ast-grep content search) instead of asking. The user is the source of intent; the codebase is the source of fact.

Modality vs adjacent skills: This is adversarial-relentless interview against documented domain language. Clarifying-question protocol is VS-shaped (hypothesis sampling + clarifying questions). General adversarial interview is general-purpose without domain-language anchor. Pick this skill when the project has (or needs) CONTEXT.md / ADRs as the artifact under stress-test.

File structure assumptions

Single-context repo:

/
├── CONTEXT.md
├── docs/adr/
│   ├── 0001-<decision>.md
│   └── 0002-<decision>.md
└── <source dirs>

Multi-context repo (if CONTEXT-MAP.md at root):

/
├── CONTEXT-MAP.md
├── docs/adr/                  ← system-wide decisions
├── <ctx-1>/
│   ├── CONTEXT.md
│   └── docs/adr/              ← context-local decisions
└── <ctx-2>/
    ├── CONTEXT.md
    └── docs/adr/

Create lazily — only when there is something to write. No CONTEXT.md yet? Create on first resolved term. No docs/adr/? Create on first qualified ADR (see below).

In session

Challenge the glossary

When the user uses a term that conflicts with CONTEXT.md, surface immediately:

"The glossary defines cancellation as ; the current usage implies . Which is canonical?"

Sharpen fuzzy language

When a term is overloaded or vague, propose a canonical term:

"account is overloaded — Customer (billing entity) or User (auth subject)? Different aggregates."

Why: vague language leaks into code as ambiguous types and misnamed modules; the cost compounds.

Probe with scenarios

When domain relationships are being discussed, invent edge-case scenarios that force boundary precision. Adapt examples to the project's domain (orders / billing / scheduling / inventory etc.), not generic "users/items".

Cross-reference with code

When the user states a behavior, dispatch Explore to check the code. Surface contradictions:

"The plan says partial cancellation is supported; the Order::cancel implementation only handles the whole-order path. Reconcile before continuing."

Update CONTEXT.md inline

When a term resolves, write the entry into CONTEXT.md immediately — capture-as-it-happens, not batch-at-end. Why: batched glossary updates lose the resolution context (who said what, in response to which scenario). See references/CONTEXT-FORMAT.md.

Constraint: CONTEXT.md excludes implementation detail. Only domain-meaningful terms — no class names, no field names, no DB columns.

Offer ADRs sparingly

Open an ADR only when all three apply:

1. Hard to reverse — meaningful cost to changing later
2. Surprising without context — future reader will ask "why did they do it this way?"
3. Real trade-off — genuine alternatives existed; the team picked one for specific reasons

Any one missing → skip the ADR. ADR format: references/ADR-FORMAT.md.

Reference materials

• references/ADR-FORMAT.md — ADR template, language-agnostic
• references/CONTEXT-FORMAT.md — glossary entry format, language-agnostic