@design-ai/cli 4.55.0

package/commands/README.md

@@ -0,0 +1,25 @@
+# Commands
+
+Slash commands. In Claude Code, drop these into `~/.claude/commands/` (or symlink) to invoke as `/<name>`. In Codex CLI or generic agents, use the body as a prompt template.
+
+| Command | What it does |
+| --- | --- |
+| [/design-from-brief](design-from-brief.md) | Generate a complete design system (palette + foundations + component baseline + starter set + handoff) from a one-paragraph product brief. **The most ambitious endpoint.** |
+| [/iterate](iterate.md) | Apply a critique to an existing artifact, produce a revision + changelog. |
+| [/document-from-brief](document-from-brief.md) | Generate documentation (tutorial / how-to / reference / explanation) from a brief. |
+| [/slide-deck](slide-deck.md) | Generate a slide deck outline (talk / pitch / reading) from a brief. |
+| [/design-review](design-review.md) | Run UX audit + a11y review + design critique in parallel and combine. |
+| [/website-improvement](website-improvement.md) | Plan website improvement work with Site Profile, audit checklist, MCP readiness, prompt generation, and handoff report. |
+| [/palette-from-brand](palette-from-brand.md) | Generate a full palette from a brand input (hex, category, or mood). |
+| [/component-spec](component-spec.md) | Spec a single component using the component-spec-writer skill. |
+| [/extract-tokens](extract-tokens.md) | Run the token extractor pipeline. |
+| [/motion-design](motion-design.md) | Spec motion for a screen / component / page. Picks tool, durations, easings; reduced-motion-safe. |
+| [/illustration](illustration.md) | Design or spec an illustration system or piece. Style, voice, format; Korean-market-aware. |
+| [/print](print.md) | Spec a print piece (business card, brochure, poster, packaging). CMYK + Pantone, bleed, finish; KR conventions. |
+| [/video](video.md) | Spec video for marketing, social, or in-product. Length, format, captions, voiceover; KR ad disclosure. |
+| [/game-ui](game-ui.md) | Spec game UI (HUD / menu / inventory / store). Genre + platform + KR conventions + a11y. |
+| [/conversational](conversational.md) | Spec a chatbot / voice / AI chat / live agent. Persona, intents, flows; KR conventions (해요체 / 합쇼체, Bixby / Clova / KakaoTalk channel). |
+| [/spatial](spatial.md) | Spec a VR / AR / MR / WebXR experience. Platform, anchoring, locomotion, comfort, accessibility; Korean Galaxy XR + KR market. |
+| [/stability-review](stability-review.md) | Run the quarterly stability review report and surface promotion candidates, stale files, and next maintenance actions. |
+
+Each file has YAML frontmatter (`description`) and a body. The body is the prompt the command expands to.

package/commands/component-spec.md

