@hegemonart/get-design-done 1.57.2 → 1.58.0

package/dist/claude-code/.claude/skills/graphify/SKILL.md

@@ -1,49 +0,0 @@
----
-name: gdd-graphify
-description: "Manage the Graphify knowledge graph for the current project. Build, query, status, diff. When available, design-planner and design-integration-checker use the graph for pre-search consultation."
----
-
-# gdd-graphify
-
-Thin command wrapper around the GSD graphify tools integration.
-
-## Usage
-
-```
-/get-design-done graphify build          # Build or rebuild the knowledge graph
-/get-design-done graphify query <term>   # Query graph for a node and neighbors
-/get-design-done graphify status         # Check graph age, enabled, node count
-/get-design-done graphify diff           # Show topology changes since last build
-```
-
-## Behavior
-
-1. Read `.design/STATE.md` to check `graphify` status in `<connections>`.
-2. Check `graphify.enabled` in `.design/config.json` via a direct file read (per D-09 - no `config-get` CLI subcommand):
-   ```
-   node -e "try{const c=JSON.parse(require('fs').readFileSync('.design/config.json','utf8'));process.stdout.write(String(c.graphify?.enabled===true))}catch{process.stdout.write('false')}"
-   ```
-3. If not enabled, print:
-   ```
-   "Graphify is not enabled. Edit `.design/config.json` to set `graphify.enabled: true`."
-   "Then run /gdd:graphify build to generate the knowledge graph."
-   ```
-   STOP.
-4. Execute the requested subcommand via the native CLI:
-   - build:  `node bin/gdd-graph build`
-   - query:  `node bin/gdd-graph query "<term>" --budget 2000`
-   - status: `node bin/gdd-graph status`
-   - diff:   `node bin/gdd-graph diff`
-5. After `build` completes, update `.design/STATE.md` `<connections>`: `graphify: available`
-
-## Required Reading
-
-- `.design/STATE.md` - for graphify status in `<connections>`
-- `.design/config.json` - for `graphify.enabled` flag
-
-## Notes
-
-- Graphify is optional. The native CLI ships in this repo at `bin/gdd-graph` (no external install - Node only).
-- Graph is stored at `.design/graph/graph.json` (Ajv-validated against `scripts/lib/graph/schema.json`).
-- Graph covers source code (`src/`, `components/`). It does NOT index `.design/` artifacts by default.
-- Use `query` with node IDs from the graph schema: `component:<name>`, `token:color/<name>`, `decision:D-<nn>`, etc.

package/dist/claude-code/.claude/skills/health/SKILL.md

