agentleFS
Sign inStart free
FuDesign2008FuDesign2008/open-skills/skills/domain-language-discipline/SKILL.md

domain-language-discipline

Skill6 starsChanged 7 days agoMITView on GitHub

Hard discipline for project domain language: maintain a pure glossary in CONTEXT.md (no implementation details), challenge fuzzy or conflicting terms in-session, create files lazily, keep orthogonal to OpenSpec behavioral contracts. Referenced by PDCA hosts during clarify/analyze when domain terms matter. Triggers — 「领域语言」「CONTEXT.md」「术语表」「统一语言」「领域词汇」 / domain language discipline, project glossary, CONTEXT.md. Do NOT use as a substitute for OpenSpec specs.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

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

    line 22
  2. Very specific:

    Prefer user-invocable: false.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free