From odin
Stress-tests feature/refactor plans against domain model in CONTEXT.md and ADRs via adversarial interviews; challenges terminology, probes scenarios, cross-references code, updates files inline. Triggers on business concept proposals.
npx claudepluginhub outlinedriven/odin-claude-plugin --plugin odinThis skill uses the workspace's default tool permissions.
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.
Interviews user one question at a time to stress-test plans against domain model in CONTEXT.md and ADRs, sharpens fuzzy terminology inline, updates CONTEXT.md lazily, proposes gated ADRs.
Challenges user plans against domain model in CONTEXT.md/ADRs, sharpens terminology, updates docs inline during grilling sessions. Use to stress-test against project language.
Builds CONTEXT.md domain glossary and docs/adr/ via grilling interview to align terminology, challenge inconsistencies, and capture architecture decisions.
Share bugs, ideas, or general feedback.
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.
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).
When the user uses a term that conflicts with CONTEXT.md, surface immediately:
"The glossary defines
cancellationas ; the current usage implies . Which is canonical?"
When a term is overloaded or vague, propose a canonical term:
"
accountis overloaded —Customer(billing entity) orUser(auth subject)? Different aggregates."
Why: vague language leaks into code as ambiguous types and misnamed modules; the cost compounds.
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".
When the user states a behavior, dispatch Explore to check the code. Surface contradictions:
"The plan says partial cancellation is supported; the
Order::cancelimplementation only handles the whole-order path. Reconcile before continuing."
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.
Open an ADR only when all three apply:
Any one missing → skip the ADR. ADR format: references/ADR-FORMAT.md.
references/ADR-FORMAT.md — ADR template, language-agnosticreferences/CONTEXT-FORMAT.md — glossary entry format, language-agnostic