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

[kyle-sexton]

Executes the domain-driven-design extraction slice of the shadowed-skill-renames contract (docs/topics/shadowed-skill-renames/PLAN.md, PR #256): a new domain-driven-design plugin (0.1.0) housing /domain-driven-design:ubiquitous-language, moved from /planning:domain-modeling.

No linked issue

Boundary rationale

• DDD stewardship, not task-shaping. The skill maintains the consuming project's committed vocabulary record — canonical terms, rejected synonyms, what-it-IS definitions, routing among already-known bounded contexts — and explicitly refuses bounded-context discovery. "domain-modeling" over-promised (it never models a domain); the concern is a DDD practice discipline, not a planning-stage task shape, so it moves out of planning into a plugin scoped to DDD practices. Deferred residents (context-mapping, aggregate-design) join when they materialize; the new plugin's README records that trigger.
• event-storming stays standalone. Per eventstorming.com's own positioning, EventStorming is multi-purpose (business-flow analysis, service design, software architecture — DDD is one application), so it is not folded into the DDD plugin. The moved skill's soft routing to the EventStorming capability is unchanged, and event-storming's references to the glossary steward remain soft "when available" routes.

Dependency (fresh-docs cited)

• planning (0.12.0 → 0.13.0, breaking for /planning:domain-modeling invokers) declares "dependencies": ["domain-driven-design"] in plugin.json. Per the current official docs, a dependencies entry "can be a bare string with only the plugin name … which depends on whatever version that plugin's marketplace provides", the name "resolves within the same marketplace as the declaring plugin", and "when you install a plugin that declares dependencies, Claude Code resolves and installs them automatically" — https://code.claude.com/docs/en/plugin-dependencies (fetched this session).
• The dependencies array is part of the plugin manifest schema ("Other plugins this plugin requires, optionally with semver version constraints") — https://code.claude.com/docs/en/plugins-reference (fetched this session).
• Because planning declares the dependency, its interview/design inline invocations of /domain-driven-design:ubiquitous-language are legal cross-plugin references under the contract's rule (required-for-contract → declared dependency). architecture and event-storming keep soft "when available" references with graceful degradation, so they need no dependency.

Change set

• New plugins/domain-driven-design/: manifest (0.1.0), README, CHANGELOG; skill moved via git mv with frontmatter name: ubiquitous-language (description keeps the domain-modeling / glossary / ubiquitous-language / define-this-domain-term triggers); the skill's context/ and evals/ moved with it — it has no ${CLAUDE_PLUGIN_ROOT} references, only skill-relative links, so nothing re-roots.
• marketplace.json: new domain-driven-design entry (category design); planning's domain-modeling/ubiquitous-language/glossary tags moved to it. No renames-map entries (contract constraint).
• planning 0.13.0: dependency declared, keywords trimmed, README/description updated, CHANGELOG marks the breaking move.
• Repo-wide sweep: every live /planning:domain-modeling reference retargeted (planning interview + design bodies and evals, architecture:improve, event-storming methodology/simulation references and evals). Historical CHANGELOG entries left untouched; git grep planning:domain-modeling now hits only CHANGELOGs.
• README catalog regenerated via scripts/generate-catalog.mjs; validate-plugin-contracts.mjs, validate-plugins.sh, and markdownlint pass locally.

Rebase note

PR #276 (architect→plan) also bumps planning and edits its CHANGELOG plus the interview/design skill bodies. This PR deliberately does not include any of #276's changes; whichever merges second takes a rebase (version + CHANGELOG adjacency, possible body-line context conflicts in interview/design).

Related

• PR docs: codify skill-naming grammar and cross-plugin reference rules #256 — codifies the naming grammar and carries the execution contract this PR implements.
• PR refactor(planning): rename architect skill to plan #276 — planning:architect → planning:plan rename (overlapping planning bump; see rebase note).

🤖 Generated with Claude Code

https://claude.ai/code/session_01YVApnNGoKxYMJKNQx1QK8C

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 77040917a6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Claude finished @kyle-sexton's task in 3m 19s —— View job

---

PR Review: feat(domain-driven-design): extract plugin

• Gather context and understand the PR
• Fetch current plugin docs (fresh-docs mandate)
• Review changed files: plugin manifests, marketplace.json, skill files
• Evaluate Codex P2 findings (version bumps for architecture/event-storming)
• Check cross-plugin references and dependency declarations
• Assess security, correctness, and CLAUDE.md alignment
• Post final review

---

Summary

Well-reasoned extraction. The boundary rationale (DDD vocabulary stewardship ≠ planning task-shaping) is coherent, the dependency declaration pattern is correct, and the repo-wide reference sweep is complete. The Codex P2 findings are valid — see the one blocking item below.

---

Confirmed issue: missing version bumps on architecture and event-storming

The Codex review is correct on both P2 flags. Three files in the architecture plugin changed (SKILL.md:61, actions/deepening.md:68, evals/evals.json), and three files in the event-storming plugin changed (glossary-and-tools.md:58, methodology/evals/evals.json, simulation/reference/agentic-simulation.md:58), yet both manifests remain at their prior versions (0.3.1 and 0.5.1).

Per the current official docs (fetched this session), version is the cache key: installed consumers only receive changed files when the version bumps. Without the bumps, deployed architecture and event-storming installations will keep the cached stale skill text that still routes to /planning:domain-modeling — which no longer ships after planning reaches 0.13.0. The graceful-degradation path (when available) absorbs the hard break, but users silently lose the seamless glossary handoff until they receive the corrected files.

The "soft when-available reference → no dependency required" reasoning in the PR description is correct about dependencies, but it does not discharge the version-bump obligation: any change to shipped plugin files requires a version bump, regardless of whether the referencing plugin hard-depends on the referenced one.

Required before merge:

• plugins/architecture/.claude-plugin/plugin.json: bump version from 0.3.1 → 0.3.2 (patch — content update, no schema or interface change) Fix this →
• plugins/event-storming/.claude-plugin/plugin.json: bump version from 0.5.1 → 0.5.2 (patch) Fix this →
• Add patch-level CHANGELOG entries for both plugins documenting the retargeted command reference

---

Everything else looks correct

domain-driven-design plugin manifest (plugin.json): well-formed — name, version, description, keywords present; the skills field is intentionally omitted and the runtime correctly defaults to scanning skills/. Keywords include domain-modeling for migration discoverability.

planning dependency declaration (plugin.json:26): "dependencies": ["domain-driven-design"] is the correct bare-string form per the official docs — resolves to whatever version the marketplace provides, auto-installs alongside planning. Cross-plugin invocations in interview and design are legal under the declared-dependency rule.

marketplace.json (line 197–201): domain-driven-design entry added at category: "design" with appropriate tags (including domain-modeling for discoverability). No renames-map entry — correct per the contract constraint (this is a new plugin + new skill name, not a plugin rename).

Skill content (ubiquitous-language/SKILL.md): frontmatter fields are valid (name, description, argument-hint, user-invocable, disable-model-invocation). The description preserves the domain modeling / glossary / ubiquitous-language / define-this-domain-term trigger phrases. Skill-relative context and evals links are unchanged and correct (no ${CLAUDE_PLUGIN_ROOT} refs to re-root).

planning changelog (CHANGELOG.md): 0.13.0 entry correctly marks the breaking move, names the destination command, and explains the dependency declaration.

Security: no credential exposure, no remote MCP servers, no hardcoded paths, no shell execution in any new file. Clean.

Repo-wide sweep: git grep planning:domain-modeling lands only in CHANGELOGs per the PR description — confirmed by the changed-file list (every live reference site in planning, architecture, and event-storming was retargeted).

---

Verdict: The version-bump gap on architecture and event-storming needs to be addressed before merge. Everything else is correct.

[claude]

Claude encountered an error after 0s —— View job

---

I'll analyze this and get back to you.

[claude]

Claude finished @kyle-sexton's task in 2m 28s —— View job

---

PR Review: feat(domain-driven-design): extract plugin

• Gather context and understand the PR
• Review new commits (6981e9c) for version bump fixes
• Verify architecture and event-storming version bumps applied correctly
• Verify CHANGELOG entries added
• Final assessment

---

Previous blocking issue resolved

The version-bump gap flagged in the prior review is fully addressed in commit 6981e9c:

Plugin	Was	Now	CHANGELOG
architecture	0.3.1	0.3.2	✅ entry added
event-storming	0.5.1	0.5.2	✅ entry added

Both CHANGELOG entries correctly document the retargeted invocation and state that the version bump exists specifically to deliver the changed files to existing installs.

---

Full PR verified correct

All items from the earlier review remain sound, and no new issues introduced by the follow-up commit:

• domain-driven-design plugin (plugin.json): 0.1.0, well-formed manifest, skills/ scan default correct.
• Skill frontmatter (SKILL.md): all required fields present, description preserves domain modeling/glossary/ubiquitous-language/define-this-domain-term trigger phrases, disable-model-invocation: false correct.
• planning dependency (plugin.json:26): "dependencies": ["domain-driven-design"] is the correct bare-string form; 0.13.0 CHANGELOG marks the breaking move clearly.
• marketplace.json: domain-driven-design entry at category: "design" with domain-modeling tag for migration discoverability; no renames-map entry (correct — new plugin + new skill, not a rename).
• Repo-wide sweep: only CHANGELOGs retain /planning:domain-modeling; all live reference sites retargeted.
• Security: no credential exposure, no remote MCP servers, no hardcoded paths. Clean.

Verdict: ready to merge. No outstanding issues.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6cdec940a7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restore the AskUserQuestion option description

This is the user-facing description for the use_ask_user_question boolean, but it now contains the whole planning-plugin overview and says nothing about rendering interview rounds through AskUserQuestion. Users configuring the option will be told it is about domain-language routing instead of the actual behavior, so keep the option-specific description that explains the interview question rendering toggle.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Put the breaking notes under 0.15.0

This commit bumps plugins/planning/.claude-plugin/plugin.json to 0.15.0, but these new breaking-change notes are appended under the existing ## [0.13.0] heading. When users audit the 0.15.0 update that removes /planning:domain-modeling, the changelog has no matching 0.15.0 section, so the command removal and new dependency are hidden in an older release; add a current-version heading for these entries.

Useful? React with 👍 / 👎.

[claude]

Claude finished @kyle-sexton's task in 2m 6s —— View job

---

PR Review: feat(domain-driven-design): extract plugin

• Gather context and understand the PR
• Read changed files at HEAD (6cdec940a7)
• Assess Codex P2 findings on final commit
• Post final review

---

Two post-merge issues confirmed

Both Codex P2 flags on the final commit (6cdec940a7) are valid and need a follow-up patch. The PR is already merged so these cannot block it, but they leave shipped planning 0.15.0 with two observable defects.

---

1. use_ask_user_question option carries the wrong description — plugin.json:9

The description field of the use_ask_user_question userConfig entry is the plugin-level marketing copy ("Pre-implementation planning pipeline: chart a too-big, foggy effort…"), not an explanation of what toggling this boolean actually does. A user configuring the option sees an irrelevant sentence about the whole plugin instead of what the setting controls.

The CHANGELOG's own 0.13.0 ### Added note (line 45) gives the correct description: "opt in to rendering a round of up to 4 independent questions through the AskUserQuestion tool; inline prose stays the default and remains the fallback for larger or dependency-carrying rounds." That prose belongs in the description field.

The title field ("Use AskUserQuestion for interview rounds") is correct — only description needs fixing.

Fix this →

---

2. CHANGELOG version gap: plugin.json is 0.15.0 but the most recent CHANGELOG section is 0.13.0 — CHANGELOG.md:6

The shipped manifest declares "version": "0.15.0", but the CHANGELOG's most recent section is ## [0.13.0] — there are no ## [0.14.0] or ## [0.15.0] sections. The breaking changes documented in 0.13.0 (domain-modeling move, architect→plan rename, use_ask_user_question) are the entries that should match whatever version was actually shipped.

This is almost certainly a rebase artifact: the PR was authored targeting 0.12.0 → 0.13.0, but PR #276 (architect→plan rename) had also bumped planning, and the squash-merge landed at 0.15.0 without the CHANGELOG header being updated to match.

The 0.13.0 section's content is correct; only its heading needs to change. The simplest fix: rename ## [0.13.0] to ## [0.15.0] and remove the orphaned version numbers. If 0.13.0 and 0.14.0 already shipped as distinct releases before this rebase, the right fix is to add a new ## [0.15.0] section above 0.13.0 scoped only to what changed in 0.15.0 — but that requires knowing which bump introduced which change, which may not be recoverable from git history alone.

Fix this →

---

Everything else verified correct

The core extraction work (new domain-driven-design plugin, moved skill and evals, dependency declaration on planning, marketplace entry, repo-wide reference sweep) and the version-bump fixes from commit 6981e9c0bf are all sound — no further issues. The two findings above are isolated to planning housekeeping and warrant a 0.15.1 patch.