/architectural-analysis

name: "architectural-analysis"
description:
  "Performs deep architectural analysis of a specified module, directory, or feature area by examining structural
  coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or
  review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing
  part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test
  planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended
  options, prior art, or how something works — use research. Not for designing a new interface or contract — use
  design-an-api. Not for planning the change its findings imply — use plan-a-change. Not for discovering bounded
  contexts, ubiquitous language, or where code boundaries diverge from domain boundaries — use ddd-analysis. Not for
  writing documentation or architectural decision records."
arguments: size
argument-hint: "[size: small | medium | large | dynamic] [focus area: module, directory, or feature to analyze]"
allowed-tools: Read, Glob, Grep, Agent, Bash(find *), 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.

• **A focus area is required.** This skill analyzes a specific module, directory, or feature. "Analyze the whole

codebase" is not a valid input. If no focus area resolves to real files, stop and ask the user to name one.

• **The agents own the judgment; the skill orchestrates.** The skill validates the focus area, classifies size, selects

the roster, fans agents out and in, and renders the report. It does not produce findings itself.

• **The discovery roster is signal-selected; the synthesis spine always runs.** `han-core:structural-analyst`,

`han-core:behavioral-analyst`, `han-core:risk-analyst`, and `han-core:software-architect` run at every size BECAUSE structure, runtime behavior, risk-of-inaction, and SOLID synthesis are the irreducible core of an architectural read. Every other specialist is added only when the focus area's signals warrant it and the size band allows it, BECAUSE dispatching an agent whose domain the code does not touch burns tokens and dilutes the report with low-signal findings.

• **Default to small.** Start classification at small and escalate only when a higher-band signal is clearly present.

Borderline signals stay at the smaller band. Under-dispatching is recoverable by re-running at a larger size; over-dispatching is not.

• **Recommendations, not refactors.** The skill never modifies code. `han-core:software-architect` (and

`han-core:system-architect` when dispatched) produce pseudocode sketches for proposed boundaries. Implementation is a separate, later step.

• **Negative results are valuable.** When a dimension is genuinely clean (no concurrency in a pure-functional module,

sound boundaries), the report says so. Agents must not fabricate findings to fill a section.

• **Single pass, no iteration round.** This skill is a fan-out / fan-in, not an iterative loop. If a band proves too

small, the user re-runs at a larger size — the skill does not self-escalate mid-run.

• **System-altitude work is deferred by default.** `han-core:software-architect` defers cross-service / bounded-context

/ trust-boundary findings rather than absorbing them. `han-core:system-architect` is added to the roster only at large size and only when a boundary-crossing seam is actually present. When it is not dispatched, those deferrals are surfaced in the report so the user can dispatch `han-core:system-architect` separately.

• **The report template lives at

[references/architectural-analysis-report-template.md](./references/architectural-analysis-report-template.md).** The skill renders that template by filling placeholders and removing the sections whose agent was not dispatched. It does not invent a structure inline.

• **The synthesized report is written for a named reader.** As the skill writes the final report's synthesized prose, it

sources the shared standard by invoking `han-communication:readability-guidance` and applies it, holding one audience above the writing: the engineer weighing the module's design and deciding whether to change it. Scope that frame per section so the technical specifics that reader needs — file paths, finding IDs, exact conditions, pseudocode — are preserved, never simplified away.

Run an Architectural Analysis

Step 1: Validate the Focus Area and Resolve Project Context

**Bind `$size`.** If the user passed `small`, `medium`, `large`, or `dynamic` as the first positional argument, bind `$size` to it. Anything else is part of the focus-area context, not a size; bind `$size` to the literal `none provided`.

**Resolve the focus area.** Take the remaining argument and conversation context as the focus area. Confirm it resolves to real files using `Glob` and `Read`. Identify t