@@ -1,99 +0,0 @@
----
-name: gdd-health
-description: "Reports .design/ artifact health - staleness, missing files, token drift, broken state transitions. Activates for requests involving checking .design artifact health, staleness, token drift, or broken state transitions."
-tools: Read, Bash, Glob, Grep, mcp__gdd_state__get
-disable-model-invocation: true
----
-
-# /gdd:health
-
-**Role:** Report the health of the `.design/` directory. Print a score and list the checks that failed.
-
-## Checks
-
-1. **Artifact inventory** - `ls -la .design/*.md` with size and mtime. Print a table.
-2. **Missing expected artifacts** - by `stage` field from the `mcp__gdd_state__get` snapshot:
-   - `brief` expects BRIEF.md
-   - `explore` expects DESIGN.md, DESIGN-DEBT.md, DESIGN-CONTEXT.md
-   - `plan` expects DESIGN-PLAN.md
-   - `design` expects DESIGN-SUMMARY.md
-   - `verify` expects DESIGN-VERIFICATION.md
-   FAIL per missing.
-3. **Token drift** - `wc -c .design/DESIGN.md .design/DESIGN-CONTEXT.md`; approx tokens = bytes/4. WARN if combined >40000.
-4. **Aged DESIGN-DEBT** - items in `.design/DESIGN-DEBT.md` not touched in >14 days (file mtime). WARN.
-5. **Broken state transitions** - `stage` field from the snapshot inconsistent with artifacts present (e.g. stage=`verify` but DESIGN-SUMMARY.md missing). FAIL.
-6. **Pending sketch/spike wrap-ups** - any `.design/sketches/*` or `.design/spikes/*` directory lacking a SUMMARY.md. WARN.
-7. **Seed germination** - scan `.design/SEEDS.md` (if present) for seeds whose trigger keywords match the snapshot or CYCLES.md content. List as "Seed ready: <text>".
-
-## State snapshot
-
-Call `mcp__gdd_state__get` once at the start to pull the snapshot used by checks 2, 5, and 7. Aggregate health math stays prose-level:
-- Count available connections from `<connections>`.
-- Count open blockers from `<blockers>` where `resolved` is absent.
-- Count pending must-haves from `<must_haves>` where `status: "pending"`.
-
-## Output
-
-```
-━━━ Design health ━━━
-Artifacts:
-  BRIEF.md           2.1 KB   2026-04-14
-  DESIGN.md          18.4 KB  2026-04-17
-  DESIGN-CONTEXT.md  7.2 KB   2026-04-17
-
-Checks:
-  [PASS] Missing artifacts
-  [WARN] Token drift (42,100)
-  [PASS] Aged DESIGN-DEBT
-  [PASS] State transitions
-  [PASS] Sketch/spike wrap-ups
-  [PASS] Seed germination
-
-Health: 5 / 6 checks passing.
-━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Figma-extract readiness (figma_extract)
-
-After the health table, the `gdd_health` MCP surface (`scripts/lib/health-mirror/index.cjs`) reports a `figma_extract` check so a user knows whether figma-extract is usable. The detail is one of three exact strings:
-
-- `figma extract: ready (token set)` - `FIGMA_TOKEN` (or `FIGMA_PERSONAL_ACCESS_TOKEN`) is present (status `ok`).
-- `figma extract: token missing` - no token env is set (status `warn`).
-- `figma extract: plugin sync needed for variables (Free tier detected)` - token present but a prior pull recorded a 403/skip on the Variables REST path, so run the plugin-sync step (status `warn`).
-
-Token PRESENCE only is detected (D-10) - the token value is never read, logged, or shown. The Free-tier signal is read from the local raw-pull cache only; no network call is made.
-
-## Skill-discipline bootstrap (skill_discipline)
-
-The `gdd_health` MCP surface also reports a `skill_discipline` check (Phase 32) confirming the using-gdd SessionStart bootstrap is live - detail is one of three exact strings:
-- `skill-discipline: ready` - `skills/using-gdd/SKILL.md` exists AND `hooks/hooks.json` SessionStart wires `inject-using-gdd.sh` (status `ok`).
-- `skill-discipline: missing using-gdd` (skill absent) or `skill-discipline: hook not wired` (skill present, no SessionStart inject) - both `warn`. The MCP surface also reports a `harness_freshness` check (Phase 44): per-harness `last_verified` age, status-aware (only `tested` harnesses warn at 60d / fail at 180d; others `n/a`). Full taxonomy in `HARNESSES.md`; refresh with `npm run verify:harness <id>`.
-
-## Check MCP registration (gdd-mcp)
-
-After the health table, inspect whether `gdd-mcp` (Phase 27.7+) is registered with any installed harness and render a one-line status row. Dismissable via `.design/config.json#mcp_nudge=false`. Non-blocking: failure paths render `MCP server: unknown` rather than crash. Full detection procedure (dismissal check, detection via `scripts/lib/install/mcp-register.cjs`, row rendering for claude/codex/both/neither, fallback) lives in `./health-mcp-detection.md`.
-
-## Update notice (safe-window surface)
-
-After the health table, emit the plugin-update banner if one is present:
-
-```bash
-[ -f .design/update-available.md ] && cat .design/update-available.md
-```
-
-Written by `hooks/update-check.sh`; suppressed mid-pipeline and when the latest release is dismissed.
-
-## Skill-length report
-
-After the health table, surface the Phase 28.5 skill-authoring contract drift signal by running `node scripts/validate-skill-length.cjs --quiet --json` and reading `summary` from stdout. Print two prose lines:
-
-- `Skill-length: <total> total | <clean> clean | <warnings> warn (>=100) | <blockers> block (>=250)`
-- If blockers > 0: list each blocker as a row `- <name> (<lines> lines)`. Else: print `All skills within contract.`
-
-Thresholds: warn >=100, block >=250 (D-01). Strict description-format off by default (D-02). Then add two compact Phase 50 lines from `scripts/lib/manifest/skills.json`: `Skills: <n>/<total> in v3 description form` (descriptions matching `/Activates for requests involving/i`) and `Composition: <edges> edges | <cycles> cycles` (`composes_with`/`next_skills` fan-out; cycles via `scripts/validate-composition-graph.cjs` when present, else `0`). See `./health-skill-length-report.md` for the JSON shape and threshold rationale.
-
-## Do Not
-
-- Do not mutate STATE.md - this skill is read-only. Only `mcp__gdd_state__get` is permitted.
-
-## HEALTH COMPLETE