@@ -0,0 +1,34 @@
+---
+description: Produce a developer-ready spec for a UI component by comparing implementations across Ant Design, MUI, and shadcn-ui.
+---
+
+Produce a full developer-ready spec for the component named in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect a component name (canonical, kebab-case). Optionally followed by:
+- target framework (`react` | `vue` | `svelte`, default `react`)
+- style system (`tailwind` | `mui` | `antd` | `css-vars`, default `css-vars`)
+
+If ambiguous, ask one clarifying question.
+
+## Steps
+
+1. Look up the component in [`knowledge/components/INDEX.md`](../knowledge/components/INDEX.md). Find references in all three libraries (or the closest analogous component if it's not indexed).
+
+2. Apply the [`component-spec-writer` playbook](../skills/component-spec-writer/PLAYBOOK.md):
+   - Find references → choose canonical API → define anatomy → states → variants → tokens → a11y → edge cases.
+
+3. Output using [`skills/component-spec-writer/TEMPLATE.md`](../skills/component-spec-writer/TEMPLATE.md).
+
+## Done when
+
+- Anatomy diagram + parts table.
+- API table (props, types, defaults, descriptions).
+- States, Variants tables.
+- Tokens consumed list.
+- Accessibility (semantic, ARIA, keyboard, touch).
+- Code example for the most common usage.
+- Edge cases section.
+- Don't section with 2–3 misuses.
+- All referenced from the three libraries cited by file path.

package/commands/conversational.md

@@ -0,0 +1,44 @@
+---
+description: Spec a conversational UI — voice assistant, chatbot, AI chat (LLM), or live-agent chat. Modality, persona, intents, flows, error recovery, accessibility; Korean conventions (Bixby / Clova / KakaoTalk channel) included.
+---
+
+You will produce a conversational UI spec for the surface described in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect:
+- Surface (e.g., "customer support chatbot", "voice search feature", "AI onboarding chat", "Bixby Capsule for ride hailing", "KakaoTalk channel bot").
+- Optionally: type, modality, audience, brand voice, backend.
+
+If ambiguous, ask one clarifying question — but only one. Otherwise apply reasonable defaults and proceed.
+
+## Steps
+
+1. **Pick the type** (voice / chatbot / AI / live agent / hybrid) and modality (voice-only / voice+visual / text-only / multimodal).
+
+2. **Apply the [conversational-ui-designer playbook](../skills/conversational-ui-designer/PLAYBOOK.md)**:
+   - Define persona (honorific level for Korean, formality, warmth).
+   - Spec turn-taking model.
+   - Document top intents OR LLM system prompt summary.
+   - Map key conversation flows.
+   - Plan error recovery.
+   - Plan human handoff.
+   - Apply Korean compliance if applicable (개인정보보호법, 정보통신망법, 자본시장법).
+   - Plan accessibility.
+
+3. **Output** using the structure in PLAYBOOK.md step 11.
+
+## Done when
+
+- Type + modality + use case + audience explicit.
+- Persona (honorific level, formality, warmth, user addressing).
+- Turn-taking model.
+- Top intents / system prompt summary.
+- Conversation flows mapped.
+- Error recovery for each failure type.
+- Human handoff path.
+- Korean compliance addressed if applicable.
+- Accessibility addressed.
+- Required UI components listed.
+- "Don't" catches 2-3 misuses.
+- Verification phase from PLAYBOOK.md passes.

package/commands/design-from-brief.md

@@ -0,0 +1,141 @@
+---
+description: Generate a complete design system (palette + foundations + component baseline + starter set + handoff) from a one-paragraph product brief.
+---
+
+Produce a full design system bootstrap deliverable from the brief in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS` as a single paragraph describing:
+- Product type / category (fintech, social, e-commerce, content, etc.)
+- Audience (consumer / B2B / age / region)
+- Platform (web / mobile / native / cross-platform)
+- Mood / tone (trustworthy / playful / premium / minimal / etc.)
+- Constraints (timeline, budget, existing brand, language)
+
+If the brief is too thin (< 30 words or missing platform/audience), ask **one** clarifying question. Then proceed.
+
+## Steps
+
+This command orchestrates **3 skills in sequence**, citing knowledge as it goes:
+
+### 1. Extract a structured spec from the brief
+
+Distill the prose brief into:
+```yaml
+product_type: <category>
+audience: <consumer | b2b | mixed>
+platform: <web | mobile-web | mobile-native-ios | mobile-native-android | rn>
+mood: [<adjective>, <adjective>]
+language: <ko | en | ko-en>
+density: <comfortable | compact>
+mode: <light | dark | both>
+constraints: [<timeline>, <budget>, <regulatory>]
+brand_color_seed: <hex if mentioned, else null>
+```
+
+Show the structured spec back to the user **briefly** ("Here's how I'm reading the brief...") and proceed.
+
+### 2. Apply `color-palette` skill
+
+Open [`skills/color-palette/PLAYBOOK.md`](../skills/color-palette/PLAYBOOK.md). Follow it end-to-end:
+- If `brand_color_seed`: use as primary.
+- Else: use mood→hue mapping (in the playbook) → derive primary.
+- Generate 11-step ramp + accent + neutrals.
+- Produce light + dark.
+- WCAG-validate the contrast matrix.
+
+If `product_type` is fintech: also add `--color-money-positive` / `--color-money-negative` per [`knowledge/patterns/money-and-amount.md`](../knowledge/patterns/money-and-amount.md).
+
+### 3. Apply `design-system-builder` skill
+
+Open [`skills/design-system-builder/PLAYBOOK.md`](../skills/design-system-builder/PLAYBOOK.md). Follow it end-to-end:
+- Typography: pick font pairing per mood. If `language` includes `ko`: apply Korean adjustments per [`knowledge/i18n/korean-typography.md`](../knowledge/i18n/korean-typography.md).
+- Spacing/radius/elevation/motion tokens.
+- Foundations docs.
+- Component baseline (one, with rationale).
+- Starter component set per `product_type` (use the category extension matrix in the playbook).
+
+If `platform` is `rn`: layer in [`knowledge/platforms/react-native.md`](../knowledge/platforms/react-native.md) — tokens as numbers, no hover, two-system shadows.
+
+### 4. Add Korean considerations (if applicable)
+
+If `language` includes `ko`:
+- Foundations doc gets a "Korean considerations" section.
+- For fintech / commerce: link to [`knowledge/i18n/korean-payments.md`](../knowledge/i18n/korean-payments.md) and [`knowledge/i18n/korean-product-conventions.md`](../knowledge/i18n/korean-product-conventions.md).
+- For pre-launch: link to [`knowledge/i18n/korean-publishing.md`](../knowledge/i18n/korean-publishing.md).
+
+### 5. Apply `handoff-spec` skill (system bootstrap variant)
+
+Open [`skills/handoff-spec/PLAYBOOK.md`](../skills/handoff-spec/PLAYBOOK.md). Produce the engineering hand-off:
+- Style Dictionary config + build commands
+- Token import (Tailwind / shadcn-ui / MUI)
+- Component baseline install commands
+- Custom-component Phase 2 list (each gets spec'd via `component-spec-writer` next)
+- Vendor SDK list (payments, identity, analytics) for the product type
+
+### 6. Output structure
+
+Produce **one** comprehensive markdown file. The structure follows [`examples/dogfood-korean-fintech-system.md`](../examples/dogfood-korean-fintech-system.md):
+
+```markdown
+# Design system: <product name>
+
+> Brief: ...
+> Stack: ...
+> Generated by: /design-from-brief
+
+## 1. Foundations
+   - Color (light + dark)
+   - Typography
+   - Spacing
+   - Radius / Elevation / Motion
+   - Contrast matrix
+
+## 2. Component baseline
+   - Picked: <library>. Why.
+
+## 3. Starter component set
+   | Component | Status | Source |
+   ...
+
+## 4. Foundations document — color usage rules
+
+## 5. Foundations document — Korean considerations (if applicable)
+
+## 6. Output structure (directory tree)
+
+## 7. Hand-off — what eng needs to do
+   1. Style Dictionary setup
+   2. Token import
+   3. Component baseline install
+   4. Custom components Phase 2 list
+   5. Vendor SDKs
+
+## Cited sources
+```
+
+### 7. Run verification
+
+Apply the verification phases of `color-palette`, `design-system-builder`, and `handoff-spec` skills. If any fails, fix and re-output the section.
+
+## Done when
+
+- One output file (or directory of outputs if requested), under 1000 lines.
+- The structured spec is shown at the top.
+- All four foundation tiers are populated (color, type, spacing, motion).
+- Light + dark contrast matrices.
+- Component baseline named with rationale.
+- Starter set matches the product category.
+- Hand-off section is implementable without follow-up.
+- All three skills' verification phases pass.
+
+## Examples
+
+**Brief**: "A 가계부 mobile app for Korean millennials. Need to feel modern and trustworthy but also approachable, not corporate."
+
+**Brief**: "B2B project management SaaS, dense data tables, dark mode primary, English."
+
+**Brief**: "E-commerce for premium Korean cosmetics, mobile-first, brand color is pearl pink, polished/luxurious."
+
+For full reference output, see [`examples/dogfood-korean-fintech-system.md`](../examples/dogfood-korean-fintech-system.md).

package/commands/design-review.md

@@ -0,0 +1,62 @@
+---
+description: Comprehensive design review — runs UX audit + a11y review + design critique in parallel and combines into one report.
+---
+
+You will produce a comprehensive design review of the artifact provided in `$ARGUMENTS`. The artifact may be a screenshot, Figma link, live URL, or HTML/code snippet.
+
+## Steps
+
+1. Identify the artifact, the user goal it serves, the platform (web / mobile / responsive), and the audience.
+
+2. Spawn three reviews **in parallel** as subagents:
+   - `agents/design-critic.md` — hierarchy, craft, decisions, top recommendation.
+   - `agents/a11y-reviewer.md` — WCAG 2.1/2.2 AA pass, keyboard, focus, contrast, semantics.
+   - Apply [`skills/ux-audit/PLAYBOOK.md`](../skills/ux-audit/PLAYBOOK.md) directly — UX best-practice issue catalog.
+
+   For non-Claude-Code agents that can't spawn subagents, run the three sections sequentially in the same prompt.
+
+3. Combine the three outputs into one report:
+
+```markdown
+# Design review: <artifact>
+
+> Goal: <one sentence>
+> Platform: <platform>
+> Reviewer: design-review skill (critic + a11y + ux)
+
+## Top recommendation
+<single sentence — the design-critic's top recommendation>
+
+## Critical (a11y + UX combined, n)
+<all 🔴 issues from a11y-reviewer + ux-audit>
+
+## High (n)
+...
+
+## Medium (n)
+...
+
+## Low (n)
+...
+
+## Hierarchy walk
+<from design-critic>
+
+## Craft notes
+<from design-critic>
+
+## Things that work well
+<combined praise from all three>
+```
+
+4. **Deduplicate**: if a11y and ux both flag the same issue (e.g., "no focus indicator on button"), merge into one entry citing both severity rationales.
+
+5. **Sort within each severity**: a11y issues first (legal/baseline), then UX, then craft. Surface the issues most blocking to the user goal at the top of each severity.
+
+## Done when
+
+- One report file produced.
+- All three lenses are reflected.
+- Top recommendation is a single sentence at the top.
+- No duplicate issues.
+- Praise section keeps the report constructive.

package/commands/document-from-brief.md

@@ -0,0 +1,47 @@
+---
+description: Generate documentation (tutorial / how-to / reference / explanation) from a one-paragraph brief. Picks the right Diátaxis type, applies template, follows technical-writing voice rules.
+---
+
+Apply the [`document-author` skill](../skills/document-author/PLAYBOOK.md) to the brief in `$ARGUMENTS`.
+
+## Input
+
+`$ARGUMENTS` should describe:
+- What's being documented (component / API / process / decision)
+- Type if known (tutorial / how-to / reference / explanation) — else infer
+- Audience (beginner / intermediate / advanced; technical / non-technical)
+- Locale (Korean / English / both)
+- Length target (under 500 / standard / long-form)
+
+If ambiguous: ask one clarifying question.
+
+## Steps
+
+1. Parse the brief into structured spec.
+2. Determine Diátaxis type if not stated. If brief mixes types: split into multiple docs.
+3. Apply [`skills/document-author/PLAYBOOK.md`](../skills/document-author/PLAYBOOK.md) end-to-end.
+4. Output the markdown file with frontmatter.
+5. Run the skill's verification phase.
+
+## Examples
+
+**Brief**: "Document our REST API authentication endpoint. POST /auth/login. For technical readers."
+→ Reference doc with signature, parameters, returns, errors, examples.
+
+**Brief**: "Walk a new user through their first chart in our analytics product. Korean, friendly tone."
+→ Tutorial with step-by-step + Korean ~해요 voice + screenshots references.
+
+**Brief**: "Why we chose ClickHouse over Postgres for analytics."
+→ Explanation doc with problem / alternatives / decision / tradeoffs.
+
+**Brief**: "How to deploy the staging environment."
+→ How-to with TL;DR + steps + variations + pitfalls.
+
+## Done when
+
+- One markdown file (or multi-file directory if split needed).
+- Matches the chosen Diátaxis template.
+- Frontmatter complete.
+- Code samples runnable.
+- Cross-reference section included.
+- Verification phase from `document-author` passes.

package/commands/extract-tokens.md

@@ -0,0 +1,38 @@
+---
+description: Refresh the knowledge base — pull upstream sources, run all extractors, regenerate knowledge/.
+---
+
+Refresh the design knowledge base.
+
+## Steps
+
+1. **Optional pull**: if `$ARGUMENTS` contains `--pull`, run `git -C refs/<repo> pull` for each subdirectory in `refs/` first. Skip otherwise (faster, uses cached state).
+
+2. **Run all extractors**:
+   ```bash
+   bash tools/extractors/run-all.sh
+   ```
+
+3. **Verify outputs**: list every file in `knowledge/` modified in the last 60 seconds. Confirm:
+   - YAML frontmatter is valid (parses, has `title`, `source`, `extracted_at`).
+   - File is non-empty.
+   - File is under 1 MB.
+
+4. **Report**:
+   ```
+   Updated:
+     - knowledge/design-tokens/ant-design.md (33 tokens, 13 presets)
+     - knowledge/typography/mui-type-scale.md (13 variants)
+     - ...
+
+   Skipped (hand-written):
+     - knowledge/colors/color-theory.md
+     - ...
+   ```
+
+## Done when
+
+- All extractors ran exit-zero.
+- Generated files have valid frontmatter.
+- Hand-written files are untouched.
+- Summary report printed.

package/commands/game-ui.md

@@ -0,0 +1,40 @@
+---
+description: Spec game UI — HUD, menus, inventory, store, settings — across genres + platforms. Korean conventions (확률 표시, 본인인증, PC bang) and accessibility built in.
+---
+
+You will produce a game UI spec for the surface described in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect:
+- A surface (e.g., "FPS HUD", "gacha store", "MMO inventory", "pause menu", "main menu").
+- Optionally: genre, platform(s), input methods, audience (Korean / international), monetization type.
+
+If ambiguous, ask one clarifying question — but only one. Otherwise apply reasonable defaults and proceed.
+
+## Steps
+
+1. **Classify genre + surface** to pick layout conventions.
+
+2. **Apply the [game-ui-designer playbook](../skills/game-ui-designer/PLAYBOOK.md)**:
+   - Pick layout per genre.
+   - Spec for each platform (UI scale, reading distance, input).
+   - Define interaction states.
+   - Plan accessibility (subtitles, color-blind, scale, remap, reduce-motion).
+   - Apply Korean compliance if KR market (확률 표시, 본인인증, GRAC, 자막).
+   - Spec performance budget + UI audio.
+
+3. **Output** using the structure in PLAYBOOK.md step 10.
+
+## Done when
+
+- Genre + surface + platform(s) + input(s) explicit.
+- Layout + element positioning specified.
+- Interaction states (default / focus / press / disabled) defined.
+- Input handling for each platform with button prompts.
+- Accessibility options addressed.
+- Korean compliance if applicable.
+- Performance budget specified.
+- UI audio defined.
+- "Don't" catches 2-3 misuses.
+- Verification phase from PLAYBOOK.md passes.

package/commands/illustration.md

@@ -0,0 +1,37 @@
+---
+description: Design and spec an illustration system or single illustration. Picks style, voice, format (SVG / Lottie / PNG), and produces a delivery-ready spec.
+---
+
+You will produce an illustration spec for the scope described in `$ARGUMENTS`.
+
+## Input
+
+Parse `$ARGUMENTS`. Expect:
+- A scope ("define a system for our SaaS", "spec empty-state illustrations", "design a mascot", "optimize this SVG").
+- Optionally: brand voice, target market (Korean / global), existing system reference.
+
+If ambiguous, ask one clarifying question — but only one. Otherwise apply reasonable defaults and proceed.
+
+## Steps
+
+1. **Classify the work** — system definition vs single piece vs mascot vs SVG technical. The classification determines which playbook section applies.
+
+2. **Apply the [illustration-designer playbook](../skills/illustration-designer/PLAYBOOK.md)**:
+   - If system: set style, voice, color, geometry, perspective.
+   - If single piece: pick from existing system; spec subject, size, format, tokens, a11y.
+   - If mascot: brief → silhouette → expression sheet → pose sheet → style guide.
+   - If SVG technical: SVGO + currentColor + accessibility checklist.
+
+3. **Apply Korean conventions** if the market is Korean B2C (mascot-led, soft geometry, warm palette).
+
+4. **Output** using the structure in PLAYBOOK.md step 8.
+
+## Done when
+
+- Style + voice + format choices explicit.
+- Color tokens listed (no raw hex in body).
+- Asset list with size, format, a11y per illustration.
+- Production checklist.
+- Reduced-motion fallback if animated.
+- "Don't" section catches 2-3 misuses.
+- Verification phase from PLAYBOOK.md passes.

package/commands/iterate.md

@@ -0,0 +1,167 @@
+---
+description: Apply a critique or change request to an existing design artifact and produce a revised version with a clear changelog.
+---
+
+Take an existing design artifact and a critique/change request. Produce a revised artifact + a changelog of what changed and why.
+
+## Input
+
+`$ARGUMENTS` is structured as:
+
+```
+<artifact-path-or-content>
+
+---
+
+<critique-or-change-request>
+```
+
+Where:
+- **Artifact**: a path to an existing file in this repo (e.g., `examples/palette-saas-violet.md`) or pasted markdown content.
+- **Critique**: free-form feedback ("primary feels too saturated"), a list of changes ("add error/danger color, increase border-radius"), or a `design-critique` agent output.
+
+If the input doesn't separate the two with `---`, ask one clarifying question.
+
+## Steps
+
+### 1. Diagnose what kind of artifact this is
+
+| Artifact type | Identifying signature |
+| --- | --- |
+| Color palette | Contains "Tokens", contrast matrix, ramp tables |
+| Component spec | Contains "Anatomy", "API", "States" sections |
+| Design system bootstrap | Contains foundations + component baseline + starter set |
+| UX audit report | Contains severity sections (🔴 / 🟠 / 🟡 / 🟢) |
+| Handoff spec | Contains screens + interactions + responsive sections |
+
+The artifact type determines which skill's playbook to re-apply.
+
+### 2. Parse the critique into discrete changes
+
+Decompose the critique into a list of actionable items:
+
+```
+Critique: "Primary feels too saturated. Also need a tertiary text color and the
+focus ring isn't visible enough on light bg."
+
+→ Parsed:
+1. Reduce primary chroma (~0.18 → ~0.13?)
+2. Add `--color-text-tertiary` if not present
+3. Increase focus-ring contrast (current ratio? target 3:1+)
+```
+
+If items are vague (e.g., "make it more modern"), ask for specifics OR pick a defensible interpretation and note the assumption.
+
+### 3. Apply each change with citation
+
+For each item, re-open the relevant skill playbook section and apply per the rules. Cite the rule:
+
+```
+1. Reduced primary chroma from 0.24 → 0.16 (cite color-theory.md: "muted brands
+   feel more trustworthy"). Re-validated contrast: still 5.1:1 on white ✓.
+```
+
+When a change has knock-on effects (e.g., changing primary forces hover/active to be re-derived), apply them all and note them in the changelog.
+
+### 4. Re-run verification
+
+Run the original skill's verification phase against the revised artifact. Fix anything that regressed.
+
+### 5. Output — the revised artifact + changelog
+
+Two outputs:
+
+#### A. Revised artifact
+
+The original artifact, modified in place. **Don't strip the front-matter** — update `extracted_at` to today; bump a `version: 1.1` field if not present (start at 1.0).
+
+#### B. Changelog
+
+```markdown
+# Iteration changelog: <artifact name>
+
+> Revised on: <date>
+> From: <previous version>
+> To: <new version>
+
+## Changes applied
+
+### 1. <change description>
+- **Why**: <reason from critique>
+- **What changed**: <before → after>
+- **Knock-on effects**: <derived adjustments>
+- **Cited rule**: <link to knowledge/ source>
+
+### 2. ...
+
+## Verification
+
+- [✓] All re-validations passed
+- [✓] No regressions vs prior version
+
+## Items NOT applied
+
+If the critique included items I didn't apply, list them with reasoning:
+- "X" — declined because <reason>. Suggest <alternative path> instead.
+```
+
+## Examples
+
+### Example 1 — palette iteration
+
+```
+Artifact: examples/palette-saas-violet.md
+
+---
+
+Primary feels too punchy for an enterprise audit tool. Also our brand has a
+secondary teal that should be the accent. And we need warmer neutrals — current
+slate reads cold against our marketing photos.
+```
+
+Output:
+- Revised palette with chroma reduced + accent swapped from amber to teal + neutrals shifted toward warm-gray (slight C ~ 0.01 with H ~ 50–80°).
+- Changelog explaining each, citing color-theory.md and the warm-neutral rationale.
+
+### Example 2 — component spec iteration
+
+```
+Artifact: examples/component-button.md
+
+---
+
+We don't need the `link` variant — link styling is its own component. And
+add a `size="xs"` for inline buttons in dense tables.
+```
+
+Output:
+- Revised spec: `link` variant removed (with note "use Link component"), `xs` size added (height 24px, font 12px).
+- Changelog noting the API shrink + the new size's spec values + a "Don't" updated to redirect link use.
+
+### Example 3 — UX audit reaction
+
+```
+Artifact: <pasted ux-audit-report-from-yesterday.md>
+
+---
+
+We fixed Critical #1 (contrast) and Critical #2 (missing labels). Re-audit.
+```
+
+Output:
+- Revised audit removing items #1 and #2 from Critical
+- Renumbering the rest
+- Adding any new findings if the artifact text suggests changes elsewhere
+- Changelog with the closure notes for #1 and #2
+
+## When NOT to iterate
+
+If the critique is fundamental ("the entire approach is wrong") rather than incremental ("primary is too saturated"), don't iterate — restart with `/design-from-brief` or fresh `color-palette` skill. Iteration is for refinement, not reset.
+
+## Done when
+
+- Revised artifact has been updated with `extracted_at` + version bumped.
+- Changelog enumerates every change with **why** + **what changed** + **citation**.
+- Items declined are listed with reasoning.
+- No regressions in re-run verification.
+- Both files (revised + changelog) referenced clearly so user knows what to read.