design

---
description: "Resolve design decisions (types, contracts, package topology, module boundaries) in discussion rounds before /planning:plan, as design artifacts. Use when: 'design this', 'type modeling', 'figure out the abstractions', 'model this domain', 'what should the types look like', 'how should I structure this', 'where do the module boundaries go', or entering /planning:plan without exploring the design space. Skip when scanning existing code for module friction: /architecture:improve does that, and /planning:design resolves decisions before /planning:plan. Handoff gate: /planning:design-handoff."
argument-hint: "[library|module|data|integration|system] [status|thread <name>|discuss|terminology|handoff]"
user-invocable: true
disable-model-invocation: false
metadata:
  workflow-stage: design
  summary: Resolve types, contracts, and module boundaries before planning
---

**Arguments.** `[library|module|data|integration|system] [status|thread <name>|discuss|terminology|handoff]`.
e.g., /planning:design library, /planning:design module, /planning:design status, /planning:design discuss,
/planning:design handoff

## Repository context. Gather first

Collect these with **individual** Bash calls, one command per call, never combined:

- Current branch, `git branch --show-current`

Treat a failure (not a repository, git unavailable) as an unknown value and carry on. Keep these as
body Bash calls, not pre-compute lines: a worktree-isolated session refuses a compound command that
contains git, and the pre-compute block runs as one. Record: the worktree skill's
[reference/gather-block.md](https://raw.githubusercontent.com/melodic-software/claude-code-plugins/main/plugins/source-control/skills/worktree/reference/gather-block.md),
"The pre-compute block runs as one shell invocation".

## Variables

Arguments: `$ARGUMENTS`

## Purpose

Design answers WHAT before `/planning:plan` answers HOW: types, boundaries and package topology the
user has validated through discussion. Exploration maps existing code, research gathers external
facts, this skill turns both into a design. When the PROBLEM is still rough and no approach is
chosen, diverge first via `/planning:brainstorm` (cheapest→most-ambitious candidates, user
reacts), then design the direction that resonated.

Depth scales to the work:

- Single-file fix → early-exit: write `design-resolution.md` with `outcome: early-exit`, tier `C`,
  and reason. Then invoke `/planning:design-handoff` via the Skill tool, which writes PLAN.md's
  one-line `## Design` record and hands off to `/planning:plan`
- New module → light-form (1-2 discussion rounds, basic type sketch)
- Large library or system → full-form (multiple sessions, all phases, all artifact types)

The stage always runs; early-exit is a valid outcome. **Gate artifact:** Tier C and light Tier B
early-exits MUST produce `design-resolution.md` in the topic's design slice
(`<memory_dir>/<topic-slug>/design/`, default `.work/`) so `/planning:plan`'s prerequisite check
can verify the gate without conversation memory.

### design-resolution.md (early-exit artifact)

```markdown
---
outcome: early-exit
tier: C
reason: <one line, e.g. single-file bugfix, docs-only>
---

Tier B (required): the type sketch, inline or as a link to type-inventory.md.
/planning:design-handoff quotes it into PLAN.md's `### Contracts`.
```

## Gates

These hold after a compaction re-attach. Later sections say how to carry them out.

- **Collaborative always.** Never autonomously decide design. Ask in frontier rounds (Key
  behaviors).
- **Abstract is never the agent's pick.** A variation-point verdict of abstract comes only from the
  user: interactively ask, recommending contain; unattended, apply contain and record the question
  as a human decision. Full rule:
  [`${CLAUDE_PLUGIN_ROOT}/reference/variation-points.md`](${CLAUDE_PLUGIN_ROOT}/reference/variation-points.md)
  "Autonomy".
- **Every recommendation carries a `Basis:` line**: `verified` with the `file:line`, tool output,
  or URL it rests on, or `judgment` (non-consequential only). A consequential one (cross-repo,
  shared infrastructure, irreversible, or security) is grounded before it is presented; one
  research cannot settle is withheld, recorded as a `deferred` thread whose research tag names
  the evidence that would settle it.

## Action Router

Parse `$ARGUMENTS` for scope and action:

| Argument | Action |
|----------|--------|
| *(empty)* | **Auto-detect**. Read the PLAN.md Brief + conversation to determine scope and phase. Resume if design artifacts exist. Ask if ambiguous |
| `library` | **Library/API design**. Packages, types, contracts, dependency graph |
| `module` | **Module design**. Domain model, boundaries, contracts. Suggest a domain-event workshop (e.g. EventStorming) when the environment provides one |
| `data` | **Data model design**. Entities, relationships, schema decisions |
| `integration` | **Integration design**. Cross-system contracts, sequence flows, error handling |
| `system` | **System design**. Components, communication patterns, deployment topology |
| `status` | **Status report**. Resolution state per thread and question |
| `thread <name>` | **Deep-dive**. One design thread |
| `discuss` | **Discussion round**. Systematic gap-finding across all artifacts |
| `terminology` | **Naming review**. Cross-cutting naming pass over the full type inventory (see "Terminology pass") |
| `handoff` | **Handoff gate**. Delegates to `/planning:design-handoff` (see "Handoff gate") |

## Phases

Phases may interleave. Track which have produced artifacts and which have open questions.

All artifacts live in `<memory_dir>/<topic-slug>/design/` (default `.work/`), never committed;
`/planning:plan`'s gate reads the gate files (`design-threads.md`, `design-resolution.md`) from
there. Placement:
[`${CLAUDE_PLUGIN_ROOT}/reference/artifact-protocol.md`](${CLAUDE_PLUGIN_ROOT}/reference/artifact-protocol.md).
`/planning:design-handoff` writes the durable content (module layout, contracts, variation
verdicts, conventions followed) into PLAN.md's `## Design`, the copy that reaches the plan, the
implementer's brief, and the pull request body or linked issue where PLAN.md is published. Derive
`<topic-slug>` from the task or branch name (kebab-case, ≤40 chars; shared with `/planning:interview` and `/planning:plan`). Skip
artifact creation for read-only actions (`status`).

### Phase 1: Problem Space Decomposition

Read the Brief's `### Problem` before decomposing; absent, start from the `Problem`, `Intent (why,
in the user's words)` and `Chosen direction` lines of `<memory_dir>/<topic-slug>/brainstorm.md`'s
`## Handoff` block when it exists; with neither, establish it:
[`${CLAUDE_PLUGIN_ROOT}/context/problem-framing.md`](../../context/problem-framing.md). Its
`time_units` user layer is `${user_config.time_units}` (unexpanded means unset).

Scan the whole problem space broadly before diving into any single capability. For each capability
or concern:

- Domain concepts (nouns, verbs, relationships)
- Invariants (rules that must always hold)
- Storage needs (stateless? persistent? app-specific?)
- Cross-app reuse: shared-library-worthy vs app-specific, following the consuming project's
  library-organization and dependency-preference conventions when it declares them

When the work adds a requirement to existing code, ask before Phase 3: had this requirement been
known when the code was first written, which types and boundaries would it have? Take that answer
as the target shape, not the current shape with the requirement bolted on.

Produce: `capability-matrix.md` (library scope) or equivalent per scope.

### Phase 2: Design Threads

Identify cross-cutting decisions that affect multiple capabilities. For each thread: name the
decision, list concrete options with tradeoffs, and resolve through discussion or defer with
rationale + research tag. Status: **resolved** (decision made), **directional** (direction agreed,
details deferred), **deferred** (needs research).

**Two-candidate step.** Take it when the codebase has nothing to copy for the thread, more than one
approach is workable, and the decision is hard to reverse (a public contract, a stored format, a
boundary other modules will build on):

1. Write the criteria the candidates will be judged by into the thread before drafting any
   candidate.
2. Draft at least two candidates that differ in structure: who owns the state, where the module
   split falls, or what shape the contract takes. A renamed or reordered copy of the first is not a
   second candidate.
3. Judge each against the written criteria, and record the rejected ones with the reason in
   `design-threads.md`.

When the thread is about how a screen or interaction looks or feels, invoke
`/prototype:explore-directions` via the Skill tool when it is among the available skills, after
confirming the scope of the throwaway with the user; otherwise run the three steps here, describing
each candidate in prose.

Open these threads when their trigger holds:

- **Shared-state**: a type can be read and changed by more than one concurrent actor (threads,
  processes, overlapping requests, background jobs). Cover which actors write it, what a reader
  sees halfway through an update, and whether the type is confined to one owner, immutable, or
  guarded.
- **Tenancy posture** (early): SaaS or B2B org-scoped products. Single- vs multi-tenant, isolation
  model, shared vs tenant-scoped data catalog.
- **Refactoring posture**: exploration surfaces high coupling, large types, or multi-responsibility
  files (refactor or strangler scope). Characterization-test strategy, seam map, incremental
  extract order, change budget.
- **Test-seam posture**: any feature with a testable surface. Sketch where its tests will attach;
  reuse an existing seam before adding one, put any new seam as high in the stack as it can go, and
  aim for the fewest seams that cover the surface. The change→test-type mapping lives in
  `/testing:plan`'s classification table; cite it when the `testing` plugin is enabled, otherwise
  apply standard test-design judgment. Confirm the seam sketch with the user before design output
  is finalized.

**Variation-point pass.** Always for `integration`, `module`, and `system`; for `library` and
`data`, when the design touches an external system or a domain category. List every variation
point (every external integration is one), ask the two questions (likelihood of a second variant,
cost of change after shipping), and open one thread per point that resolves to a verdict: abstract
now, contain now and abstract later (the default for anything external), or leave inline (internal
one-offs only). Run the leak test on every abstraction and contained boundary, and place seams
where the solution's existing architecture style already puts them. Questions, verdicts, leak test,
autonomy rule, and sources:
[`${CLAUDE_PLUGIN_ROOT}/reference/variation-points.md`](${CLAUDE_PLUGIN_ROOT}/reference/variation-points.md).
A variation-intent answer from `/planning:interview` is settled, never re-asked.

Produce: `design-threads.md`

### Phase 3: Type Modeling

The phase ends with a `type-inventory.md` in which every type traces to a call site that needs it,
and each type's shape is set by the operations its busiest paths run on it. Two checks prove it:

- **Call sites before types.** From consumer code, sketch two or three brief calls into the new
  contract, written as its users will write them, before any type has a name; for a library or
  API, at least one sits inside the importing package. A type enters the inventory only if those
  calls need it, given the capabilities.
- **Operations set structure.** Each entry lists its operations (lookup by key, ordered walk,
  append, bulk replace) with the busiest-path ones flagged, and its structure is the one those
  flagged operations favor.

Apply [`reference/type-discipline.md`](reference/type-discipline.md). When the repository has a
`tsconfig.json` or the change touches `.ts`, `.tsx`, `.mts` or `.cts` files, also read
[`reference/type-discipline/typescript.md`](reference/type-discipline/typescript.md).

- Records, enums, strongly-typed IDs, value objects
- Contracts: interfaces with method signatures
- Read and follow the consuming project's naming conventions (interface naming, context-relative
  naming, collisions with common library types, namespaces) before naming
