Update to Matt Skills Curated

{
  "description": "Build and sharpen a project's domain model, ubiquitous language, and architectural decision records. Use when establishing codebase terminology, challenging fuzzy concepts, writing ADRs, or updating CONTEXT.md — even if the user says \"define our terms\". Do NOT use for general code refactoring without domain shifts.",
  "included_files": [
    {
      "relative_path": "ADR-FORMAT.md",
      "size_in_bytes": 2733
    },
    {
      "relative_path": "CONTEXT-FORMAT.md",
      "size_in_bytes": 2290
    },
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 101
    }
  ],
  "name": "domain-modeling",
  "skill_md_contents": "---\nname: domain-modeling\ndescription: \"Build and sharpen a project's domain model, ubiquitous language, and architectural decision records. Use when establishing codebase terminology, challenging fuzzy concepts, writing ADRs, or updating CONTEXT.md — even if the user says \\\"define our terms\\\". Do NOT use for general code refactoring without domain shifts.\"\n---\n\n# Domain Modeling\n\nActively establish, sharpen, and enforce ubiquitous domain language (`CONTEXT.md`) and architectural decision records (`docs/adr/*.md`) to prevent semantic drift across agents and engineering teams.\n\n---\n\n## Core Invariants\n\n1. **Active Semantic Enforcement**: Proactively challenge overloaded, ambiguous, or colloquial terms and align them with canonical definitions in real time.\n2. **Immediate Inline Glossary Updates**: Capture domain terms into `CONTEXT.md` the instant they crystallize; never batch glossary edits to the end of a session.\n3. **Strict Implementation-Free Glossary**: `CONTEXT.md` must contain zero implementation details, frameworks, or database choices—it is a pure domain dictionary.\n4. **Selective ADR Threshold**: Only author an ADR when a decision meets all 3 criteria: (1) Hard to reverse, (2) Surprising without context, (3) The result of a real trade-off.\n5. **Codebase-Glossary Alignment**: Cross-reference terminology with live codebase entities and flag discrepancies immediately.\n\n---\n\n## Architecture & Map of Content (MOC)\n\n```\n[ Domain Discussions / User Prompts ] ──► [ Semantic Challenge & Disambiguation ] ──► [ Inline CONTEXT.md Update ]\n                                                                 │\n                                ┌────────────────────────────────┴────────────────────────────────┐\n                                ▼                                                                 ▼\n                     [ Domain Dictionary ]                                              [ Architectural Records ]\n                     - Single-context: `CONTEXT.md`                                     - `docs/adr/NNNN-<slug>.md`\n                     - Multi-context: `CONTEXT-MAP.md`                                  - Context, Decision, Consequences\n```\n\n| Artifact | Responsibility | Format Reference |\n|---|---|---|\n| **Domain Glossary** | Canonical terms, entity boundaries, invariants | `skills/domain-modeling/CONTEXT-FORMAT.md` |\n| **Architectural Record** | Irreversible architectural choices & trade-offs | `skills/domain-modeling/ADR-FORMAT.md` |\n| **Context Map** | Bounded contexts across modular repositories | `CONTEXT-MAP.md` |\n\n---\n\n## Step-by-Step Procedure (TWI)\n\n### Step 1: Detect Context Architecture & Glossary Baseline\n- **Action**: Check if a root `CONTEXT-MAP.md` exists (multi-context) or single `CONTEXT.md` / `docs/adr/`.\n- **Key Point**: Create glossary files lazily on the first resolved term.\n- **Why**: Multi-context systems require partitioning domain terms by bounded context to prevent collision.\n\n### Step 2: Challenge Fuzzy & Overloaded Language\n- **Action**: Intercept vague nouns (e.g. \"account\", \"item\", \"process\") and propose distinct canonical domain entities.\n- **Key Point**: Stress-test boundaries with concrete edge-case scenarios (e.g., \"What happens during partial cancellation?\").\n- **Why**: Ambiguous nouns lead to bloated database entities and tangled business logic.\n\n### Step 3: Verify Alignment Against Existing Codebase\n- **Action**: Search the codebase for entity names and check whether existing schemas agree with the user's description.\n- **Key Point**: Highlight discrepancies immediately: \"The code cancels entire Orders, but you described partial cancellation. Which is correct?\"\n- **Inline Checklist**:\n  - [ ] Term verified against live database/code entities\n  - [ ] Definition added to `CONTEXT.md` using standard format\n  - [ ] Implementation details omitted from glossary\n\n### Step 4: Author Architectural Decision Records (ADRs)\n- **Action**: For decisions meeting the 3-point threshold, create `docs/adr/NNNN-<slug>.md`.\n- **Key Point**: Document Context, Decision, Status, and Consequences.\n- **Why**: Transparent ADRs prevent repetitive debates and document technical debt trade-offs.\n\n---\n\n## Anti-Rationalization Guardrails\n\n| Tempting Rationalization | Binding Rule | Engineering Rationale |\n|---|---|---|\n| *\"I'll add database table schemas into CONTEXT.md.\"* | **Forbidden. CONTEXT.md contains pure domain terms only.** | Coupling the domain glossary to DB schemas makes it obsolete upon migration. |\n| *\"Let's write an ADR for every small choice (e.g. library helper).\"* | **Enforce the 3-point ADR threshold.** | Low-value ADRs clutter documentation and obscure truly critical architectural choices. |\n| *\"The user used 'User' and 'Customer' interchangeably; I'll ignore it.\"* | **Challenge and disambiguate overloaded terms immediately.** | Conflating distinct domain concepts creates severe authorization and modeling bugs. |\n\n"
}