@hegemonart/get-design-done 1.41.5 → 1.43.0

package/skills/scan/scan-procedure.md

@@ -7,8 +7,8 @@ tags: [scan, procedure, extracted, pipeline-stage, design-system, audit]
 last_updated: 2026-05-18
 ---
 
-Source: extracted from `skills/scan/SKILL.md` (Phase 28.5 rework — D-10 extract-then-link).
-The skill's load-bearing workflow stays in `../skills/scan/SKILL.md`; this file holds the
+Source: extracted from `skills/scan/SKILL.md` (Phase 28.5 rework - D-10 extract-then-link).
+The skill's essential workflow stays in `../skills/scan/SKILL.md`; this file holds the
 detail the agent reaches for when executing a specific step (STATE integration, connection
 probes, extraction grep commands, scoring, output contracts).
 
@@ -16,7 +16,7 @@ probes, extraction grep commands, scoring, output contracts).
 
 Detailed procedure for the get-design-done `scan` pre-pipeline initializer. Companion to
 `../skills/scan/SKILL.md`. Read this file when executing a specific scan step; the SKILL.md
-keeps the load-bearing workflow + decision tree, this file holds the deep methodology.
+keeps the essential workflow + decision tree, this file holds the deep methodology.
 
 ---
 
@@ -28,18 +28,18 @@ At scan entry, before running any step:
 
 1. Check for `.design/STATE.md`.
    - **If missing:** create it from `../reference/STATE-TEMPLATE.md`. Set the following fields:
-     - `started_at` = now (ISO 8601) — **set once; never overwrite on subsequent runs**
+     - `started_at` = now (ISO 8601) - **set once; never overwrite on subsequent runs**
      - `last_checkpoint` = now
      - frontmatter `stage` = `scan`
      - `<position>` `stage` = `scan`, `status` = `in_progress`, `task_progress` = `0/8`
-   - **If present and `stage == scan` and `status == in_progress`:** RESUME — skip already-complete steps using `task_progress` as offset. Do not reset `started_at`.
+   - **If present and `stage == scan` and `status == in_progress`:** RESUME - skip already-complete steps using `task_progress` as offset. Do not reset `started_at`.
    - **Otherwise (normal transition):** set frontmatter `stage = scan`, `<position>` `stage = scan`, `status = in_progress`, `task_progress = 0/8`. Do not overwrite `started_at`.
 
 ### Probe connection availability
 
-Run both probes below. MCP tools may be in the deferred tool set — **always call ToolSearch first**; without it, a deferred tool invocation fails silently.
+Run both probes below. MCP tools may be in the deferred tool set - **always call ToolSearch first**; without it, a deferred tool invocation fails silently.
 
-**Figma probe (variant-agnostic — resolves any server prefix matching `/figma/i`):**
+**Figma probe (variant-agnostic - resolves any server prefix matching `/figma/i`):**
 
 ```
 Step A1 — Keyword ToolSearch:
@@ -80,7 +80,7 @@ Note: scan probes **both** connections because the State Integration block is th
 
 Run all 4 Phase 8 probes at scan entry. Results are written to STATE.md `<connections>` so downstream stages (verify, compare, darkmode, plan, design) do not re-probe unless needed.
 
-Note: as of v1.0.7.1, Figma is a single connection (`figma:` key) covering reads + writes — no separate `figma_writer:` probe. The Wave A Figma probe above is the sole Figma availability check.
+Note: as of v1.0.7.1, Figma is a single connection (`figma:` key) covering reads + writes - no separate `figma_writer:` probe. The Wave A Figma probe above is the sole Figma availability check.
 
 **preview:**
 
@@ -178,7 +178,7 @@ Update `last_checkpoint` to now. Write `.design/STATE.md` to disk before proceed
 
 ---
 
-## Step 1 — Orient
+## Step 1 - Orient
 
 Identify the project structure before scanning:
 
@@ -204,7 +204,7 @@ Record: framework, CSS approach, component count, style file count, token system
 `src/` -> `app/` -> `pages/` -> `lib/`. Substitute the detected source root (the matched
 directory name) into every subsequent grep command in this SKILL.md that currently references
 `src/` as the primary component root. If none of these directories exist, log
-"No standard source directory found — manual audit required" and proceed with the unchanged
+"No standard source directory found - manual audit required" and proceed with the unchanged
 command (the `2>/dev/null` guards will suppress the no-match output).
 
 Log the detected source root in DESIGN.md frontmatter as:
@@ -212,7 +212,7 @@ Log the detected source root in DESIGN.md frontmatter as:
 
 ---
 
-## Step 2 — Extract Color System
+## Step 2 - Extract Color System
 
 ```bash
 # All hex colors used