- Follow the project's codified design principles (e.g. Law of Demeter, dependency direction,
  disambiguating overloaded terms) where declared; otherwise low-coupling/high-cohesion defaults
- Invoke `/domain-driven-design:curate-language` via the Skill tool (if that plugin is enabled)
  the moment a domain term resolves, so the glossary owner applies the consumer's format,
  placement, and context routing; without it, record the resolved term and rejected synonyms in
  the design artifacts

Produce: `type-inventory.md`

Close Phase 3 by auditing the inventory: for each type, follow one value from where it is made to
where it is read. A fault at any stop sends that type back to the design threads.

1. **Where it is made.** When a schema, spec or migration already describes the shape, the entry
   derives from it instead of redrawing it. A value from outside the program becomes this type
   where it arrives, and nothing further in validates that input again.
2. **What it holds.** Try to write a mix of field values the domain forbids; a type that accepts it
   is too loose. For each type the design strengthened, name the function that would fail on part
   of its input without the extra strength; with none, the strength guards nothing, and that is a
   fault too.
3. **Where it is read.** Picture one more variant: every reading site must then fail to compile,
   not keep running silently. On the same path, every cast, assertion or suppression has a check
   in front of it.

Once type modeling stabilizes, run the `terminology` action over the whole inventory; per-type
naming during modeling does not replace it.