package/dist/claude-code/.claude/skills/health/health-mcp-detection.md

@@ -1,44 +0,0 @@
----
-name: health-mcp-detection
-type: heuristic
-version: 1.0.0
-phase: 28.5
-tags: [health, mcp, detection, gdd-mcp, registration-nudge]
-last_updated: 2026-05-18
----
-
-# Health MCP-Registration Detection Procedure
-
-Extracted from `skills/health/SKILL.md` per Phase 28.5 D-10 (extract-then-link, never delete content).
-This file documents the canonical procedure for inspecting whether `gdd-mcp` (Phase 27.7+) is
-registered with any installed harness and rendering a one-line status row after the health
-table. The procedure is non-blocking by design: any failure path renders `unknown` rather
-than crashing the skill.
-
-## Dismissal check
-
-1. Read `.design/config.json` (if present). Parse JSON inside a try/catch.
-2. If `config.mcp_nudge === false`, SKIP this step entirely (render nothing).
-3. On parse failure: default to `mcp_nudge=true` (show the row) - fail-safe per threat T-27.7-04-05.
-
-## Detection
-
-1. Read `.claude/settings.local.json` (or equivalent harness settings file) and inspect its `mcpServers` object - alternatively run `claude mcp list` / `codex mcp list` if a CLI is available (see fallback below).
-2. Preferred invocation via the install-lib: call `detectMcpRegistration()` from `scripts/lib/install/mcp-register.cjs`. Returns `{harnesses: [{harness, present, registered}], summary}`.
-
-## Row rendering
-
-Based on the detection result, render exactly ONE of these row strings:
-
-- When `claude` and `codex` both present + both registered:
-  `MCP server: registered with claude+codex`
-- When only one harness is present and registered:
-  `MCP server: registered with claude` (or `MCP server: registered with codex`)
-- When at least one harness is present but `gdd-mcp` is NOT in its registered list:
-  `MCP server: not registered  (run: npx @hegemonart/get-design-done --register-mcp; dismiss: .design/config.json#mcp_nudge=false)`
-- When neither harness CLI is found on PATH:
-  `MCP server: unknown (claude/codex CLI not found)`
-
-## Fallback (if `mcp-register.cjs` not yet shipped)
-
-Skip this step silently with status `MCP server: unknown`. This step is non-blocking - failures here MUST NOT crash the SKILL.

package/dist/claude-code/.claude/skills/health/health-skill-length-report.md

@@ -1,69 +0,0 @@
-# Health skill - skill-length report subsection
-
-Phase 28.5-11 / D-11 reference. Read by `skills/health/SKILL.md` to render the
-"Skill-length report" subsection after the standard health checks.
-
-## JSON shape (from `validate-skill-length.cjs --quiet --json`)
-
-```jsonc
-{
-  "summary": {
-    "total":    70,   // number of SKILL.md files under skills/
-    "clean":    70,   // skills with 0 errors and 0 warnings
-    "warnings": 0,    // skills with >=100 lines but <250 (D-01 warn band)
-    "blockers": 0     // skills with any block-level error (>=250 lines,
-                      //   missing frontmatter field, description out of
-                      //   range, disable-model-invocation non-whitelisted)
-  },
-  "skills": [
-    {
-      "name": "...",           // skill folder name (matches skills/<name>/SKILL.md)
-      "path": "...",           // absolute path to the file on disk
-      "lines": 0,              // wc -l semantics
-      "descriptionLength": 0,  // length of frontmatter.description string
-      "hasRequiredFields": true,
-      "level": "clean",        // "clean" | "warn" | "block"
-      "errors": [{ "code": "...", "message": "..." }],
-      "warnings": [{ "code": "...", "message": "..." }],
-      "reasons": ["..."]       // human-readable summary lines
-    }
-  ]
-}
-```
-
-## Render contract
-
-The health skill prints two lines after the existing checks table:
-
-```
-Skill-length: <total> total | <clean> clean | <warnings> warn (>=100) | <blockers> block (>=250)
-  All skills within contract.
-```
-
-If `summary.blockers > 0`, replace the second line with one indented row per
-blocker entry (skills where `level === "block"`):
-
-```
-Skill-length: 70 total | 67 clean | 2 warn (>=100) | 1 block (>=250)
-  - <name> (<lines> lines)
-```
-
-## Thresholds (D-01)
-
-- `warn >=100` - skill flagged as advisory; CI emits `::warning::` annotation
-  but does not fail the build.
-- `block >=250` - skill flagged as blocker; CI emits `::error::` and fails
-  the build via exit code 2.
-
-## Strict description-format (D-02)
-
-`STRICT_DESCRIPTION=1` / `--strict-description` is OFF by default. Phase 33
-will graduate the strict `<what>. Use when <triggers>.` regex from advisory
-to hard-block based on A/B evidence at
-`.design/research/description-format-ab.md`.
-
-## Cross-link from health
-
-- `skills/health/SKILL.md` - emits the report after the main checks table.
-- `scripts/validate-skill-length.cjs` - provides the JSON.
-- `tests/phase-28.5-baseline.test.cjs` - locks the post-rework distribution.

