domain-model

Validates plans against project domain language and updates CONTEXT.md and ADRs inline.

2|2|Updated Jun 28, 2015
One-click install
npx skills add https://github.com/camercu/dotfiles --skill domain-model-camercu
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-model
Source: https://github.com/camercu/dotfiles/tree/main/common/.config/agents/skills/domain-model
Command: npx skills add https://github.com/camercu/dotfiles --skill domain-model-camercu

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Plans and architecture proposals often use vague or conflicting terminology that drifts from the project's documented domain language and actual code behavior, leading to misaligned implementations and hidden design contradictions. ## Core Features & Use Cases - Terminology Grilling: Interviews you one question at a time, challenging terms that conflict with the project glossary and sharpening fuzzy language into precise canonical terms. - Code Cross-Referencing: Explores the codebase to surface contradictions between what the plan claims and what the code actually does. - Inline Documentation Updates: Updates CONTEXT.md immediately as terms resolve and creates ADRs only when decisions pass a three-gate check (hard to reverse, surprising, real trade-off). - Use Case: You have a feature spec that mentions "cancelling an account". The skill challenges whether you mean Customer or User, checks the code for partial cancellation support, and records the resolved term in CONTEXT.md. ## Quick Start Ask the AI to stress-test your current plan or spec against the project's domain model and existing documentation.

Frequently Asked Questions about domain-model

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate a plan against a project domain model?▼

Run a grilling session that challenges each term in the plan against the project glossary in CONTEXT.md. Conflicts are called out immediately, resolved terms are recorded inline, and code is cross-referenced to confirm stated behavior.

What is a CONTEXT.md file in domain-driven design?▼

CONTEXT.md is a glossary of domain terms with tight one-sentence definitions, avoided synonyms, relationships between concepts, and flagged ambiguities. Single-context repos use one root file; multi-context repos use a CONTEXT-MAP.md linking per-context files.

When should I write an architecture decision record?▼

Create an ADR only when all three gates pass: the decision is hard to reverse, surprising without context, and involved a real trade-off between alternatives. Easy-to-reverse or obvious decisions should not be recorded.

How do I detect drift between a glossary and code?▼

Compare each glossary definition in CONTEXT.md against actual code usage of the term. If the glossary says "Order" means one thing but the code uses it differently, that contradiction is a finding that must be resolved or explicitly accepted.

What are the limitations of terminology grilling sessions?▼

The session requires an existing plan or proposal in context to work from, and it only records terms meaningful to domain experts, not implementation details. It does not perform structural architecture analysis, which belongs to a separate review step.