### Phase 4: Package/Module Topology

- Package or module structure with dependency graph
- What goes where (abstractions vs implementation vs service defaults)
- Adapter surfaces (infrastructure boundary)
- Dependency direction enforcement per the project's declared layer rules

Produce: `library-topology.md` (library scope) or equivalent per scope.

When the dependency graph reads more clearly visually, optionally also emit a self-contained HTML
topology view to the OS temp directory, never beside `library-topology.md`, which stays the record.
Rules:
[`${CLAUDE_PLUGIN_ROOT}/reference/artifact-protocol.md`](${CLAUDE_PLUGIN_ROOT}/reference/artifact-protocol.md).

### Phase 5: Discussion Rounds

Each round:

1. Re-read all design artifacts.
2. Record as design threads: underspecified types, missing contracts, boundary friction, pattern
   concerns, and design-default gaps (configurability, extension axes, observability,
   testability).
3. Present findings ordered by tweak likelihood (the presentation default `/planning:plan` Step 5
   documents): public contracts, data shapes, and user-facing surfaces lead; settled-looking
   mechanical threads sit at the bottom. Order only; thread dependencies still govern what can
   resolve when.
4. When discussion surfaces project-wide principles, suggest codifying them in the project's own
   rules.

Continue until no new gaps surface, then run the `handoff` action.

