Files
dotfiles/modules/claude-code/skills/domain-modeling/CONTEXT-FORMAT.md
alexion 20e968c709 Manage the user's global Claude config in the Module (task 0008)
Bring the declarative half of ~/.claude into modules/claude-code and apply
it when the Module is enabled: the global agent instructions (context =
./CLAUDE.md), the skills tree (skills = ./skills), the attention-bell hook,
and settings.json (model = opus plus the Stop/Notification/SessionStart
hook wiring).

Runtime state (projects, plugins, cache, history, sessions) and the
.credentials.json secret are left out, so login survives rebuilds and no
secret enters the repo. Verified against the built home-files that
~/.claude/{CLAUDE.md,settings.json,skills,hooks/attention-bell.sh} are
generated, the hook executable.
2026-07-19 07:57:43 -04:00

1.1 KiB

CONTEXT.md Format

Structure

# {Context Name}

{One or two sentence description of what this context is and why it exists.}

## Language

**Order**:
{A one or two sentence description of the term}
_Avoid_: Purchase, transaction

**Invoice**:
A request for payment sent to a customer after delivery.
_Avoid_: Bill, payment request

**Customer**:
A person or organization that places orders.
_Avoid_: Client, buyer, account

Rules

  • Be opinionated. When multiple words exist for the same concept, pick the best one and list the others under _Avoid_.
  • Keep definitions tight. One or two sentences max. Define what it IS, not what it does.
  • Only include terms specific to this project's context. General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
  • Group terms under subheadings when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.