domain-model

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