@@ -243,13 +243,13 @@ Produce a color inventory table:
 
 ---
 
-## Step 2A — Figma Token Augmentation
+## Step 2A - Figma Token Augmentation
 
-**Skip this step if `figma` is `not_configured` or `unavailable` in `.design/STATE.md` `<connections>`.** Fall back to the grep-based token extraction from Step 2 alone — no error, no warning. Scan continues normally.
+**Skip this step if `figma` is `not_configured` or `unavailable` in `.design/STATE.md` `<connections>`.** Fall back to the grep-based token extraction from Step 2 alone - no error, no warning. Scan continues normally.
 
 ### If `figma: available`
 
-Read the resolved prefix from STATE.md `<connections>` (e.g., `prefix=mcp__figma__` or `prefix=mcp__figma-desktop__`) and call `{prefix}get_variable_defs` (no arguments — returns all variables in the active Figma file).
+Read the resolved prefix from STATE.md `<connections>` (e.g., `prefix=mcp__figma__` or `prefix=mcp__figma-desktop__`) and call `{prefix}get_variable_defs` (no arguments - returns all variables in the active Figma file).
 
 > If no Figma file is open, the call errors. Treat any error as a graceful skip: update STATE.md `<connections>` to `figma: unavailable` and continue with Step 2 results only.
 