## Lifecycle and reversibility

Skip on early-exit, `status`, or trivial single-file work. Otherwise call each significant decision
a one-way or two-way door, prompt an ADR for each one-way door, and scale investment by subdomain
and quality bar: [`reference/reversibility.md`](reference/reversibility.md).

## Terminology pass (`terminology` action)

Over the full type inventory, once type modeling stabilizes:

1. Check interface-naming form and context-relative naming against the project's conventions
2. Check collisions with common library/framework type names (e.g. a bare `Result<T>` 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 `/domain-driven-design:curate-language` via the Skill tool (if enabled) to sync resolved
   terms and rejected synonyms into the project's glossary; the table above is the standalone
   fallback

## Handoff gate (`handoff` action)

Invoke `/planning:design-handoff` via the Skill tool. It is the only gate implementation: it checks
`design-threads.md` (or the `design-resolution.md` early-exit artifact) and on PASS emits the
plan-ready summary and resume prompt. This skill carries no gate criteria of its own; criteria changes land in
`/planning:design-handoff` only.

**Stub files (`scaffold_stubs`)**. Before invoking the gate, resolve `scaffold_stubs`, lowest layer
first: the default `false`; the plugin's user config (`${user_config.scaffold_stubs}`, where a
literal unexpanded value means unset); then the `scaffold_stubs` key of the repository's
`docs/conventions/planning.yaml`, which wins when set, read only when the working directory's git
root is neither `$HOME` nor an ancestor of it. Only the bare booleans `true` and `false` are valid:
any other value, a quoted `"true"` included, is named with its file (or user config), key and
value, and that layer is dropped, so a valid higher layer still wins and otherwise the key is
`false`. Report one line naming the value and its layer, e.g.
`scaffold_stubs: true (docs/conventions/planning.yaml)`. Keys and layers:
[`${CLAUDE_PLUGIN_ROOT}/reference/config.md`](${CLAUDE_PLUGIN_ROOT}/reference/config.md).

With `true`, add a `## Stub scaffold` section to `design-threads.md` (or to `design-resolution.md`
on an early exit) listing every new file the design introduces, each with the signatures it will
declare (types, function and method signatures, exported constants), from the resolved type
inventory and contracts. Each stub body is the language's ordinary not-implemented form (for
example `raise NotImplementedError` in Python or `todo!()` in Rust), with no per-language reference
file. After the gate passes, the handoff output names those files and signatures so
`/planning:plan` can place the stub phase. With `false`, write no such section and name no stubs.

## Scope-specific artifacts

| Scope | Primary artifacts | Typed artifact | Dialect |
|-------|-------------------|----------------|---------|
| `library` | capability-matrix.md, type-inventory.md, library-topology.md, design-threads.md | none | none (no typed artifact, so no scope label) |
| `module` | domain-model.md, module-boundary.md, contracts.md, design-threads.md | none | none (no typed artifact, so no scope label) |
| `data` | entity-relationships.md, schema-decisions.md, design-threads.md | `entity-relationships.md` | mermaid `erDiagram` by default; DBML when `diagram_dialect.data` resolves to `dbml` |
| `integration` | contract-spec.md, sequence-flows.md, design-threads.md | `sequence-flows.md`, `contract-spec.md` | mermaid `sequenceDiagram` for the flows; an OpenAPI 3.1 sketch for the contract spec |
| `system` | component-map.md, communication-patterns.md, design-threads.md | `component-map.md`, and only when `diagram_dialect.system` names a dialect | a C4 container view in LikeC4 or C4-PlantUML. Never Mermaid's experimental C4 support |

`design-threads.md` is common across all scopes.

### Typed artifacts: dialect and scope label

Typing adds a declared dialect and a scope label to artifacts this skill already emits; no new
file. Everything the **Typed artifact** column does not name (`schema-decisions.md`,
`communication-patterns.md`, every `library` and `module` artifact) stays prose with no dialect and
no scope label. `component-map.md` is likewise untyped prose with no scope label whenever
`diagram_dialect.system` is unset, so a downstream lookup finds nothing rather than an unlabeled
diagram.

