mcpField
D
domain-language-discipline

domain-language-discipline

github.com/fudesign2008Development651 installsUpdated 3d ago
Repository

About domain-language-discipline

An internal shared skill for maintaining a project's canonical terminology and boundaries in CONTEXT.md, separate from OpenSpec and implementation details. It calls for loading relevant terms, resolving conflicts, and updating the glossary as terms are settled.

Key features

  1. 01Maintain canonical project terms and boundaries
  2. 02Read CONTEXT.md or mapped files when relevant
  3. 03Surface and resolve terminology conflicts
  4. 04Update the glossary when terms are settled
  5. 05Suggest ADRs only for specific trade-offs

Use cases

  1. 01Check the glossary when analysis depends on domain terms
  2. 02Resolve conflicts between user wording and canonical terms
  3. 03Record newly settled terminology in CONTEXT.md

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/fudesign2008/open-skills --skill domain-language-discipline

After installing, type/domain-language-disciplinein Claude Code to confirm it loaded.

Details

From the project README

Domain Language Discipline

Internal shared skill. Single source of truth for project ubiquitous language as a glossary, orthogonal to OpenSpec. Hosts declare it in dependencies and abort if missing — no silent fallback.

Name note: intentionally not named domain-modeling (external skills repo). Use this name only.

What CONTEXT.md is (and is not)

IsIs not
Canonical terms and boundaries (glossary)Spec, ticket, or task list
Pure domain languageImplementation details, APIs, schemas, file paths
Orthogonal companion to OpenSpecReplacement for openspec/ proposal/specs/design/tasks

If a root CONTEXT-MAP.md exists, treat it as a pointer to multiple context-local CONTEXT.md files; otherwise use a single root CONTEXT.md.

Required behavior

  1. Read when domain language is in play — if CONTEXT.md (or mapped files) exists, load relevant terms before sharpening analysis or solutions that hinge on vocabulary.
  2. Challenge conflicts — when the user (or session) uses a term that conflicts with the glossary, surface the conflict and resolve which meaning is canonical before continuing as if both were fine.
  3. Sharpen fuzzy language — propose a precise canonical term when language is vague or overloaded; confirm with the user when it is a decision (per clarifying-question-discipline if asking).
  4. Update lazily, inline — when a term is resolved, update CONTEXT.md immediately. Create the file only when the first term is recorded. Keep entries free of implementation detail.
  5. ADRs sparingly — offer an ADR only when hard-to-reverse and surprising without context and the result of a real trade-off; otherwise skip. ADRs are optional companions, not required by this skill's core loop.

Forbidden

  • Writing OpenSpec requirements, code designs, or API contracts into CONTEXT.md
  • Treating the glossary as the behavioral source of truth instead of OpenSpec / host sinks
  • Renaming this skill to domain-modeling inside this repository

Integration guide

  • Hosts: one-line pointer at clarify/analyze when domain terms matter — load this skill; do not paste glossary format tables into hosts.
  • Prefer user-invocable: false; users reach it through PDCA hosts or explicit load.
  • Behavior changes still go to OpenSpec (or the host's artifact sink), not into CONTEXT.md.

Comments

Markdown supported