/ddd-analysis

name: "ddd-analysis"
description:
  "Analyzes an existing codebase using strategic Domain-Driven Design to discover bounded contexts, surface
  ubiquitous language and semantic collisions, find places where code boundaries diverge from domain boundaries,
  and produce an evidence-backed domain and context map. Use when the goal is DDD-specific: bounded context
  discovery, ubiquitous language analysis, domain model discovery, or mapping contested ownership and
  responsibility. The entire repository is a valid scope; no module or directory must be named first. Does not
  assess architectural coupling, cohesion, or technical debt — use architectural-analysis. Does not design
  service communication, integration patterns, or deployment topology — use architectural-analysis or
  plan-a-feature. Does not refactor code, diagnose bugs, or review code quality — use refactor, investigate,
  or code-review."
arguments: size
argument-hint: "[size: small | medium | large] [focus area: module or directory to restrict analysis to]"
allowed-tools: Read, Glob, Grep, Agent, Write, Bash(find *), Bash(date *), Bash(mkdir *), Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

Project Context

• git installed: !`which git 2>/dev/null || echo "not installed"`
• CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
• project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
• personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
• project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md` probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Operating Principles

Read these before dispatching anything. They constrain every step below.

• **The entire repository is a valid scope.** No focus area is required. If the user names a module or directory,

restrict the analysis to it; otherwise, scope is the full repository. Do not ask for a focus area when none was given.

• **Discovery and context model only. No migration plans.** This skill characterizes what the domain structure is.

It does not produce recommendations for service splits, migration steps, or refactoring work. When the context model surfaces a decision the team wants to act on, the right next step is `han-planning:plan-a-feature` (to specify a change) or `han-coding:architectural-analysis` (for a code-level view of a specific module). The context model informs those steps; it does not replace them.

• **Analysis surface partitions organize agent work, not context proposals.** The inventory step identifies

tractable areas for structural and behavioral analysis. These partitions are analytical conveniences — they must never be mentioned in any agent brief as context candidates or suggested boundaries.

• **The agents own the judgment; the skill orchestrates.** The skill resolves scope, surveys the surface, classifies

depth, briefs the agents, collects their output, and renders the report. It does not produce DL#, CAP#, OWN#, S#, B#, or BCM# findings itself.

• **Negative results are valuable.** A module with no domain events and only CRUD operations is evidence, not a gap.

Agents must not fabricate findings to fill sections.

• **Exactly one revision loop.** The skill dispatches bounded-context-modeler, then bounded-context-critic, then

bounded-context-modeler once more with the critique. The loop is closed after the revision pass. The skill does not self-escalate or repeat this cycle.

• **The report template lives at

[references/ddd-analysis-report-template.md](./references/ddd-analysis-report-template.md).** The skill renders that template by synthesizing agent output into each section following the template's placeholder instructions. It does not invent a structure inline.

• **The synthesized prose is written for a named reader.** As the skill writes each section, it invokes

`han-communication:readability-guidance` and applies the shared standard, holding one audience above the writing: the engineer or product manager reading the context model and deciding what to do next.

Run a DDD Analysis

Step 1: Resolve Scope and Load Project Context

**Bind `$size`.** If the user passed `small`, `medium`, or `large` as the first positional argument, bind `$size` to it. If `$size` is `none provided` and the project config supplies a `default-swarm-size` value via `config-rule.md`, adopt that value as `$size` and note the config as the source. If no value is available from either source, set `$size` to `medium`.

**Resolve the focus area.** Take the remaining argument and conversation context as the focus area. If a focus area was supplied, confirm it resolves to real files using Glob and Read. If it does not resolve to actual files, stop and ask the user to clarify before proceeding. If no focus area was supplied, the scope is the entire repository — do not ask for one.

**Resolve project context.** If `CLAUDE.md` is present (see Project Context), read its `## Project Discovery` section for language, framework, and convention signals. Fall back to `project-discovery.md` if present. If neither exists, discovery agents will infer from surrounding code — note this in every agent brief.

**Note git availability.** Read the `git installed` value from Project Context. If it is empty or reads `not installed`, git is unavailable: note this in the agent briefs and in the report.

**State the driving concern, if any.** If the user named a concern ("I think billing and subscriptions overlap", "we need to underst