**The scope label.** Every typed artifact opens with frontmatter naming the producing scope and the
dialect of its fenced block:

```markdown
---
scope: data
dialect: mermaid
---
```

`scope` is one of `data`, `integration`, `system`. `dialect` is one of `mermaid`, `dbml`,
`openapi-3.1`, `likec4`, `c4-plantuml`. `/work-items:decompose` (when the `work-items` plugin is
enabled) reads the label to inline the artifact under a provenance note naming scope and dialect;
without that plugin the label is inert. The body is one fenced block in the declared dialect,
followed by the artifact's prose. Tag the fence with the renderer name: `mermaid`, `dbml`, `yaml`
for the OpenAPI 3.1 sketch, `likec4`, `plantuml`. An `integration` session labels two artifacts,
one per typed file.

**Resolving the dialect.** `diagram_dialect` is a team-shared convention key split by artifact kind
(`diagram_dialect.data`, `diagram_dialect.system`). Resolve it per session, before writing a typed
artifact:

1. Anchor at the repository root: `${CLAUDE_PROJECT_DIR}` when set, otherwise
   `git rev-parse --show-toplevel`. Never a CWD-relative read.
2. Resolve the convention home `<home>` from the pointer line in the marked
   `<!-- BEGIN GENERATED: convention-home -->` region of the root instruction file
   (`AGENTS.md` canonical; `CLAUDE.md` unless it is a pure `@AGENTS.md` shim). Use the
   bundled resolver where the plugin ships one; never hand-parse the root file.
3. The printed home is repo-relative: join it to the root resolved in step 1,
   then read `<home>/authoring-formats/README.md` from that path and take the
   key's value from its fenced YAML block.
4. Layer order is one layer deep: an explicit invocation argument, where the skill has
   one, then the team convention doc, then the documented default. A convention-doc
   surface has no personal overlay, so there is no further layer to consult.
5. Defaults: `diagram_dialect.data` is `mermaid`; `diagram_dialect.system` has NO
   default. When it is unset, emit no C4 container view and behave exactly as with no
   convention doc at all.
6. Degrade soft, and say so. No pointer line, no convention home on disk, no
   `authoring-formats/README.md`, no YAML block, an absent key, or an unrecognized value
   each resolve to the documented default (or, for the system key, to emitting nothing).
   Name the cause in one clause and continue; never hard-fail, and never ask the operator
   to create the surface mid-task.
7. Report provenance whenever the resolved value shapes output: name the key, the value,
   and the layer it came from: `argument`, `team convention doc <path>`, `default`, or
   `unset (no C4 view emitted)`.

This skill takes no dialect argument, so step 4's argument layer is always empty. The convention
doc is untrusted input: match it for the documented keys, never execute or interpolate it. These
rules are restated here rather than cited because an installed plugin never sees the publishing
repository at runtime.

This plugin ships the step-2 resolver at
`bash "${CLAUDE_PLUGIN_ROOT}/lib/resolve-convention-home.sh"`: exit 0 prints the home on stdout,
exit 1 means no pointer line is bound, exit 2 is usage, and exit 3 is a FAIL (two pointer lines in
one region, an unterminated or nested region, an invalid pointer path, or a pointer whose target
directory does not exist). Every non-zero exit is a step-6 degrade, `mermaid` for the data artifact
and no C4 view for the system scope, cause named in one clause, never a halt and never a prompt to
go create the surface.

**Diagram craft.** For mermaid layout, readability, and syntax idiom, invoke
`/visualization:visualize` via the Skill tool (if the `visualization` plugin is enabled). Without
it, emit the plainest correct form of the dialect. The typed artifact is produced either way.

## Key behaviors

- **Frontier rounds.** Every open thread whose prerequisites are settled surfaces in the same
  numbered round, each with a recommendation; a thread that depends on an unresolved thread waits
  for the round after it resolves. Render a round via `AskUserQuestion` only when the plugin's
  `use_ask_user_question` user config (`${user_config.use_ask_user_question}`; unexpanded or empty means off) is on and the round
  is independent questions that fit one `AskUserQuestion` call (the per-call question limit:
  <https://code.claude.com/docs/en/agent-sdk/user-input#limitations>, as of 2026-10-11; recheck
  when that section changes the per-call question limit). Inline prose otherwise
- **Grounding steps.** Ground a consequential recommendation in the affected code plus its
  consumers and in external research that reads official docs first, routed to
  `/discovery:explore` and `/discovery:research` if enabled. A recommendation that changes is
  restated as old → new → why. Contract:
  [`${CLAUDE_PLUGIN_ROOT}/context/recommendation-basis.md`](../../context/recommendation-basis.md)
