From 77040917a61d150a54b447abdb1c7b42c09ca180 Mon Sep 17 00:00:00 2001 From: Kyle Sexton <153232337+kyle-sexton@users.noreply.github.com> Date: Fri, 17 Jul 2026 12:56:00 -0400 Subject: [PATCH 1/2] feat(domain-driven-design): extract plugin; move domain-modeling to ubiquitous-language MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Extract a new domain-driven-design plugin (0.1.0) owning DDD practice skills, and move planning:domain-modeling into it as domain-driven-design:ubiquitous-language. The skill maintains vocabulary only and explicitly refuses bounded-context discovery — "domain-modeling" over-promised, and the concern is DDD language stewardship, not planning-stage task shaping. - planning bumps to 0.13.0 (breaking for /planning:domain-modeling invokers) and declares a dependency on domain-driven-design, so the glossary steward auto-installs from the same marketplace and the pipeline's inline vocabulary updates stay legal cross-plugin. - marketplace.json gains the domain-driven-design entry (category design); planning's domain-modeling/ubiquitous-language/glossary tags move to the new plugin. No renames-map entries. - Repo-wide sweep retargets every live /planning:domain-modeling reference (planning interview/design, architecture improve, event-storming methodology/simulation soft routes); historical CHANGELOG entries untouched. - event-storming stays a standalone plugin — multi-purpose per eventstorming.com; the moved skill's soft routing to it is unchanged. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01YVApnNGoKxYMJKNQx1QK8C --- .claude-plugin/marketplace.json | 8 +++- README.md | 3 +- plugins/architecture/skills/improve/SKILL.md | 2 +- .../skills/improve/actions/deepening.md | 5 ++- .../skills/improve/evals/evals.json | 6 +-- .../.claude-plugin/plugin.json | 21 +++++++++++ plugins/domain-driven-design/CHANGELOG.md | 16 ++++++++ plugins/domain-driven-design/README.md | 37 +++++++++++++++++++ .../skills/ubiquitous-language}/SKILL.md | 20 +++++----- .../context/glossary-contract.md | 0 .../ubiquitous-language}/evals/evals.json | 14 +++---- .../evals/fixtures/billing-terms.md | 0 .../evals/fixtures/context-map.md | 0 .../evals/fixtures/custom-terms.md | 0 .../evals/fixtures/support-terms.md | 0 .../skills/methodology/evals/evals.json | 6 +-- .../reference/glossary-and-tools.md | 6 +-- .../reference/agentic-simulation.md | 2 +- plugins/planning/.claude-plugin/plugin.json | 10 ++--- plugins/planning/CHANGELOG.md | 13 +++++++ plugins/planning/README.md | 14 +++---- plugins/planning/skills/design/SKILL.md | 10 ++--- .../planning/skills/design/evals/evals.json | 8 ++-- plugins/planning/skills/interview/SKILL.md | 6 ++- .../planning/skills/interview/context/loop.md | 2 +- .../skills/interview/evals/evals.json | 4 +- 26 files changed, 155 insertions(+), 58 deletions(-) create mode 100644 plugins/domain-driven-design/.claude-plugin/plugin.json create mode 100644 plugins/domain-driven-design/CHANGELOG.md create mode 100644 plugins/domain-driven-design/README.md rename plugins/{planning/skills/domain-modeling => domain-driven-design/skills/ubiquitous-language}/SKILL.md (87%) rename plugins/{planning/skills/domain-modeling => domain-driven-design/skills/ubiquitous-language}/context/glossary-contract.md (100%) rename plugins/{planning/skills/domain-modeling => domain-driven-design/skills/ubiquitous-language}/evals/evals.json (75%) rename plugins/{planning/skills/domain-modeling => domain-driven-design/skills/ubiquitous-language}/evals/fixtures/billing-terms.md (100%) rename plugins/{planning/skills/domain-modeling => domain-driven-design/skills/ubiquitous-language}/evals/fixtures/context-map.md (100%) rename plugins/{planning/skills/domain-modeling => domain-driven-design/skills/ubiquitous-language}/evals/fixtures/custom-terms.md (100%) rename plugins/{planning/skills/domain-modeling => domain-driven-design/skills/ubiquitous-language}/evals/fixtures/support-terms.md (100%) diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 672f13c885..ad4b10f4d1 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -191,7 +191,13 @@ "name": "planning", "source": "./plugins/planning", "category": "design", - "tags": ["planning", "wayfind", "decision-map", "brainstorm", "prd", "interview", "domain-modeling", "ubiquitous-language", "glossary", "design", "design-handoff", "devils-advocate", "architect", "stress-test", "skill"] + "tags": ["planning", "wayfind", "decision-map", "brainstorm", "prd", "interview", "design", "design-handoff", "devils-advocate", "architect", "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", diff --git a/README.md b/README.md index c3b91fca1b..7cdb64b99f 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,8 @@ 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. +- [`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, route resolved domain language to the domain-driven-design glossary steward, 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. diff --git a/plugins/architecture/skills/improve/SKILL.md b/plugins/architecture/skills/improve/SKILL.md index 60804184c0..aafb975842 100644 --- a/plugins/architecture/skills/improve/SKILL.md +++ b/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 | diff --git a/plugins/architecture/skills/improve/actions/deepening.md b/plugins/architecture/skills/improve/actions/deepening.md index 7f0284b264..4301c0b1fd 100644 --- a/plugins/architecture/skills/improve/actions/deepening.md +++ b/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. diff --git a/plugins/architecture/skills/improve/evals/evals.json b/plugins/architecture/skills/improve/evals/evals.json index b993be2c46..f85761f7c6 100644 --- a/plugins/architecture/skills/improve/evals/evals.json +++ b/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" diff --git a/plugins/domain-driven-design/.claude-plugin/plugin.json b/plugins/domain-driven-design/.claude-plugin/plugin.json new file mode 100644 index 0000000000..b5e7f638ce --- /dev/null +++ b/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" + ] +} diff --git a/plugins/domain-driven-design/CHANGELOG.md b/plugins/domain-driven-design/CHANGELOG.md new file mode 100644 index 0000000000..5e6738783e --- /dev/null +++ b/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. diff --git a/plugins/domain-driven-design/README.md b/plugins/domain-driven-design/README.md new file mode 100644 index 0000000000..16a92c58db --- /dev/null +++ b/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. diff --git a/plugins/planning/skills/domain-modeling/SKILL.md b/plugins/domain-driven-design/skills/ubiquitous-language/SKILL.md similarity index 87% rename from plugins/planning/skills/domain-modeling/SKILL.md rename to plugins/domain-driven-design/skills/ubiquitous-language/SKILL.md index 9ffb71f3ef..f9c7406ac4 100644 --- a/plugins/planning/skills/domain-modeling/SKILL.md +++ b/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 diff --git a/plugins/planning/skills/domain-modeling/context/glossary-contract.md b/plugins/domain-driven-design/skills/ubiquitous-language/context/glossary-contract.md similarity index 100% rename from plugins/planning/skills/domain-modeling/context/glossary-contract.md rename to plugins/domain-driven-design/skills/ubiquitous-language/context/glossary-contract.md diff --git a/plugins/planning/skills/domain-modeling/evals/evals.json b/plugins/domain-driven-design/skills/ubiquitous-language/evals/evals.json similarity index 75% rename from plugins/planning/skills/domain-modeling/evals/evals.json rename to plugins/domain-driven-design/skills/ubiquitous-language/evals/evals.json index 092b8c2ab9..6a65eabddc 100644 --- a/plugins/planning/skills/domain-modeling/evals/evals.json +++ b/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": [ diff --git a/plugins/planning/skills/domain-modeling/evals/fixtures/billing-terms.md b/plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/billing-terms.md similarity index 100% rename from plugins/planning/skills/domain-modeling/evals/fixtures/billing-terms.md rename to plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/billing-terms.md diff --git a/plugins/planning/skills/domain-modeling/evals/fixtures/context-map.md b/plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/context-map.md similarity index 100% rename from plugins/planning/skills/domain-modeling/evals/fixtures/context-map.md rename to plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/context-map.md diff --git a/plugins/planning/skills/domain-modeling/evals/fixtures/custom-terms.md b/plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/custom-terms.md similarity index 100% rename from plugins/planning/skills/domain-modeling/evals/fixtures/custom-terms.md rename to plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/custom-terms.md diff --git a/plugins/planning/skills/domain-modeling/evals/fixtures/support-terms.md b/plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/support-terms.md similarity index 100% rename from plugins/planning/skills/domain-modeling/evals/fixtures/support-terms.md rename to plugins/domain-driven-design/skills/ubiquitous-language/evals/fixtures/support-terms.md diff --git a/plugins/event-storming/skills/methodology/evals/evals.json b/plugins/event-storming/skills/methodology/evals/evals.json index 0d4e14c2c7..0327dd0229 100644 --- a/plugins/event-storming/skills/methodology/evals/evals.json +++ b/plugins/event-storming/skills/methodology/evals/evals.json @@ -77,11 +77,11 @@ { "id": 7, "name": "glossary-graduation-delegates-not-discovers", - "prompt": "At Big Picture wrap-up we resolved two domain terms and already established their bounded contexts. /planning:domain-modeling is available in this session. Graduate the terms without re-running context discovery.", - "expected_output": "Delegates each resolved term to /planning:domain-modeling for consumer-convention glossary maintenance and routing among the already-established contexts. It does not apply bounded-context discovery heuristics or prescribe a glossary filename.", + "prompt": "At Big Picture wrap-up we resolved two domain terms and already established their bounded contexts. /domain-driven-design:ubiquitous-language is available in this session. Graduate the terms without re-running context discovery.", + "expected_output": "Delegates each resolved term to /domain-driven-design:ubiquitous-language for consumer-convention glossary maintenance and routing among the already-established contexts. It does not apply bounded-context discovery heuristics or prescribe a glossary filename.", "files": [], "expectations": [ - "Invokes /planning:domain-modeling for active glossary graduation", + "Invokes /domain-driven-design:ubiquitous-language for active glossary graduation", "Uses the contexts already established by the workshop rather than discovering new ones", "Does not run, repeat, or inline bounded-context discovery heuristics", "Does not prescribe a universal glossary or map filename" diff --git a/plugins/event-storming/skills/methodology/reference/glossary-and-tools.md b/plugins/event-storming/skills/methodology/reference/glossary-and-tools.md index 5c297cdb5e..0bd5cd9247 100644 --- a/plugins/event-storming/skills/methodology/reference/glossary-and-tools.md +++ b/plugins/event-storming/skills/methodology/reference/glossary-and-tools.md @@ -55,9 +55,9 @@ Ubiquitous Language stickies are session artifacts — the terms they resolve sh - Project-context terms only — EventStorming mechanics vocabulary (the tables above) stays out - If the repo keeps no committed glossary yet, offer discovery-first lazy creation: infer placement and shape from consumer conventions; ask when ambiguous; never prescribe a universal filename -- When `/planning:domain-modeling` is available in the current session, delegate graduation to it; the - skill owns active maintenance and routing among already-known contexts. Without it, the shape above - is the complete fallback contract +- When `/domain-driven-design:ubiquitous-language` is available in the current session, delegate + graduation to it; the skill owns active maintenance and routing among already-known contexts. + Without it, the shape above is the complete fallback contract - Do not use glossary graduation to discover bounded contexts; this section consumes boundaries the workshop or project has already established diff --git a/plugins/event-storming/skills/simulation/reference/agentic-simulation.md b/plugins/event-storming/skills/simulation/reference/agentic-simulation.md index 2f42bbb99b..74f0a5ea33 100644 --- a/plugins/event-storming/skills/simulation/reference/agentic-simulation.md +++ b/plugins/event-storming/skills/simulation/reference/agentic-simulation.md @@ -602,7 +602,7 @@ The legend MUST be incrementally updated as each phase introduces new building b **Ubiquitous Language capture (facilitator observation, not a formal phase):** Per Brandolini (Ch. 1): "When new terms arise, and the discussion shows that they have an exact meaning in that context, I start capturing key term definitions on a special sticky note and place them just below the normal flow." In simulation, the facilitator notes domain-specific terms with precise contextual meanings as they emerge organically during ANY phase — not as a dedicated step. Use gray stickies placed below the main flow. These are NOT Wikipedia definitions — just what each term means in THIS domain conversation. Examples: "CFP: Call for Papers", "Track: Parallel session stream." -At Wrapping Up, these gray stickies become graduation candidates: offer each resolved term for the consumer repo's committed project glossary — one entry per term with a 1–2 sentence definition of what it IS and a plain `Avoid:` line listing the rejected synonyms, project-context terms only. When `/planning:domain-modeling` is available in the current session, delegate this active maintenance to it; the skill discovers the consumer's format and location and routes only among contexts already established by the workshop or project. Without that skill, preserve the same discovery-first, lazy fallback and ask when placement is ambiguous. Glossary graduation never discovers bounded contexts. +At Wrapping Up, these gray stickies become graduation candidates: offer each resolved term for the consumer repo's committed project glossary — one entry per term with a 1–2 sentence definition of what it IS and a plain `Avoid:` line listing the rejected synonyms, project-context terms only. When `/domain-driven-design:ubiquitous-language` is available in the current session, delegate this active maintenance to it; the skill discovers the consumer's format and location and routes only among contexts already established by the workshop or project. Without that skill, preserve the same discovery-first, lazy fallback and ask when placement is ambiguous. Glossary graduation never discovers bounded contexts. **Bounded context identification (POST-WORKSHOP homework — not a workshop phase):** Brandolini is emphatic (Ch. 6): "Once the workshop is officially over, and participants left the workshop room, we can start talking software, ...finally!" and "We can't assume the business side to know about bounded contexts. BCs are mostly a software development issue." BC discovery is the software architect's homework AFTER the workshop, using these 6 heuristics from Ch. 6: diff --git a/plugins/planning/.claude-plugin/plugin.json b/plugins/planning/.claude-plugin/plugin.json index 7c8ac8ac20..a081b73b27 100644 --- a/plugins/planning/.claude-plugin/plugin.json +++ b/plugins/planning/.claude-plugin/plugin.json @@ -1,8 +1,8 @@ { "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json", "name": "planning", - "version": "0.12.0", - "description": "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.", + "version": "0.13.0", + "description": "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, route resolved domain language to the domain-driven-design glossary steward, explore the design space, stress-test adversarially, and produce a structured implementation plan with an approval gate.", "author": { "name": "Melodic Software", "email": "info@melodicsoftware.com" @@ -15,9 +15,6 @@ "brainstorm", "prd", "interview", - "domain-modeling", - "ubiquitous-language", - "glossary", "design", "design-handoff", "devils-advocate", @@ -25,5 +22,6 @@ "stress-test", "implementation-plan", "skill" - ] + ], + "dependencies": ["domain-driven-design"] } diff --git a/plugins/planning/CHANGELOG.md b/plugins/planning/CHANGELOG.md index 760cb09b66..5b9763f669 100644 --- a/plugins/planning/CHANGELOG.md +++ b/plugins/planning/CHANGELOG.md @@ -3,6 +3,19 @@ All notable changes to the `planning` plugin are documented here. Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this plugin uses semantic versioning. +## [0.13.0] + +### Changed + +- **BREAKING: `/planning:domain-modeling` moved out of this plugin** — it now lives in the new + `domain-driven-design` plugin as `/domain-driven-design:ubiquitous-language`. The skill maintains + vocabulary only and explicitly refuses bounded-context discovery, so "domain-modeling" + over-promised; the concern is DDD language stewardship, not planning-stage task shaping. Invokers + of `/planning:domain-modeling` must switch to the new command. +- **Declared a dependency on `domain-driven-design`**, so installing `planning` auto-installs the + glossary steward and the pipeline's inline vocabulary updates (`interview`, `design`) keep working + cross-plugin. + ## [0.12.0] ### Changed diff --git a/plugins/planning/README.md b/plugins/planning/README.md index 192f637f65..7e5ac4e1c5 100644 --- a/plugins/planning/README.md +++ b/plugins/planning/README.md @@ -1,11 +1,11 @@ # planning A Claude Code plugin for the **pre-implementation planning pipeline** — everything -between a rough idea and approved, executable work. Nine pipeline skills covering +between a rough idea and approved, executable work. Eight pipeline skills covering charting a too-big, foggy effort as a decision map, divergence, product intent, the -engineering contract, active domain-language maintenance, design exploration, the -design→plan gate, adversarial review, and the implementation plan itself — plus a -re-runnable `setup` action that settles where artifacts land in the consuming repo. +engineering contract, design exploration, the design→plan gate, adversarial review, +and the implementation plan itself — plus a re-runnable `setup` action that settles +where artifacts land in the consuming repo. | Skill | Stage | What it does | |---|---|---| @@ -13,7 +13,6 @@ re-runnable `setup` action that settles where artifacts land in the consuming re | `/planning:brainstorm` | Diverge | Turns a rough problem into codebase-grounded candidate approaches ordered cheapest→most ambitious; the user reacts, then work routes onward scoped. | | `/planning:prd` | Product intent | Produces a Product Requirements Document (problem, users, success metrics) in three tiers — one-pager, consumer-feature, B2B-internal — with a synthesize path and a review mode. | | `/planning:interview` | Engineering contract | Locks a task contract (goal, constraints, acceptance criteria, named assumptions) into a PLAN.md Brief — synthesizing when intent is clear, running depth-first Q&A when it isn't, or interviewing relentlessly on request. | -| `/planning:domain-modeling` | Domain language | Maintains the consuming project's active ubiquitous-language glossary: resolves ambiguous terms, records canonical language and rejected synonyms, and routes entries to already-known contexts without discovering boundaries. | | `/planning:design` | Design space | Explores types, contracts, module boundaries, and package topology through collaborative discussion rounds, producing capability-matrix / type-inventory / design-threads / topology artifacts; its `handoff` action delegates to `/planning:design-handoff`. | | `/planning:design-handoff` | Design→plan gate | Gates a finished design for `/planning:architect` — a binary check that every `design-threads.md` thread is RESOLVED, directional, or TAGGED-DEFERRED — then packages the architect-ready summary and resume prompt, or FAILs and routes back to `/planning:design`. | | `/planning:devils-advocate` | Adversarial review | Stress-tests plans via assumption extraction, evidence checks, failure scenarios, and operational-gotcha sweeps — every finding evidence-backed, never generic warnings. | @@ -23,8 +22,9 @@ re-runnable `setup` action that settles where artifacts land in the consuming re The pipeline composes end-to-end — `wayfind` charts the fog upstream when an effort is too big to hold at once, then `brainstorm → prd → interview → design → design-handoff → architect` with `devils-advocate` attacking the plan before -approval — while `domain-modeling` is invoked whenever those workflows resolve vocabulary. -Every skill also works standalone. +approval — while `/domain-driven-design:ubiquitous-language` is invoked whenever +those workflows resolve vocabulary (this plugin declares a dependency on the +`domain-driven-design` plugin, so it auto-installs). Every skill also works standalone. ## Works in any repo diff --git a/plugins/planning/skills/design/SKILL.md b/plugins/planning/skills/design/SKILL.md index 3789a2bd64..42ea72a399 100644 --- a/plugins/planning/skills/design/SKILL.md +++ b/plugins/planning/skills/design/SKILL.md @@ -105,8 +105,8 @@ Derive types from capabilities: - Contracts: interfaces with method signatures - Follow the consuming project's naming conventions (interface naming, context-relative naming, name-collision avoidance with common library types, namespace conventions) — read its rules before naming - Follow the project's codified design principles (e.g. Law of Demeter, dependency direction, disambiguating overloaded terms) where it declares them; otherwise apply standard low-coupling/high-cohesion defaults -- Invoke `/planning:domain-modeling` the moment a domain term resolves so the active glossary owner - applies the consumer's existing format, placement, and context routing +- Invoke `/domain-driven-design:ubiquitous-language` the moment a domain term resolves so the + active glossary owner applies the consumer's existing format, placement, and context routing Produce: `type-inventory.md` @@ -144,8 +144,8 @@ A cross-cutting naming review of the full type inventory, run once type modeling 2. Check collisions with common library/framework type names (e.g. a bare `Result` when the stack already ships one) 3. Check overloaded-term disambiguation and domain accuracy against the project's domain vocabulary 4. Record decisions in a terminology table inside `type-inventory.md` -5. Invoke `/planning:domain-modeling` to sync resolved terms and rejected synonyms into the - consuming project's active glossary +5. Invoke `/domain-driven-design:ubiquitous-language` to sync resolved terms and rejected synonyms + into the consuming project's active glossary ## Handoff gate (`handoff` action) @@ -189,7 +189,7 @@ The in-session shortcut to the design→plan gate. Delegate to `/planning:design | Skill | Relationship | |-------|-------------| | `/interview` | **Before.** `/interview` locks the brief (scope + constraints). `/design` explores the solution space within those constraints | -| `/planning:domain-modeling` | **During.** Owns active project-glossary updates whenever design resolves domain language; it does not own type or boundary design | +| `/domain-driven-design:ubiquitous-language` | **During.** Owns active project-glossary updates whenever design resolves domain language; it does not own type or boundary design | | `/discovery:explore` (if installed) | **Before.** Exploration maps existing code. `/design` creates what SHOULD exist | | `/discovery:research` (if installed) | **Before + parallel.** Research gathers external facts. `/design` synthesizes them. Deferred research items can run in parallel | | `/design-handoff` | **The gate.** Owns the design→plan gate criteria and the /architect-ready summary; this skill's `handoff` action delegates to it | diff --git a/plugins/planning/skills/design/evals/evals.json b/plugins/planning/skills/design/evals/evals.json index 0bd8d51a46..aebaf0cd9b 100644 --- a/plugins/planning/skills/design/evals/evals.json +++ b/plugins/planning/skills/design/evals/evals.json @@ -63,15 +63,15 @@ }, { "id": 6, - "name": "resolved-terms-delegate-to-domain-modeling", + "name": "resolved-terms-delegate-to-ubiquitous-language", "prompt": "/planning:design terminology — the user just confirmed that Shipment is canonical and Parcel is a rejected synonym. Sync the terminology and continue the design pass.", - "expected_output": "Records the terminology decision in the type inventory and invokes /planning:domain-modeling to maintain the consumer glossary, then continues the design workflow. It does not reimplement or prescribe glossary format/location itself.", + "expected_output": "Records the terminology decision in the type inventory and invokes /domain-driven-design:ubiquitous-language to maintain the consumer glossary, then continues the design workflow. It does not reimplement or prescribe glossary format/location itself.", "files": [], "expectations": [ - "Invokes /planning:domain-modeling for the resolved Shipment vocabulary", + "Invokes /domain-driven-design:ubiquitous-language for the resolved Shipment vocabulary", "Does not prescribe a glossary filename, path, or duplicate entry format inside the design workflow", "Records the terminology decision in the design artifact as well as routing the glossary update", - "Continues the design workflow after domain-modeling returns" + "Continues the design workflow after ubiquitous-language returns" ] } ] diff --git a/plugins/planning/skills/interview/SKILL.md b/plugins/planning/skills/interview/SKILL.md index 331097ae9c..b5bbcb0616 100644 --- a/plugins/planning/skills/interview/SKILL.md +++ b/plugins/planning/skills/interview/SKILL.md @@ -60,7 +60,8 @@ The Q&A path of this skill is one engine wrapped in a stop condition and an outp 2. **Survey-then-deep** — before asking blind, do a fast breadth pass (repo files, recent commits, existing skills, relevant project rules) so questions land in real context 3. **Climb-to-anchor** — find the nearest `CLAUDE.md`, `AGENTS.md`, domain-vocabulary file, or module README by walking UP from the relevant directory toward repo root; let those shape questions instead of asking what is already documented 4. **Immediate doc maintenance** *(engineering sessions only)* — when an answer resolves a domain - term, invoke `/planning:domain-modeling` IMMEDIATELY between questions, not batched at end. Route + term, invoke `/domain-driven-design:ubiquitous-language` IMMEDIATELY between questions, not + batched at end. Route decisions, gotchas, and conventions to their proper homes (ADR, project rules, side note) in the same response. A general session writes no repo docs — it drives to a shared-understanding summary only @@ -113,7 +114,8 @@ When the task touches domain concepts, these behaviors activate during Q&A. The - **glossary challenge** — when the user uses a domain term two ways, or a term collides with an existing definition, probe it - **domain scenario exploration** — invent edge cases that probe concept boundaries ("what happens when a Customer cancels half an Order?") - **inline vocabulary update** *(engineering sessions only)* — when a term resolves, invoke - `/planning:domain-modeling` immediately. That skill owns discovery-first placement, the consumer's + `/domain-driven-design:ubiquitous-language` immediately. That skill owns discovery-first + placement, the consumer's file shape, purity, canonical terms, rejected synonyms, and known-context routing; the interview resumes after the update - **ADR, offered sparingly** *(engineering sessions only)* — propose an architecture decision record only when a decision is hard to reverse AND surprising without context AND the result of a real trade-off. Write to the repository's declared ADR convention (a managed `docs/adr/` README, a project rule, or an existing `docs/adr/` shape); if none is declared, offer and defer — never prescribe a location or format diff --git a/plugins/planning/skills/interview/context/loop.md b/plugins/planning/skills/interview/context/loop.md index 15c2f5d603..249cfcb243 100644 --- a/plugins/planning/skills/interview/context/loop.md +++ b/plugins/planning/skills/interview/context/loop.md @@ -57,7 +57,7 @@ Run rounds until the stop condition is met. Each round: 4. **Ask ONE question with a recommended answer** — if the codebase gate didn't resolve it, ground the recommendation in observed codebase state. When no code signal exists, recommend based on conventions and state the basis 5. **Capture the answer** in the working draft of the Brief (in your head or a scratch buffer, NOT on disk yet) 6. **Prune the tree** — what branches did this answer eliminate? What new branches opened? What's the next blocking decision? -7. **Domain check** — when the task touches domain concepts, run the glossary challenge (probe terms used two ways or colliding with existing definitions) + scenario exploration (invented edge cases probing concept boundaries). **Engineering sessions only:** when a term resolves, invoke `/planning:domain-modeling` for the inline vocabulary update — a general session writes no repo docs (SKILL.md "Domain-aware behaviors") +7. **Domain check** — when the task touches domain concepts, run the glossary challenge (probe terms used two ways or colliding with existing definitions) + scenario exploration (invented edge cases probing concept boundaries). **Engineering sessions only:** when a term resolves, invoke `/domain-driven-design:ubiquitous-language` for the inline vocabulary update — a general session writes no repo docs (SKILL.md "Domain-aware behaviors") ### Decision dependencies diff --git a/plugins/planning/skills/interview/evals/evals.json b/plugins/planning/skills/interview/evals/evals.json index 7ca3a42c50..0398f4d106 100644 --- a/plugins/planning/skills/interview/evals/evals.json +++ b/plugins/planning/skills/interview/evals/evals.json @@ -78,10 +78,10 @@ "id": 7, "name": "engineering-term-resolution-delegates", "prompt": "/planning:interview me — in this engineering task we resolved that Subscriber is canonical and Member is rejected. Continue the interview after preserving that decision.", - "expected_output": "Invokes /planning:domain-modeling immediately for the resolved engineering vocabulary, then resumes the one-question-at-a-time interview. It does not write a parallel glossary format itself, and a general-domain session would not mutate repo docs.", + "expected_output": "Invokes /domain-driven-design:ubiquitous-language immediately for the resolved engineering vocabulary, then resumes the one-question-at-a-time interview. It does not write a parallel glossary format itself, and a general-domain session would not mutate repo docs.", "files": [], "expectations": [ - "Invokes /planning:domain-modeling immediately for the resolved term", + "Invokes /domain-driven-design:ubiquitous-language immediately for the resolved term", "Does not prescribe or reimplement glossary format/location in the interview skill", "Resumes the interview loop after the vocabulary update", "Keeps the repository write explicitly scoped to an engineering session" From 6981e9c0bf3be17820220ec43c0918bd79b2438d Mon Sep 17 00:00:00 2001 From: Kyle Sexton <153232337+kyle-sexton@users.noreply.github.com> Date: Fri, 17 Jul 2026 13:45:53 -0400 Subject: [PATCH 2/2] feat(domain-driven-design): bump companion plugins with retargeted references Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01YVApnNGoKxYMJKNQx1QK8C --- plugins/architecture/.claude-plugin/plugin.json | 2 +- plugins/architecture/CHANGELOG.md | 6 ++++++ plugins/event-storming/.claude-plugin/plugin.json | 2 +- plugins/event-storming/CHANGELOG.md | 6 ++++++ 4 files changed, 14 insertions(+), 2 deletions(-) diff --git a/plugins/architecture/.claude-plugin/plugin.json b/plugins/architecture/.claude-plugin/plugin.json index 1d612e902c..b4fd4bf520 100644 --- a/plugins/architecture/.claude-plugin/plugin.json +++ b/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", diff --git a/plugins/architecture/CHANGELOG.md b/plugins/architecture/CHANGELOG.md index c5dba1db38..74db3d6fe3 100644 --- a/plugins/architecture/CHANGELOG.md +++ b/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 diff --git a/plugins/event-storming/.claude-plugin/plugin.json b/plugins/event-storming/.claude-plugin/plugin.json index 1b1978f8f6..a8af850db8 100644 --- a/plugins/event-storming/.claude-plugin/plugin.json +++ b/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", diff --git a/plugins/event-storming/CHANGELOG.md b/plugins/event-storming/CHANGELOG.md index 324b4c33b4..1e1759f1d2 100644 --- a/plugins/event-storming/CHANGELOG.md +++ b/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