package/dist/claude-code/.claude/skills/help/SKILL.md

@@ -1,87 +0,0 @@
----
-name: gdd-help
-description: "Lists all available get-design-done commands with one-line descriptions"
-tools: Read
-disable-model-invocation: true
----
-
-# Get Design Done - Help
-
-**Role:** Print a formatted reference of all `/gdd:` commands, grouped by purpose.
-
----
-
-## Output
-
-Print the following table:
-
-```
-━━━ Get Design Done — Command Reference ━━━
-
-Pipeline stages (run in order):
-  brief              Stage 1 — capture problem statement, audience, constraints → BRIEF.md
-  explore            Stage 2 — inventory scan + design context interview → DESIGN.md, DESIGN-DEBT.md, DESIGN-CONTEXT.md
-  plan               Stage 3 — decompose into executable tasks → DESIGN-PLAN.md
-  design             Stage 4 — execute tasks with wave coordination → DESIGN-SUMMARY.md
-  verify             Stage 5 — audit, verify, score → DESIGN-VERIFICATION.md
-
-Standalone analysis:
-  style [Component]  Generate component handoff doc → DESIGN-STYLE-[Name].md
-  darkmode           Audit dark mode architecture + contrast → DARKMODE-AUDIT.md
-  compare            Delta between baseline and verification → COMPARE-REPORT.md
-
-Ergonomics:
-  next               Route to the next pipeline stage based on STATE.md
-  help               This reference
-  progress           Show current pipeline state
-  health             Health check of .design/ artifacts
-  quick              Fast pass through the whole pipeline
-  fast               Aggressive speed mode
-
-Exploration:
-  discuss            Open discussion thread with design-discussant agent
-  list-assumptions   Print active D-XX decisions from STATE.md
-  sketch             Open a design sketch scratchpad
-  sketch-wrap-up     Close sketch and merge learnings
-  spike              Time-boxed exploratory spike
-  spike-wrap-up      Close spike and capture outcomes
-  map                Map the codebase structure
-  audit              Run audit-only pass
-
-Maintenance:
-  note               Record a quick note to STATE.md
-  plant-seed         Record an idea for later
-  add-backlog        Append item to backlog
-  review-backlog     Review pending backlog
-  todo               List/manage design TODOs
-  stats              Print pipeline stats
-  settings           View/edit plugin settings
-  update             Update the plugin
-  reapply-patches    Reapply any pending patches
-  debug              Enter systematic debugging mode
-  undo               Revert the last stage action
-
-Lifecycle:
-  new-project        Initialize STATE.md + .design/ directory
-  new-cycle          Start a new design cycle on an existing project
-  complete-cycle     Archive the current cycle
-  pause              Pause work and save context
-  resume             Resume paused work
-  do                 Execute a specific task
-  ship               Create PR from completed work
-  pr-branch          Create/switch PR branch
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Update notice (safe-window surface)
-
-After the command reference, emit the plugin-update banner if one is present:
-
-```bash
-[ -f .design/update-available.md ] && cat .design/update-available.md
-```
-
-Written by `hooks/update-check.sh`; suppressed mid-pipeline and when the latest release is dismissed.
-
-## HELP COMPLETE

package/dist/claude-code/.claude/skills/instinct/SKILL.md

@@ -1,111 +0,0 @@
----
-name: gdd-instinct
-description: "Inspects and manages atomic instinct learning units - small, scoped, confidence-weighted patterns the pipeline accumulates across cycles. Lists the project and global instinct stores, searches them by keyword, and promotes a vetted project instinct to the global store once it has cleared the cross-project gate. Use when the user wants to see what instincts exist, find an instinct by topic, or promote one to global scope. Activates for requests involving instincts, learned patterns, instinct promotion, instinct search, or the instinct store."
-argument-hint: "[list | query <keyword> | promote <id>] [--scope project|global] [--domain <d>]"
-tools: Read, Bash
-user-invocable: true
----
-
-# /gdd:instinct
-
-**Role:** Front end for the atomic instinct store. An instinct is a single learned pattern with a trigger, a confidence between 0.3 and 0.9, a domain, and a scope. This skill lists, searches, and promotes instincts. It never edits stored units by hand and never invents new ones - the reflector and `/gdd:extract-learnings` author them.
-
-The store engine ships at `scripts/lib/instinct-store.cjs` (authored elsewhere - this skill only calls it). Unit shape (YAML frontmatter plus a short body) is specified in `reference/instinct-format.md`. The project store lives at `.design/instincts/instincts.json`; the global store at `~/.claude/gdd/global-instincts.json`.
-
-Invoke the engine with `node`, the same way other skills call a `scripts/lib` helper:
-
-```bash
-node "${CLAUDE_PLUGIN_ROOT}/scripts/lib/instinct-store.cjs" <subcommand> [args]
-```
-
-If the engine exposes only a module API rather than a CLI, drive it from a short `node -e` script:
-
-```bash
-node -e "const s=require('${CLAUDE_PLUGIN_ROOT}/scripts/lib/instinct-store.cjs'); console.log(JSON.stringify(s.list({scope:process.env.SCOPE})))"
-```
-
-## Invocation Modes
-
-| Command | Behavior |
-|---|---|
-| `/gdd:instinct list` | Compact table of stored instincts (default mode). |
-| `/gdd:instinct query "<keyword>"` | Search instincts by keyword; show the top matches. |
-| `/gdd:instinct promote <id>` | Promote one project instinct to the global store (gated). |
-
-Flags apply across modes:
-
-- `--scope project|global` selects which store to read. Default is `project`.
-- `--domain <d>` filters to one domain (the domain enum is defined in `reference/instinct-format.md`).
-
-## list
-
-Read the requested store and print a compact table. Call `instinct-store.list({ scope, domain, baseDir })`:
-
-```bash
-node -e "const s=require('${CLAUDE_PLUGIN_ROOT}/scripts/lib/instinct-store.cjs'); \
-  const rows=s.list({ scope: process.env.SCOPE || 'project', domain: process.env.DOMAIN || undefined }); \
-  console.log(JSON.stringify(rows));"
-```
-
-Render one row per instinct. Keep it scannable:
-
-```
-ID        DOMAIN     CONF   CYCLES  TRIGGER
-in-7f3a   tokens     0.72   3       palette has no neutral ramp
-in-91bc   layout     0.55   2       cards overflow on the 320px breakpoint
-```
-
-- `CONF` is the stored confidence (0.3 to 0.9).
-- `CYCLES` is `cycles_seen`.
-- Truncate `TRIGGER` to keep each line on one row.
-
-If the store is empty, print: `No instincts in the <scope> store yet. Run /gdd:reflect or /gdd:extract-learnings to accumulate some.`
-
-## query
-
-Search by keyword and show the closest matches. Call `instinct-store.query(keyword, { scope, baseDir, limit })`. The engine uses an FTS5 index when one is present and falls back to a plain scan otherwise; either path returns the same row shape.
-
-```bash
-node -e "const s=require('${CLAUDE_PLUGIN_ROOT}/scripts/lib/instinct-store.cjs'); \
-  const hits=s.query(process.env.KW, { scope: process.env.SCOPE || 'project', limit: 10 }); \
-  console.log(JSON.stringify(hits));"
-```
-
-Print the top matches in the same table shape as `list`, ordered by the engine's relevance ranking. If there are no matches, say so plainly and suggest a broader keyword. Quote multi-word keywords so the shell passes one argument.
-
-## promote
-
-Promote a single project instinct into the global store so it applies across every project. Promotion is **gated**: `instinct-store.promote(id, { baseDir })` only succeeds when the instinct has been seen across at least K cycles (K=2) spanning at least M distinct project ids (M=2). The engine enforces the gate; this skill surfaces the outcome and asks the user to confirm before the write.
-
-Confirm first. Prefer `@clack/prompts`, and fall back to `AskUserQuestion` when it is absent (mirror the probe in `/gdd:new-skill`):
-
-```bash
-node -e "try { require.resolve('@clack/prompts'); console.log('clack'); } catch { console.log('fallback'); }"
-```
-
-- `clack`: drive `clack.confirm({ message: 'Promote <id> to the global store?' })` from a short Node script.
-- `fallback`: ask the same yes or no question with `AskUserQuestion`.
-
-On a confirmed yes, run the promotion:
-
-```bash
-node -e "const s=require('${CLAUDE_PLUGIN_ROOT}/scripts/lib/instinct-store.cjs'); \
-  console.log(JSON.stringify(s.promote(process.env.ID, {})));"
-```
-
-Branch on the engine result:
-
-- Promotion succeeded: print `Promoted <id> to the global store.` and show the new global row.
-- Gate not met: the engine reports how far the instinct is from the K=2 / M=2 bar. Print that plainly, for example `<id> needs 2 cycles across 2 projects; seen 1 cycle in 1 project so far. Not promoted.` Do not retry and do not force the write.
-- Unknown id: print `No instinct <id> in the project store.` and suggest `/gdd:instinct list`.
-
-If the user answers no at the confirm step, print `Promotion cancelled.` and exit without writing.
-
-## Do Not
-
-- Do not edit `.design/instincts/instincts.json` or the global store by hand. All writes go through `scripts/lib/instinct-store.cjs`.
-- Do not author new instincts here. The reflector and `/gdd:extract-learnings` emit units; this skill reads and promotes them.
-- Do not bypass the promotion gate. If the K=2 / M=2 bar is not met, report it and stop.
-- Do not modify `reference/instinct-format.md` or the store engine.
-
-## INSTINCT COMPLETE

package/dist/claude-code/.claude/skills/list-assumptions/SKILL.md

@@ -1,61 +0,0 @@
----
-name: gdd-list-assumptions
-description: "Surfaces hidden design assumptions baked into the codebase before planning - pattern-based detection plus user-surfaced items."
-argument-hint: "[--area typography|color|layout|motion|a11y]"
-tools: Read, Grep, Glob
-disable-model-invocation: true
----
-
-# /gdd:list-assumptions
-
-**Role:** Surface implicit design assumptions that were never explicitly decided. Output a numbered list tagging each as `[EXPLICIT]` (found in STATE.md/DESIGN-CONTEXT.md decisions) or `[IMPLICIT]` (inferred from code patterns).
-
-## Step 1 - Read explicit decisions
-
-Read `.design/STATE.md` `<decisions>` and `.design/DESIGN-CONTEXT.md` (if present). Collect every D-XX as `[EXPLICIT]` entries keyed by category.
-
-## Step 2 - Scan codebase for implicit patterns
-
-If `--area <name>` is given, restrict to that area. Otherwise scan all.
-
-**Layout**
-- Grep for `@media` queries → "Is mobile-first or desktop-first assumed?"
-- Grep for `grid-template`, `flex-direction` → "Is F-pattern or Z-pattern layout assumed?"
-
-**Typography**
-- Grep for `font-family` declarations → "Does the chosen font stack assume brand acceptance?"
-- Grep for `font-size: [0-9]+px` with varying values → "Is a modular scale assumed or ad-hoc sizing?"
-
-**Color**
-- Grep for hex literals `#[0-9a-fA-F]{3,8}` → "Is the palette assumed to be fixed without a token layer?"
-
-**Motion**
-- Grep for `@keyframes`, `transition`, `animate` → "Does the brand tolerate animation?"
-- Grep for `prefers-reduced-motion` → "Is reduced-motion honored or assumed ignored?"
-
-**A11y**
-- Grep for `aria-`, `role=`, `alt=` coverage → "Is WCAG AA the target, or AAA?"
-- Grep for `outline: none`, `outline: 0` → "Are focus rings intentionally removed?"
-
-For each hit, emit `Detected assumption: [pattern] at [file:line]` and flag as `[IMPLICIT]`.
-
-## Step 3 - Output
-
-```
-━━━ Design assumptions ━━━
-
-Typography
-  01 [EXPLICIT] D-03: Font family Inter
-  02 [IMPLICIT] 18 px font-size values found — scale not explicit (src/Card.css:12, ...)
-
-Color
-  03 [IMPLICIT] 47 hex literals — no token layer (see /gdd:discuss color)
-
-...
-
-N assumptions total — M implicit.
-Next: /gdd:discuss --all to resolve implicit ones.
-━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## LIST-ASSUMPTIONS COMPLETE

package/dist/claude-code/.claude/skills/list-pins/SKILL.md

@@ -1,27 +0,0 @@
----
-name: gdd-list-pins
-description: "Lists pinned skill aliases per harness with their source skill and pin timestamp. Use when you want to see which gdd skills have been pinned as standalone shortcuts and where."
-tools: Read, Bash
----
-
-# /gdd:list-pins
-
-**Role:** Show every pinned skill alias across the installed harness `skills/` directories. For each one, report the harness it lives in, the on-disk alias directory name, the source skill it points at (from the `<!-- gdd-pinned-skill source=<skill> -->` marker), and when it was pinned (the file modification time).
-
-## Steps
-
-1. **Run the list CLI.** Invoke the shipped script (it takes no arguments). The plugin root resolves via `CLAUDE_PLUGIN_ROOT` (falling back to the current directory when that variable is absent):
-
-    ```bash
-    node "${CLAUDE_PLUGIN_ROOT:-$(pwd)}/scripts/lib/pin/cli.cjs" list
-    ```
-
-    The CLI scans each harness `skills/` directory under the current project, finds the stubs carrying the gdd pin marker, and prints one line per pinned alias in the form `[<config-dir>] <alias> -> source=<skill> (pinned <timestamp>)`.
-
-2. **Report the result.** Relay the CLI output verbatim. Exit codes: 0 means one or more pinned aliases were found, 1 means none were found (nothing has been pinned yet), 2 means an error.
-
-## Do Not
-
-- Do not scan the harness directories by hand. The CLI already enforces the marker check, so only genuine gdd pins are listed.
-
-## LIST-PINS COMPLETE

package/dist/claude-code/.claude/skills/live/SKILL.md

@@ -1,98 +0,0 @@
----
-name: gdd-live
-description: "Live in-browser design mode. The user picks a DOM element on a running dev server (via the Claude Preview MCP), the agent generates N design variants in one batch, they hot-swap in place through HMR or preview_eval using a data-gdd-variant marker, the user accepts or discards, and the whole pick-generate-accept loop persists to .design/live-sessions so it survives a crash or resume. Use when the user wants to iterate on the look of a live component against a real running server, asks to try variants on a page, or runs the live command with a url; falls back to a screenshot-only degraded mode on harnesses without MCP support. Activates for requests involving in-browser design iteration, picking an element on a dev server, or generating variants with hot-swap."
-argument-hint: "[--variants N] [--resume <session-id>] [url]"
-tools: Read, Write, Edit, Bash, Glob, Grep, Task
-user-invocable: true
----
-
-# gdd-live - Live In-Browser Design Mode
-
-Pick a DOM element on a running dev server, generate competing design variants, hot-swap them in place, and accept the winner as a real source edit. Every step persists to `.design/live-sessions/<id>.json` so the session survives a crash or a later resume.
-
-The browser-side runtime, the harness-mode gate, the session store, the events feed, the post-check, the scope guard, and the bandit feed are all separate modules under `scripts/lib/live/`. This skill describes the loop and names the module that owns each step; it does not import them.
-
-For the full surface (the Preview MCP tools, the six `live_*` events, the session file, the bandit feed, degraded mode, the scope guard), see `../../reference/live-mode-integration.md`. For the SKILL.md structural contract, see `../../reference/skill-authoring-contract.md`.
-
----
-
-## Arguments
-
-- `[url]` - the page to drive. Optional. When omitted, detect the dev server and use its root.
-- `--variants N` - how many variants to generate per pick. Default 3.
-- `--resume <session-id>` - reattach to an in-progress session in `.design/live-sessions/`.
-
----
-
-## BOOT
-
-1. Probe the Preview MCP per `../../connections/preview.md`: `ToolSearch({ query: "Claude_Preview" })`, then `mcp__Claude_Preview__preview_list`. Empty ToolSearch means the MCP is not loaded.
-2. Resolve the harness live mode. The capability signal is `capability_matrix.mcp_support` in `scripts/lib/manifest/harnesses.json`, projected by `scripts/lib/live/harness-mode.cjs` (`liveModeFor(harnessId)`). A `puppeteer` result means full live mode; a `degraded` result means screenshot-only.
-3. If `mcp_support` is false for this harness, or Preview is unavailable, enter DEGRADED mode and say so plainly: variants are generated and captured as static screenshots, with no in-page hot-swap. Skip the INJECT and PICK steps; generate against the file the user names instead.
-4. Detect the dev server. Look for Vite, Next, Bun, or a static server (check `package.json` scripts plus a `preview_list` entry). Record the server descriptor on the session.
-5. Open or create the session via `scripts/lib/live/session-store.cjs` (`.design/live-sessions/<id>.json`). On `--resume`, load the named session (see RESUME).
-
----
-
-## INJECT
-
-Inject the browser runtime once. Read `RUNTIME_JS` from `scripts/lib/live/runtime.cjs` and evaluate it in the page with `mcp__Claude_Preview__preview_eval`. The runtime is an idempotent IIFE bound to `window.__gddLive`, so a re-inject after navigation rebinds the same singleton rather than stacking listeners. It installs the pick handler and the variant-swap helpers, and stamps the live variant on the element via the `data-gdd-variant` attribute.
-
----
-
-## PICK
-
-1. Arm the picker (`window.__gddLive.pick()`), then guide the user to click the target element. Use `preview_click` and `preview_inspect` to confirm the element and read its computed styles and bounding box.
-2. Read the pick report back. Its fields are documented in `pickReportShape` (selector, tagName, classList, boundingRect, computedStyle subset, current variant). The selector strategy prefers id, then a data-testid, then a tag plus class plus nth-of-type path.
-3. Emit a `live_pick` event through `scripts/lib/live/events.cjs` and append a `pick` entry to the session.
-
----
-
-## GENERATE (one batch)
-
-1. Load the relevant Phase 45 canonical reference index FIRST, so variants are grounded in real guidance: the domain index that matches the picked element (for example `../../reference/spatial.md` for layout, `../../reference/interaction.md` for components and a11y, `../../reference/color.md` for color, `../../reference/typography.md` for type, `../../reference/motion.md` for animation).
-2. Generate all N variants in ONE batch (default 3), each a distinct, hypothesis-tagged design direction for the picked element. Do not generate them one at a time.
-3. For each variant: write the change atomically to the implicated source file, then make it live. With HMR running, the file write is enough; otherwise apply the variant in place with `window.__gddLive.swapVariant({ n, style, html })`, which sets `data-gdd-variant="n"` and applies the variant's style or markup.
-
----
-
-## POST-CHECK
-
-Run the post-check on each variant via `scripts/lib/live/postcheck.cjs`, which invokes `gdd-detect`. Show the findings inline next to each variant. A variant that trips a finding is flagged, NOT auto-rejected: the user still decides. Append a `live_postcheck` event per variant.
-
----
-
-## ACCEPT / DISCARD
-
-- ACCEPT one variant: apply the chosen variant as the canonical source edit, and revert the others in the page (`window.__gddLive.revert()` on each non-chosen element). Emit a `live_accept` event and feed the outcome to the design-variants bandit via `scripts/lib/live/bandit-feed.cjs` (a dev-time signal). Append an `accept` entry.
-- DISCARD: revert every variant in the page back to its captured original and leave the source untouched. Emit a `live_discard` event and append a `discard` entry.
-
-Either way, persist the result through `scripts/lib/live/session-store.cjs` before continuing.
-
----
-
-## PERSIST
-
-Every step (boot, pick, generate, post-check, accept, discard) is written to the session file through `scripts/lib/live/session-store.cjs` as it happens. The on-disk event log uses the `pick`, `generate`, `accept`, `discard` kinds; the telemetry stream uses the six `live_*` event types. Writes are atomic, so an interrupted step never leaves a half-written session.
-
----
-
-## RESUME
-
-With `--resume <session-id>`, load the named session from `.design/live-sessions/`. Only an `in_progress` session is resumable. Offer the user two choices: continue from the last recorded event (report what that was, for example "last pick was the primary button"), or start fresh (open a new session and leave the old one intact). Never silently replay completed events.
-
----
-
-## SCOPE GUARD
-
-Never write outside the source files implicated by the picked element. Run every proposed write through `scripts/lib/live/scope-guard.cjs`, which maps the picked selector to its owning source files and rejects edits that fall outside them. If a variant would need a change beyond that scope (a shared token, a parent layout, a new dependency), stop and surface it to the user rather than widening the blast radius.
-
-## Constraints
-
-- Do NOT edit files outside the picked element's implicated sources (enforced by the scope guard).
-- Do NOT generate variants one at a time; generate the full batch, then swap.
-- Do NOT auto-reject a variant on a post-check finding; flag it and let the user decide.
-- In DEGRADED mode, state up front that hot-swap is unavailable and fall back to screenshots.
-- Persist before every user-facing prompt so a crash never loses accepted work.
-
-## LIVE COMPLETE