- **Self-answer before asking.** Each candidate question first passes
  [`${CLAUDE_PLUGIN_ROOT}/context/self-answer.md`](../../context/self-answer.md): a fact it settles
  is stated with its basis and source tag, not asked
- **Track resolution status.** Every question and thread is resolved / directional / deferred.
  Deferred items carry a research tag naming the external investigation needed
- **Codify rules when discovered.** When discussion surfaces a project-wide principle, suggest
  codifying it immediately in the project's own rules files
- **Incremental artifacts.** Build artifacts as discussion progresses and update them as decisions
  evolve. Re-read multi-turn shared artifacts (`design-threads.md` and peers) from disk before
  every write, since another turn or agent may have changed them, and prefer appending or refining
  over wholesale rewrites
- **Dependency order awareness.** Surface which decisions block others so `/planning:plan` can
  sequence phases
- **Resume from prior state.** When design artifacts exist in the topic's design directory, read
  them, summarize current state, and identify remaining gaps
- **Suggest adjacent skills.** When a domain-event workshop fits better for domain modeling,
  suggest it if available. Suggest `/discovery:research` (if enabled) for a deferred item needing
  external research, and the `terminology` then `handoff` actions at the session tail
- **Design defaults (non-trivial scopes only).** For `library`, `module`, `data`, `integration`,
  and `system` scopes, when discussion touches configurability, extension points, observability,
  or testability, open a design thread for it. Extension points start from the Phase 2
  variation-point pass. Skip on early-exit, `status`, or trivial single-file work. Apply
  [`reference/design-defaults.md`](reference/design-defaults.md) first (quality bar, consumer
  standards, the Brief's quality requirements, generalize-now-or-wait, per-tenant configurability
  as vendor guidance), then recommend from SRP, OCP, LSP, ISP, DIP, composition over inheritance,
  reuse and DRY of knowledge, coupling and cohesion, information hiding, deep modules and YAGNI per
  [`design-principles.md`](${CLAUDE_PLUGIN_ROOT}/reference/design-principles.md).

## What this skill does NOT do

- **Implementation planning**: `/planning:plan` (phases, sanity checks, file-level work items)
- **Code writing**: the implementation stage
- **External research**: the research capability; this skill synthesizes its results
- **Diagram craft**: this skill selects the dialect; layout and idiom route to
  `/visualization:visualize` if enabled, else the plainest correct form is emitted
- **UI/UX design**: user research, flows and information architecture are
  `/user-experience:shape` (if enabled); look and response are `/user-interface:design` (if
  enabled)
- **Domain event workshops**: an EventStorming-style capability; this skill may suggest it within
  module design
- **Product intent**: `/planning:prd` (problem, users, success metrics)
- **Intent contract**: `/planning:interview` (goal, constraints, acceptance criteria)

## Next

- The design is finished: /planning:design-handoff gates it and writes it into PLAN.md's `## Design` for /planning:plan.
- A name is still undecided: /naming:name-it-better.
- A resolved decision is worth keeping: /architecture:record-decision.

## Relationship to other skills

| Skill | Relationship |
|-------|-------------|
| `/planning:interview` | **Before.** Locks the brief (scope + constraints); design explores the solution space within them |
| `/domain-driven-design:curate-language` | **During.** Owns project-glossary updates when design resolves domain language; not type or boundary design |
| `/visualization:visualize` (if enabled) | **During.** Owns visual-form choice and mermaid craft for a typed artifact's fenced block |
| `/work-items:decompose` (if enabled) | **After.** Reads a typed artifact's `scope` and `dialect` label to inline it into the spec container with a provenance note, and quotes each slice's part of PLAN.md's `## Design` into that slice's body |
| `/discovery:explore` (if enabled) | **Before.** Maps existing code; design creates what SHOULD exist |
| `/discovery:research` (if enabled) | **Before + parallel.** Gathers external facts; deferred research items can run in parallel |
| `/planning:design-handoff` | **The gate.** Owns the design→plan gate criteria and the plan-ready summary |
| `/planning:plan` | **After the handoff gate.** Produces HOW; when design artifacts exist it consumes them instead of re-deriving design |

• SKILL.md 29 KB
• evals/evals.json 21 KB
• reference/design-defaults.md 6 KB
• reference/reversibility.md 6 KB
• reference/type-discipline.md 3 KB
• reference/type-discipline/typescript.md 8 KB