feat(domain-driven-design): extract plugin; move domain-modeling to ubiquitous-language

.claude-plugin/marketplace.json

@@ -193,6 +193,12 @@
       "category": "design",
       "tags": ["planning", "wayfind", "decision-map", "brainstorm", "prd", "interview", "domain-modeling", "ubiquitous-language", "glossary", "design", "design-handoff", "devils-advocate", "plan", "stress-test", "skill"]
     },
+    {
+      "name": "domain-driven-design",
+      "source": "./plugins/domain-driven-design",
+      "category": "design",
+      "tags": ["ddd", "domain-driven-design", "ubiquitous-language", "glossary", "domain-modeling", "skill"]
+    },
     {
       "name": "naming",
       "source": "./plugins/naming",

README.md

@@ -32,6 +32,7 @@ Browse and manage with `/plugin`. To refresh after updates: `/plugin marketplace
 - [`architecture`](plugins/architecture) — Scans an existing codebase for module-level architecture friction — shallow modules, seam leaks, and locality gaps — using Ousterhout's deep-module lens, presents candidates as a self-contained HTML report, and runs an interview loop on the selected candidate before handing off for planning.
 - [`prototype`](plugins/prototype) — Builds throwaway code to answer a design question before committing to architecture — a logic facet (an interactive terminal app over a portable state model) and a UI facet (radically different visual variants on one route).
 - [`planning`](plugins/planning) — Pre-implementation planning pipeline: chart a too-big, foggy effort as a decision map, diverge on candidate approaches, lock product intent and the engineering contract, actively maintain resolved domain language, explore the design space, stress-test adversarially, and produce a structured implementation plan with an approval gate.
+- [`domain-driven-design`](plugins/domain-driven-design) — Domain-driven-design practice skills. Today: actively maintains a consuming project's ubiquitous-language glossary — resolves ambiguous or overloaded terms, records canonical language and rejected synonyms, sharpens what-it-IS definitions, and routes entries to already-known bounded contexts without discovering boundaries.
 - [`naming`](plugins/naming) — Generates and evaluates fresh name candidates for anything — an identifier, file, module, skill, repo, or domain term — by fanning out blind, fresh-context generators from distinct lenses (responsibility-literal, moment-of-use, domain-lore), then scoring a shortlist against the consuming org's naming criteria. The human always picks; it never auto-locks a name. An optional tournament mode adds elimination rounds with independent judges for high-stakes, hard-to-refactor names.
 - [`event-storming`](plugins/event-storming) — EventStorming for domain discovery — a methodology skill (Big Picture / Process Modeling / Design-Level facilitation reference, notation, patterns) and a simulation skill (agentic multi-persona workshops that produce a structured-markdown model by default; a live Miro-board rendering path is available when the first-party miro plugin is enabled).
 - [`miro`](plugins/miro) — Miro board management over the Model Context Protocol: create and manage boards, sticky notes, shapes, frames, connectors, and tags for EventStorming, brainstorming, and diagramming. Bundles a local stdio MCP server (single self-contained Node artifact); installs disabled — opt in and supply a Miro API token.

plugins/architecture/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "architecture",
-  "version": "0.3.1",
+  "version": "0.3.2",
   "description": "Scans an existing codebase for module-level architecture friction — shallow modules, seam leaks, and locality gaps — using Ousterhout's deep-module lens, presents candidates as a self-contained HTML report, and runs an interview loop on the selected candidate before handing off for planning.",
   "author": {
     "name": "Melodic Software",

plugins/architecture/CHANGELOG.md

@@ -3,6 +3,12 @@
 All notable changes to the `architecture` plugin are documented here. Format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning.
 
+## [0.3.2]
+
+### Changed
+
+- Soft references to the moved vocabulary skill now invoke `/domain-driven-design:ubiquitous-language` (was `/planning:domain-modeling`). Version bumped so existing installs receive the retargeted references.
+
 ## [0.3.1]
 
 ### Changed

plugins/architecture/skills/improve/SKILL.md

@@ -58,5 +58,5 @@ Graceful degradation — where a named step below is not available in the consum
 |------|------|-----|
 | A debugging pass finds an architectural root cause | Run this skill's deepening lens | Structured deepening review of the affected module |
 | A candidate shape is agreed | Hand off to a planning skill if the project has one; else summarize the agreed shape for planning | Consumes the `agreed-shape` entry from the candidate artifact (see `actions/deepening.md`) |
-| During the interview loop | Maintain resolved project vocabulary | Invoke `/planning:domain-modeling` when available in the current session; otherwise update an existing consumer-declared glossary in its own shape |
+| During the interview loop | Maintain resolved project vocabulary | Invoke `/domain-driven-design:ubiquitous-language` when available in the current session; otherwise update an existing consumer-declared glossary in its own shape |
 | Post-improvement | Review the implemented changes with the project's review tool | Standard diff review |

plugins/architecture/skills/improve/actions/deepening.md

@@ -65,8 +65,9 @@ Once the user picks a candidate, walk the decision tree: constraints, dependenci
 
 Side effects inline as decisions crystallize:
 
-- **New concept or sharpened term?** Invoke `/planning:domain-modeling` immediately when that skill is
-  available in the current session; it owns active glossary maintenance and known-context routing.
+- **New concept or sharpened term?** Invoke `/domain-driven-design:ubiquitous-language` immediately
+  when that skill is available in the current session; it owns active glossary maintenance and
+  known-context routing.
   Otherwise preserve the existing fallback: update a consumer-declared ubiquitous-language glossary
   in its own shape. If no convention exists, offer discovery-first lazy creation without prescribing
   a filename.

plugins/architecture/skills/improve/evals/evals.json

@@ -62,11 +62,11 @@
     {
       "id": 5,
       "name": "resolved-vocabulary-routes-to-owner",
-      "prompt": "/architecture:improve deepening — while grilling the selected candidate we resolved a new project term, Fulfillment Window. /planning:domain-modeling is available in this session. Preserve the term and continue.",
-      "expected_output": "Invokes /planning:domain-modeling for active glossary maintenance, then resumes the architecture interview. Architecture does not duplicate the glossary contract or discover bounded contexts; when that skill is unavailable it preserves only the consumer-owned fallback.",
+      "prompt": "/architecture:improve deepening — while grilling the selected candidate we resolved a new project term, Fulfillment Window. /domain-driven-design:ubiquitous-language is available in this session. Preserve the term and continue.",
+      "expected_output": "Invokes /domain-driven-design:ubiquitous-language for active glossary maintenance, then resumes the architecture interview. Architecture does not duplicate the glossary contract or discover bounded contexts; when that skill is unavailable it preserves only the consumer-owned fallback.",
       "files": [],
       "expectations": [
-        "Invokes /planning:domain-modeling because the skill is available in the current session",
+        "Invokes /domain-driven-design:ubiquitous-language because the skill is available in the current session",
         "Does not reimplement a glossary filename, location, or entry contract in architecture",
         "Does not perform bounded-context discovery as part of preserving the term",
         "Continues the selected-candidate interview after the glossary update"

plugins/domain-driven-design/.claude-plugin/plugin.json

@@ -0,0 +1,21 @@
+{
+  "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
+  "name": "domain-driven-design",
+  "version": "0.1.0",
+  "description": "Domain-driven-design practice skills. Today: actively maintains a consuming project's ubiquitous-language glossary — resolves ambiguous or overloaded terms, records canonical language and rejected synonyms, sharpens what-it-IS definitions, and routes entries to already-known bounded contexts without discovering boundaries.",
+  "author": {
+    "name": "Melodic Software",
+    "email": "info@melodicsoftware.com"
+  },
+  "license": "MIT",
+  "keywords": [
+    "ddd",
+    "domain-driven-design",
+    "ubiquitous-language",
+    "glossary",
+    "domain-modeling",
+    "vocabulary",
+    "bounded-contexts",
+    "skill"
+  ]
+}

plugins/domain-driven-design/CHANGELOG.md

@@ -0,0 +1,16 @@
+# Changelog
+
+All notable changes to the `domain-driven-design` plugin are documented here. Format follows
+[Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning.
+
+## [0.1.0]
+
+### Added
+
+- **Initial release.** `/domain-driven-design:ubiquitous-language` — moved from the
+  `planning` plugin, where it lived as `/planning:domain-modeling`. The skill maintains
+  the consuming project's active ubiquitous-language glossary (canonical terms, rejected
+  synonyms, what-it-IS definitions, routing among already-known bounded contexts) and
+  explicitly refuses bounded-context discovery — the old name over-promised modeling; the
+  concern is DDD language stewardship. `planning` now declares a dependency on this
+  plugin, so its pipeline keeps invoking the skill cross-plugin.

plugins/domain-driven-design/README.md

@@ -0,0 +1,37 @@
+# domain-driven-design
+
+A Claude Code plugin owning **DDD practice skills** — the stewardship disciplines of
+domain-driven design, independent of any one planning or workshop workflow.
+
+| Skill | What it does |
+|---|---|
+| `/domain-driven-design:ubiquitous-language` | Actively maintains the consuming project's ubiquitous-language glossary: resolves ambiguous or overloaded terms, records canonical language and rejected synonyms, and routes entries to already-known bounded contexts — never discovering boundaries itself. |
+
+Deferred: `context-mapping` and `aggregate-design` join this plugin when those
+practices materialize as skills.
+
+Bounded-context **discovery** is out of scope here — workshop-driven discovery lives in
+the standalone `event-storming` plugin, which `ubiquitous-language` soft-routes to when
+boundaries are missing.
+
+## Works in any repo
+
+- **Reads your conventions, assumes none.** Glossary filename, location, shape, and
+  context map come from the consuming project; where none exist, creation is lazy and
+  discovery-first — never a prescribed universal filename.
+- **No `userConfig`, no persistent state, no network.**
+
+## Install
+
+```shell
+/plugin marketplace add melodic-software/claude-code-plugins
+/plugin install domain-driven-design@melodic-software
+```
+
+The `planning` plugin declares a dependency on this plugin, so installing `planning`
+installs it automatically.
+
+## License
+
+MIT (SPDX-License-Identifier: MIT). See the `LICENSE` file at the root of the
+melodic-software/claude-code-plugins repository.

plugins/planning/skills/domain-modeling/SKILL.md → plugins/domain-driven-design/skills/ubiquitous-language/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: domain-modeling
-description: "Actively maintain a consuming project's ubiquitous-language glossary as domain understanding changes: resolve ambiguous or overloaded terms, choose canonical language, record rejected synonyms, sharpen what-it-IS definitions, and route terms to an already-known bounded context. Use when: 'update the domain glossary', 'define this domain term', 'standardize this vocabulary', 'these names conflict', or planning resolves domain language worth preserving. Not for passive glossary lookup, general dictionary definitions, or bounded-context discovery."
+name: ubiquitous-language
+description: "Actively maintain a consuming project's ubiquitous-language glossary as domain understanding changes: resolve ambiguous or overloaded terms, choose canonical language, record rejected synonyms, sharpen what-it-IS definitions, and route terms to an already-known bounded context. Use when: 'update the domain glossary', 'define this domain term', 'standardize this vocabulary', 'these names conflict', domain modeling resolves vocabulary, or planning resolves domain language worth preserving. Not for passive glossary lookup, general dictionary definitions, or bounded-context discovery."
 argument-hint: "[term, ambiguity, or resolved vocabulary]"
 user-invocable: true
 disable-model-invocation: false
@@ -92,15 +92,17 @@ Return:
 - file updated or created
 - any unresolved ambiguity or observed drift that needs a separate change
 
-## Invocation by sibling workflows
+## Invocation by consuming workflows
 
 `/planning:interview` and `/planning:design` invoke this skill the moment an engineering discussion
-resolves project vocabulary. They continue their own workflow after the glossary update; this skill
-does not take ownership of the Brief or design artifacts.
-
-Other plugins may invoke `/planning:domain-modeling` when it is available in the current session. When
-it is unavailable, they may preserve their existing minimal fallback: update an already-declared
-glossary in its own shape, or offer a discovery-first lazy creation without inventing a filename.
+resolves project vocabulary (the `planning` plugin declares a dependency on this plugin). They
+continue their own workflow after the glossary update; this skill does not take ownership of the
+Brief or design artifacts.
+
+Other plugins may invoke `/domain-driven-design:ubiquitous-language` when it is available in the
+current session. When it is unavailable, they may preserve their existing minimal fallback: update
+an already-declared glossary in its own shape, or offer a discovery-first lazy creation without
+inventing a filename.
 
 ## Boundaries
 

plugins/planning/skills/domain-modeling/evals/evals.json → plugins/domain-driven-design/skills/ubiquitous-language/evals/evals.json

@@ -1,10 +1,10 @@
 {
-  "skill_name": "domain-modeling",
+  "skill_name": "ubiquitous-language",
   "evals": [
     {
       "id": 1,
       "name": "preserves-consumer-glossary-convention",
-      "prompt": "/planning:domain-modeling We resolved that a Claimant is the person requesting coverage, never the insured organization. Treat evals/fixtures/custom-terms.md as the consumer project's existing glossary and update the term there.",
+      "prompt": "/domain-driven-design:ubiquitous-language We resolved that a Claimant is the person requesting coverage, never the insured organization. Treat evals/fixtures/custom-terms.md as the consumer project's existing glossary and update the term there.",
       "expected_output": "Updates the existing custom-terms.md table in its established row/column shape, defining Claimant tightly and recording 'insured organization' in its Rejected names column. It does not create or prescribe a GLOSSARY.md file.",
       "files": ["evals/fixtures/custom-terms.md"],
       "expectations": [
@@ -17,7 +17,7 @@
     {
       "id": 2,
       "name": "unresolved-language-does-not-write",
-      "prompt": "/planning:domain-modeling We keep alternating between Account, Customer, and Tenant, and nobody agrees whether these are one concept or three. Please add something to the glossary now so we can move on.",
+      "prompt": "/domain-driven-design:ubiquitous-language We keep alternating between Account, Customer, and Tenant, and nobody agrees whether these are one concept or three. Please add something to the glossary now so we can move on.",
       "expected_output": "Declines to manufacture consensus or write a speculative entry. Exercises the terms against a domain scenario and asks one focused question that resolves their conceptual boundary before any glossary update.",
       "files": [],
       "expectations": [
@@ -30,7 +30,7 @@
     {
       "id": 3,
       "name": "routes-known-context-without-discovery",
-      "prompt": "/planning:domain-modeling In the Support context, Ticket means a customer's request for help; Billing also uses ticket to mean a metered charge record. Use the supplied context map and glossaries, and record only the resolved Support meaning. Do not redesign our contexts.",
+      "prompt": "/domain-driven-design:ubiquitous-language In the Support context, Ticket means a customer's request for help; Billing also uses ticket to mean a metered charge record. Use the supplied context map and glossaries, and record only the resolved Support meaning. Do not redesign our contexts.",
       "expected_output": "Reads the supplied map, routes the new definition only to support-terms.md, and leaves billing-terms.md and the context boundaries unchanged. It does not duplicate the entry or run bounded-context discovery.",
       "files": [
         "evals/fixtures/context-map.md",
@@ -47,7 +47,7 @@
     {
       "id": 4,
       "name": "no-spec-or-generic-term-pollution",
-      "prompt": "/planning:domain-modeling Add Retry to our domain glossary with the definition 'a Polly policy stored in Redis that retries the HTTP request three times with exponential backoff.'",
+      "prompt": "/domain-driven-design:ubiquitous-language Add Retry to our domain glossary with the definition 'a Polly policy stored in Redis that retries the HTTP request three times with exponential backoff.'",
       "expected_output": "Rejects the proposed entry because Retry is generic programming vocabulary and the proposed text is an implementation specification, not a project-specific what-it-IS domain definition. It asks for evidence of a distinct project-domain meaning before admitting it.",
       "files": [],
       "expectations": [
@@ -60,7 +60,7 @@
     {
       "id": 5,
       "name": "no-empty-file-or-fixed-filename",
-      "prompt": "/planning:domain-modeling Set up our domain glossary structure now. We have not resolved any domain terms, the repo has no vocabulary convention, and I will not be available to answer placement questions.",
+      "prompt": "/domain-driven-design:ubiquitous-language Set up our domain glossary structure now. We have not resolved any domain terms, the repo has no vocabulary convention, and I will not be available to answer placement questions.",
       "expected_output": "Does not create empty glossary or context-map scaffolding and does not choose a universal filename. It reports that creation is deferred until a real term resolves and a consumer convention can be inferred or confirmed.",
       "files": [],
       "expectations": [
@@ -73,7 +73,7 @@
     {
       "id": 6,
       "name": "passive-lookup-does-not-mutate",
-      "prompt": "/planning:domain-modeling Read evals/fixtures/custom-terms.md and tell me what Policyholder means. This is a lookup only; no terminology changed.",
+      "prompt": "/domain-driven-design:ubiquitous-language Read evals/fixtures/custom-terms.md and tell me what Policyholder means. This is a lookup only; no terminology changed.",
       "expected_output": "Answers from the existing entry without rewriting, normalizing, or relocating the glossary. It recognizes that passive reading is not an active model-language change.",
       "files": ["evals/fixtures/custom-terms.md"],
       "expectations": [

plugins/event-storming/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "event-storming",
-  "version": "0.5.1",
+  "version": "0.5.2",
   "description": "EventStorming for domain discovery — a methodology skill (Big Picture / Process Modeling / Design-Level facilitation reference, notation, patterns) and a simulation skill (agentic multi-persona workshops that produce a structured-markdown model by default; a live Miro-board rendering path is available when the first-party miro plugin is enabled).",
   "author": {
     "name": "Melodic Software",

plugins/event-storming/CHANGELOG.md

@@ -3,6 +3,12 @@
 All notable changes to the `event-storming` plugin are documented here. Format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning.
 
+## [0.5.2]
+
+### Changed
+
+- Soft references to the moved vocabulary skill now invoke `/domain-driven-design:ubiquitous-language` (was `/planning:domain-modeling`). Version bumped so existing installs receive the retargeted references.
+
 ## [0.5.1]
 
 ### Changed