@@ -261,7 +261,7 @@ Read the resolved prefix from STATE.md `<connections>` (e.g., `prefix=mcp__figma
 | `FLOAT` | `spacing/*` | Add row to spacing system |
 | `FLOAT` | `font-size/*` or `typography/*` | Add row to typography system |
 
-Record both the variable **NAME** and resolved value — not just the value. `get_variable_defs` returns resolved values only (no alias chains); the name often carries semantic meaning the value cannot.
+Record both the variable **NAME** and resolved value - not just the value. `get_variable_defs` returns resolved values only (no alias chains); the name often carries semantic meaning the value cannot.
 
 **Multi-mode (Light/Dark):** when `valuesByMode` has multiple entries, extract all values and note dark-mode existence in the DESIGN.md color section.
 
@@ -284,13 +284,13 @@ When this step runs successfully:
 
 ### Caveats
 
-- `get_variable_defs` returns **resolved values only** — no alias chains. Always record the variable NAME alongside the value; the name carries semantic meaning not present in the hex/float alone.
+- `get_variable_defs` returns **resolved values only** - no alias chains. Always record the variable NAME alongside the value; the name carries semantic meaning not present in the hex/float alone.
 - **Multi-mode:** when Light and Dark mode values differ, record both. Note dark-mode variable presence in the DESIGN.md color section.
 - **No file open:** if `get_variable_defs` errors (most commonly because no Figma file is open), skip this step entirely and update STATE.md `<connections>` to `figma: unavailable`. Do not error the scan stage.
 
 ---
 
-## Step 3 — Extract Typography System
+## Step 3 - Extract Typography System
 
 ```bash
 # Font families
@@ -310,9 +310,9 @@ grep -rEoh "line-height:\s*[0-9.]*|leading-[a-z0-9]*" src/ styles/ --include="*.
 
 1. How many font families? (> 2 = violation unless one is monospace)
 2. Are font sizes from a defined scale or arbitrary px?
-3. Map found sizes to nearest modular scale — identify outliers
+3. Map found sizes to nearest modular scale - identify outliers
 4. Are weights following hierarchy? (body 400, headings 600-700, never 300 on small text)
-5. Line-height on body text — is it 1.5–1.75?
+5. Line-height on body text - is it 1.5–1.75?
 6. Any of the reflex fonts without apparent brand reason? (Inter, DM Sans, Space Grotesk, Plus Jakarta Sans)
 
 Read `${CLAUDE_PLUGIN_ROOT}/reference/typography.md` for comparison criteria.
@@ -321,7 +321,7 @@ Produce a typography inventory table.
 
 ---
 
-## Step 4 — Extract Spacing System
+## Step 4 - Extract Spacing System
 
 ```bash
 # All CSS spacing values
@@ -340,7 +340,7 @@ Grid compliance: are spacing values in the 4/8/12/16/24/32/48/64 series? Flag an
 
 ---
 
-## Step 5 — Anti-Pattern Audit
+## Step 5 - Anti-Pattern Audit
 
 Read `${CLAUDE_PLUGIN_ROOT}/reference/anti-patterns.md`. Run all grep commands.
 
@@ -369,13 +369,13 @@ For each finding: record the count, a sample file:line, and severity (BAN = P0,
 
 ---
 
-## Step 6 — Component Inventory
+## Step 6 - Component Inventory
 
 If `--quick`, skip this step.
 
 ### Component pattern indicators
 
-A bare `grep -rln "className" src/` produces false positives on type-only files, test files, utility helpers, and server-only modules — none of which are components. Instead, use a three-pass multi-signal filter. A file qualifies as a component only when **all three indicators** match:
+A bare `grep -rln "className" src/` produces false positives on type-only files, test files, utility helpers, and server-only modules - none of which are components. Instead, use a three-pass multi-signal filter. A file qualifies as a component only when **all three indicators** match:
 
 1. Has a JSX-like return: `grep -lE "return\s*\(" <file>`
 2. Has className or class attribute usage: `grep -lE "className=|class=" <file>`
@@ -415,13 +415,13 @@ Identify:
 - Which have design system-level implementation vs. one-off styles
 - Which are candidates for design system extraction
 
-### --full mode per-file output
+### `--full` mode per-file output
 
 If `--full` flag is set, emit one row per file in the component inventory:
 
 | File | Component Count | Styling Approach | Token Usage | Issues |
 |------|-----------------|------------------|-------------|--------|
-| src/components/Button.tsx | 1 | Tailwind | var(--primary), p-4, gap-2 | heading weight dup |
+| src/components/Button.tsx | 1 | Tailwind | `var(--primary)`, p-4, gap-2 | heading weight dup |
 | src/components/Card.tsx | 1 | CSS Module | styles.card, rgb(...) | hardcoded color |
 
 Columns:
@@ -435,7 +435,7 @@ Without `--full`, the component inventory is a summary count only (not per-file)
 
 ---
 
-## Step 7 — Score All 7 Categories
+## Step 7 - Score All 7 Categories
 
 Read `${CLAUDE_PLUGIN_ROOT}/reference/audit-scoring.md`. Score each category 0–10 based on what you found in Steps 1–6.
 
@@ -449,7 +449,7 @@ Calculate grade (A=90–100, B=75–89, C=60–74, D=45–59, F=0–44).
 
 ---
 
-## Step 8 — Generate Design Debt Roadmap
+## Step 8 - Generate Design Debt Roadmap
 
 Collect all findings from Steps 1–6. Classify each:
 
@@ -462,27 +462,27 @@ Collect all findings from Steps 1–6. Classify each:
 
 Group into **debt themes**:
 
-1. **Foundation** — token layer, design system architecture
-2. **Typography** — scale, hierarchy, families
-3. **Color** — palette, semantics, dark mode
-4. **Accessibility** — contrast, focus, semantics, motion
-5. **Anti-Patterns** — BAN + SLOP removals
-6. **Components** — inconsistency, missing primitives
-7. **Motion** — easing, duration, reduced-motion
+1. **Foundation** - token layer, design system architecture
+2. **Typography** - scale, hierarchy, families
+3. **Color** - palette, semantics, dark mode
+4. **Accessibility** - contrast, focus, semantics, motion
+5. **Anti-Patterns** - BAN + SLOP removals
+6. **Components** - inconsistency, missing primitives
+7. **Motion** - easing, duration, reduced-motion
 
 For each debt item, estimate effort:
-- `XS` — single-line grep-and-replace (< 30 min)
-- `S` — localized fix in 1–3 files (< 2h)
-- `M` — affects 5–15 files, requires testing (2–8h)
-- `L` — architectural change, touches 15+ files (1–3 days)
-- `XL` — design system rebuild (3+ days)
+- `XS` - single-line grep-and-replace (< 30 min)
+- `S` - localized fix in 1–3 files (< 2h)
+- `M` - affects 5–15 files, requires testing (2–8h)
+- `L` - architectural change, touches 15+ files (1–3 days)
+- `XL` - design system rebuild (3+ days)
 
 ### Priority score for ordering DESIGN-DEBT.md entries
 
 Each debt item gets three scores:
 
 - **severity_weight**: `{ P0: 4, P1: 3, P2: 2, P3: 1 }`
-- **effort_weight**: `{ XS: 5, S: 4, M: 3, L: 2, XL: 1 }` — high effort = lower priority
+- **effort_weight**: `{ XS: 5, S: 4, M: 3, L: 2, XL: 1 }` - high effort = lower priority
 - **dependency_depth**: count of other debt items this fix unblocks
 
 Formula:
@@ -498,7 +498,7 @@ Ordering rules:
 
 Example: A P1 issue (`severity_weight = 3`) with S effort (`effort_weight = 4`) that unblocks 2 other items (`dependency_depth = 2`) scores: `(3 * 4) + (2 * 2) = 16`. A P0 issue (`4`) with XL effort (`1`) with no dependencies scores: `(4 * 1) + 0 = 4`. The P1 ranks above the P0 despite lower severity because its XL effort makes the P0 low ROI.
 
-Identify **quick wins**: P1 issues with XS/S effort — these have the best ROI.
+Identify **quick wins**: P1 issues with XS/S effort - these have the best ROI.
 Identify **blocking dependencies**: fixes that must happen before others (e.g., token layer before dark mode).
 
 ---
@@ -686,7 +686,7 @@ Given the scan results:
 
 ```
 Suggested first pipeline run:
-  /get-design-done:discover --auto
+  /get-design-done:discover `--auto`
     -> Will use DESIGN.md as baseline context
   /get-design-done:plan
     -> Scope: address all P0s + top 5 P1s

package/skills/settings/SKILL.md

@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 # gdd-settings
 
-Manages `.design/config.json` — the per-project config for model profile and parallelism. See `reference/config-schema.md` for the full schema. This skill also supports patching non-stage STATE.md frontmatter keys (`cycle`, `wave`, custom keys) via `mcp__gdd_state__frontmatter_update`. See **STATE.md frontmatter** below.
+Manages `.design/config.json` - the per-project config for model profile and parallelism. See `reference/config-schema.md` for the full schema. This skill also supports patching non-stage STATE.md frontmatter keys (`cycle`, `wave`, custom keys) via `mcp__gdd_state__frontmatter_update`. See **STATE.md frontmatter** below.
 
 ## Subcommands
 
@@ -48,7 +48,7 @@ Use `AskUserQuestion` to pick one or more cleanup actions, then confirm each bef
 Always:
 
 1. Read current `.design/config.json` (use defaults below if missing).
-2. Merge the single field being changed — never overwrite unrelated fields.
+2. Merge the single field being changed - never overwrite unrelated fields.
 3. Write back as pretty JSON (2-space indent, trailing newline).
 
 ## STATE.md frontmatter

package/skills/ship/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gdd-ship
-description: "Post-verify PR flow — creates a clean PR branch, invokes code review check, and prepares the PR for merge."
+description: "Post-verify PR flow - creates a clean PR branch, invokes code review check, and prepares the PR for merge."
 argument-hint: "[--title <PR title>] [--draft]"
 tools: Read, Write, Bash, AskUserQuestion, Task
 disable-model-invocation: true
@@ -26,18 +26,18 @@ Closes the verify → merge gap: runs `/gdd:pr-branch` for a clean branch, assem
 ## Do Not
 
 - Do not push to `main`/`master` directly.
-- Do not include `.design/` or `.planning/` files in the PR branch — that is `/gdd:pr-branch`'s job.
-- Do not skip the verify pre-flight silently — always surface a failure and ask.
+- Do not include `.design/` or `.planning/` files in the PR branch - that is `/gdd:pr-branch`'s job.
+- Do not skip the verify pre-flight silently - always surface a failure and ask.
 
-## Step 6.5 — PR inline review surface (pr-commenter)
+## Step 6.5 - PR inline review surface (pr-commenter)
 
-ONLY on the success path — after the PR has been created (Step 5) and its URL printed (Step 6) — spawn `agents/pr-commenter.md` via the `Task` tool to post GDD's verify/audit output **inline** on the new PR: inline review comments on changed lines, Preview/Chromatic before-after screenshot pairs, and the `gdd/design-review` check-run (audit pillar scores + verify pass/fail + a11y). Pass the PR number + `owner/repo` in the Task context.
+ONLY on the success path - after the PR has been created (Step 5) and its URL printed (Step 6) - spawn `agents/pr-commenter.md` via the `Task` tool to post GDD's verify/audit output **inline** on the new PR: inline review comments on changed lines, Preview/Chromatic before-after screenshot pairs, and the `gdd/design-review` check-run (audit pillar scores + verify pass/fail + a11y). Pass the PR number + `owner/repo` in the Task context.
 
 This is a **degrade-to-noop** surface and MUST NOT fail the ship: if `gh` is unavailable, the `GDD_DISABLE_PR_COMMENTER` kill-switch (env or `.design/config.json`) is set, or the agent errors, the ship still succeeds (pr-commenter prints the bodies for manual paste). Skip this step entirely if PR creation failed in Step 5. The posting contract (gh-api shapes, check-run payload, redaction, branch-protection setup) lives in `reference/pr-review-integration.md`.
 
-## Step 7 — Update notice (post-closeout surface)
+## Step 7 - Update notice (post-closeout surface)
 
-ONLY on the success path — after the PR has been created and the URL has been printed — emit the plugin-update banner. If PR creation failed earlier, skip this step (do not suggest upgrades in the middle of a PR-creation failure).
+ONLY on the success path - after the PR has been created and the URL has been printed - emit the plugin-update banner. If PR creation failed earlier, skip this step (do not suggest upgrades in the middle of a PR-creation failure).
 
 ```bash
 [ -f .design/update-available.md ] && cat .design/update-available.md

package/skills/sketch/SKILL.md

@@ -5,9 +5,9 @@ argument-hint: "[topic] [--variants N] [--quick]"
 tools: Read, Write, AskUserQuestion, Bash
 ---
 
-# Get Design Done — Sketch
+# Get Design Done - Sketch
 
-**Role:** Multi-variant HTML exploration. Answers "what could this look like?" by generating N standalone HTML variants from a topic prompt. Variants are browser-openable directly — no build step — and can be screenshot by Phase 8 Preview/Playwright tooling later.
+**Role:** Multi-variant HTML exploration. Answers "what could this look like?" by generating N standalone HTML variants from a topic prompt. Variants are browser-openable directly - no build step - and can be screenshot by Phase 8 Preview/Playwright tooling later.
 
 Unlike `/gdd:spike` (which tests feasibility), `/gdd:sketch` explores visual/directional variants.
 
@@ -18,7 +18,7 @@ Parse `$ARGUMENTS`:
 - `--variants N` → number of variants (default: 3)
 - `--quick` → skip intake, use DESIGN-CONTEXT.md tokens + sensible defaults
 
-## Step 1 — Intake (unless `--quick`)
+## Step 1 - Intake (unless `--quick`)
 
 AskUserQuestion, one at a time:
 1. "What are you sketching? (component, layout, page)"
@@ -27,12 +27,12 @@ AskUserQuestion, one at a time:
 
 If `--quick`: derive directions from topic + pull tokens from `.design/DESIGN-CONTEXT.md` if present, else defaults.
 
-## Step 2 — Create sketch directory
+## Step 2 - Create sketch directory
 
 - Derive `<slug>` from the topic (kebab-case).
 - `mkdir -p .design/sketches/<slug>/` via Bash.
 
-## Step 3 — Write INTAKE.md
+## Step 3 - Write INTAKE.md
 
 Write `.design/sketches/<slug>/INTAKE.md` with:
 - Topic
@@ -40,20 +40,20 @@ Write `.design/sketches/<slug>/INTAKE.md` with:
 - Token references (link to DESIGN-CONTEXT.md or inline list)
 - Timestamp
 
-## Step 4 — Generate N standalone HTML variants
+## Step 4 - Generate N standalone HTML variants
 
 For each of N variants (default 3), write `variant-<n>.html` as a **complete standalone HTML file**:
 - `<!DOCTYPE html>` + `<html>` + `<head>` + `<body>`
 - `<style>` block inline with CSS custom properties for tokens (`--color-*`, `--space-*`, `--font-*`)
 - Semantic HTML5 (`<header>`, `<main>`, `<nav>`, `<section>`, etc.)
-- No imports, no bundler, no JS framework — opens in a browser directly via `file://`
+- No imports, no bundler, no JS framework - opens in a browser directly via `file://`
 - Each variant explores a different direction from intake
 
-## Step 5 — Write README.md
+## Step 5 - Write README.md
 
 Write `.design/sketches/<slug>/README.md` with:
 - Topic + one-line summary
-- List of variants: `variant-1.html` — direction label — one-line description
+- List of variants: `variant-1.html` - direction label - one-line description
 - How to view: "Open each `variant-*.html` in a browser."
 - Next step: "Run `/gdd:sketch-wrap-up <slug>` when ready to pick a winner."
 
@@ -71,7 +71,7 @@ Next: /gdd:sketch-wrap-up <slug>
 
 ## Do Not
 
-- Do not write to `src/` — sketches live in `.design/sketches/` only.
+- Do not write to `src/` - sketches live in `.design/sketches/` only.
 - Do not use build-step syntax (JSX, TS, imports). Standalone HTML only.
 - Do not overwrite an existing sketch slug without asking.
 

package/skills/sketch-wrap-up/SKILL.md

@@ -5,25 +5,25 @@ argument-hint: "[slug]"
 tools: Read, Write, Glob, AskUserQuestion
 ---
 
-# Get Design Done — Sketch Wrap-Up
+# Get Design Done - Sketch Wrap-Up
 
-**Role:** Close an open sketch — elicit the winner + rationale from the user, group the decision by design area, and codify it as a project-local skill at `./.claude/skills/design-<area>-conventions.md` so future gdd sessions auto-load the decision. See `./reference/cycle-handoff-preamble.md` for the cycle-handoff framing this decision-archive feeds into.
+**Role:** Close an open sketch - elicit the winner + rationale from the user, group the decision by design area, and codify it as a project-local skill at `./.claude/skills/design-<area>-conventions.md` so future gdd sessions auto-load the decision. See `./reference/cycle-handoff-preamble.md` for the cycle-handoff framing this decision-archive feeds into.
 
-## Step 1 — Find sketches
+## Step 1 - Find sketches
 
 - Glob `.design/sketches/*/`.
 - If `[slug]` provided → use it directly.
 - If multiple pending (no `WINNER.md`) → AskUserQuestion: "Which sketch are you wrapping up?"
 - If none → print `No open sketches. Run /gdd:sketch first.` and exit.
 
-## Step 2 — Walk variants
+## Step 2 - Walk variants
 
 Read the sketch's `README.md`. For each `variant-N.html`:
 
 - Show the variant's one-line description from README.
 - AskUserQuestion: "Is variant-N a keeper, maybe, or rejected?"
 
-## Step 3 — Elicit winner rationale
+## Step 3 - Elicit winner rationale
 
 AskUserQuestion in sequence:
 
@@ -31,11 +31,11 @@ AskUserQuestion in sequence:
 2. "What makes variant-N the winning direction? (grounds the decision for future sessions)"
 3. "Any token implications? (e.g., spacing scale clamp, color adjustment, font-weight shift)"
 
-## Step 4 — Group by design area
+## Step 4 - Group by design area
 
 AskUserQuestion: "Which design area does this winner inform?" Options: `typography / color / layout / motion / component / interaction`.
 
-## Step 5 — Write project skill
+## Step 5 - Write project skill
 
 Append to `./.claude/skills/design-<area>-conventions.md` (create if missing):
 
@@ -50,20 +50,20 @@ Auto-loaded in gdd sessions. Captures decisions codified from `/gdd:sketch-wrap-
 **Token implications**: <implications, or "none">
 ```
 
-## Step 6 — Write WINNER.md
+## Step 6 - Write WINNER.md
 
 Write `.design/sketches/<slug>/WINNER.md` with: `# Winner: variant-N`, then bold-prefixed fields **Slug**, **Area**, **Rationale**, **Captured** (YYYY-MM-DD), **Project skill written to** (path from Step 5).
 
-## Step 7 — Append D-XX + `<prototyping>` outcome to STATE.md
+## Step 7 - Append D-XX + `<prototyping>` outcome to STATE.md
 
-Two coupled writes — both must succeed so the sketch resolution surfaces in both `<decisions>` (all downstream stages) and `<prototyping>` (planner-specific context via decision-injector). Compute `D-XX` as max existing `D-NN` + 1 (scan `<decisions>` for `D-\d+:`, zero-pad to 2 digits).
+Two coupled writes - both must succeed so the sketch resolution surfaces in both `<decisions>` (all downstream stages) and `<prototyping>` (planner-specific context via decision-injector). Compute `D-XX` as max existing `D-NN` + 1 (scan `<decisions>` for `D-\d+:`, zero-pad to 2 digits).
 
 - **Write 1 (`<decisions>`):** `D-XX: sketch/<slug> — winner: variant-N — <rationale> (locked)\n  Source: .design/sketches/<slug>/WINNER.md`
 - **Write 2 (`<prototyping>`):** `<sketch slug="<slug>" cycle="<cycle>" decision="D-XX" status="resolved"/>`. `<cycle>` from STATE.md frontmatter; empty string valid for single-cycle Wave A projects. If `<prototyping>` block does not exist, materialize between `<must_haves>` and `<connections>` per STATE template; append the `<sketch …/>` as first child.
 
 Prefer MCP `gdd_state` typed mutators (byte-identical output): `mcp__gdd_state__add_decision({id, text, status})` + `mcp__gdd_state__add_prototyping({type:"sketch", slug, cycle, decision, status})`. Without MCP, edit `.design/STATE.md` directly via Read + Write.
 
-## Step 8 — Update sketches SUMMARY.md
+## Step 8 - Update sketches SUMMARY.md
 
 Append to `.design/sketches/SUMMARY.md` (create if missing):
 
@@ -87,6 +87,6 @@ Project skill: ./.claude/skills/design-<area>-conventions.md
 ## Do Not
 
 - Do not modify other sketch variants or rejected directions.
-- Do not write to `src/` — conventions are design-layer only.
+- Do not write to `src/` - conventions are design-layer only.
 
 ## SKETCH-WRAP-UP COMPLETE

package/skills/skill-manifest/SKILL.md

@@ -14,7 +14,7 @@ tools: Bash, Read, Glob
 ls .design/intel/exports.json 2>/dev/null && echo "ready" || echo "missing"
 ```
 
-## Mode 1 — Intel store available
+## Mode 1 - Intel store available
 
 Read `.design/intel/exports.json`. Group entries by `kind` (skill vs agent). Print:
 
@@ -47,7 +47,7 @@ Total: <N> skills, <M> agents
 
 To get the description for each skill/agent: read `exports.json` entry and look up the matching file in `files.json`, then read its frontmatter `description` field from `exports.json` (if stored) or from the file directly.
 
-## Mode 2 — Intel store missing (fallback)
+## Mode 2 - Intel store missing (fallback)
 
 If `.design/intel/exports.json` is not present, fall back to directory scan:
 
@@ -68,9 +68,9 @@ AGENTS: design-advisor.md, design-auditor.md, ...
 
 ## Filter mode
 
-`/gdd:skill-manifest agents` — show agents only
-`/gdd:skill-manifest skills` — show skills only
-`/gdd:skill-manifest <keyword>` — filter by keyword in name or description
+`/gdd:skill-manifest agents` - show agents only
+`/gdd:skill-manifest skills` - show skills only
+`/gdd:skill-manifest <keyword>` - filter by keyword in name or description
 
 ## Required reading (conditional)
 

package/skills/spike/SKILL.md

@@ -5,9 +5,9 @@ argument-hint: "[hypothesis] [--timebox <minutes>]"
 tools: Read, Write, Bash, AskUserQuestion
 ---
 
-# Get Design Done — Spike
+# Get Design Done - Spike
 
-**Role:** Timeboxed feasibility experiment. Answers "can this work?" — e.g., "can we use view transitions for this flow?", "does this animation perform on mobile?". Unlike `/gdd:sketch` (visual variants), `/gdd:spike` tests a hypothesis.
+**Role:** Timeboxed feasibility experiment. Answers "can this work?" - e.g., "can we use view transitions for this flow?", "does this animation perform on mobile?". Unlike `/gdd:sketch` (visual variants), `/gdd:spike` tests a hypothesis.
 
 ## Flag parsing
 
@@ -15,7 +15,7 @@ Parse `$ARGUMENTS`:
 - `[hypothesis]` → summary phrase, derives the slug
 - `--timebox <minutes>` → default 60
 
-## Step 1 — Intake
+## Step 1 - Intake
 
 AskUserQuestion:
 1. "What's the hypothesis? (e.g., 'view transitions can replace our current route animations')"
@@ -23,12 +23,12 @@ AskUserQuestion:
 3. "What would prove it works? (success criteria)"
 4. "What would prove it doesn't? (failure criteria)"
 
-## Step 2 — Create spike directory
+## Step 2 - Create spike directory
 
 - Derive `<slug>` from the hypothesis (kebab-case, short).
 - `mkdir -p .design/spikes/<slug>/scratch/` via Bash.
 
-## Step 3 — Write HYPOTHESIS.md
+## Step 3 - Write HYPOTHESIS.md
 
 Write `.design/spikes/<slug>/HYPOTHESIS.md`:
 ```markdown
@@ -48,7 +48,7 @@ Write `.design/spikes/<slug>/HYPOTHESIS.md`:
 Experimental code in `./scratch/` — not committed to src/.
 ```
 
-## Step 4 — Announce
+## Step 4 - Announce
 
 ```
 ━━━ Spike started ━━━
@@ -61,7 +61,7 @@ When done: /gdd:spike-wrap-up <slug>
 
 ## Do Not
 
-- Do not write experimental code to `src/` — use `.design/spikes/<slug>/scratch/`.
+- Do not write experimental code to `src/` - use `.design/spikes/<slug>/scratch/`.
 - Do not exceed the timebox without explicit user approval; wrap up and reassess first.
 
 ## SPIKE COMPLETE

package/skills/spike-wrap-up/SKILL.md

@@ -1,26 +1,26 @@
 ---
 name: gdd-spike-wrap-up
-description: "Close a spike — capture findings, write decision to STATE.md, update SUMMARY.md."
+description: "Close a spike - capture findings, write decision to STATE.md, update SUMMARY.md."
 argument-hint: "[slug]"
 tools: Read, Write, Glob, AskUserQuestion
 ---
 
-# Get Design Done — Spike Wrap-Up
+# Get Design Done - Spike Wrap-Up
 
-**Role:** Close an open spike — capture the verdict, write findings, record a D-XX decision in STATE.md so `plan` sees it when creating tasks. See `./reference/cycle-handoff-preamble.md` for the cycle-handoff framing this archive feeds into.
+**Role:** Close an open spike - capture the verdict, write findings, record a D-XX decision in STATE.md so `plan` sees it when creating tasks. See `./reference/cycle-handoff-preamble.md` for the cycle-handoff framing this archive feeds into.
 
-## Step 1 — Find spike
+## Step 1 - Find spike
 
 - Glob `.design/spikes/*/`.
 - If `[slug]` provided → use it directly.
 - If multiple pending (no `FINDINGS.md`) → AskUserQuestion: "Which spike are you wrapping up?"
 - If none → print `No open spikes. Run /gdd:spike first.` and exit.
 
-## Step 2 — Re-surface hypothesis
+## Step 2 - Re-surface hypothesis
 
 Read `.design/spikes/<slug>/HYPOTHESIS.md`. Show the hypothesis + success/failure criteria to the user.
 
-## Step 3 — Elicit findings
+## Step 3 - Elicit findings
 
 AskUserQuestion in sequence:
 
@@ -28,7 +28,7 @@ AskUserQuestion in sequence:
 2. "What was learned? (1–3 sentences)"
 3. "Recommendation? (adopt / reject / needs more investigation)"
 
-## Step 4 — Write FINDINGS.md
+## Step 4 - Write FINDINGS.md
 
 Write `.design/spikes/<slug>/FINDINGS.md`:
 
@@ -46,19 +46,19 @@ Write `.design/spikes/<slug>/FINDINGS.md`:
 <1–2 bullets>
 ```
 
-## Step 5 — Record decision in STATE.md
+## Step 5 - Record decision in STATE.md
 
 Append under `<decisions>`: `D-XX: spike/<slug> — <verdict> — <recommendation>\n  Rationale: <one line>\n  Source: .design/spikes/<slug>/FINDINGS.md`. Compute `D-XX` as max existing `D-NN` + 1 (scan for `D-\d+:`, zero-pad to 2 digits). Prefer MCP `gdd_state` typed mutator when available: `mcp__gdd_state__add_decision({id, text, status:"locked"})`.
 
-## Step 6 — Append `<prototyping>` outcome to STATE.md
+## Step 6 - Append `<prototyping>` outcome to STATE.md
 
-Coupled with Step 5 — both must succeed so the spike resolution surfaces in `<decisions>` (downstream stages) and `<prototyping>` (planner via decision-injector). Use **same `D-XX`**. Append under `<prototyping>`: `<spike slug="<slug>" cycle="<cycle>" decision="D-XX" verdict="yes|no|partial" status="resolved"/>`. `<cycle>` from STATE.md frontmatter (`cycle:` field; empty string valid for single-cycle Wave A); `verdict` from Step 3.
+Coupled with Step 5 - both must succeed so the spike resolution surfaces in `<decisions>` (downstream stages) and `<prototyping>` (planner via decision-injector). Use **same `D-XX`**. Append under `<prototyping>`: `<spike slug="<slug>" cycle="<cycle>" decision="D-XX" verdict="yes|no|partial" status="resolved"/>`. `<cycle>` from STATE.md frontmatter (`cycle:` field; empty string valid for single-cycle Wave A); `verdict` from Step 3.
 
 If `<prototyping>` block does not exist, materialize between `<must_haves>` and `<connections>` per STATE template; append `<spike …/>` as first child.
 
 Prefer MCP typed mutator (byte-identical output): `mcp__gdd_state__add_prototyping({type:"spike", slug, cycle, decision:"D-XX", verdict, status:"resolved"})`. Without MCP, edit `.design/STATE.md` directly via Read + Write.
 
-## Step 7 — Update spikes SUMMARY.md
+## Step 7 - Update spikes SUMMARY.md
 
 Append to `.design/spikes/SUMMARY.md` (create if missing):
 
@@ -80,7 +80,7 @@ FINDINGS.md written.
 
 ## Do Not
 
-- Do not delete the `scratch/` directory — it's a record of what was tried.
-- Do not promote scratch code to `src/` automatically — require a follow-up plan task.
+- Do not delete the `scratch/` directory - it's a record of what was tried.
+- Do not promote scratch code to `src/` automatically - require a follow-up plan task.
 
 ## SPIKE-WRAP-UP COMPLETE