@hegemonart/get-design-done 1.57.2 → 1.58.0

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

@@ -1,87 +0,0 @@
----
-name: gdd-settings
-description: "Manage .design/config.json settings. Subcommands: profile, parallelism, cleanup, show."
-argument-hint: "<profile <name>|parallelism <key> <value>|cleanup|show>"
-tools: Read, Write, AskUserQuestion, Bash, mcp__gdd_state__get, mcp__gdd_state__frontmatter_update
-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.
-
-## Subcommands
-
-### `show`
-
-Print the current `.design/config.json` contents, nicely formatted. If the file is missing, print the defaults with a note that no config exists yet. Also call `mcp__gdd_state__get` to print the current STATE.md frontmatter keys (cycle, wave, model_profile) alongside config.json for a unified view.
-
-### `profile <name>`
-
-Set `model_profile` to one of `quality`, `balanced`, `budget`. Validate the value; reject anything else with the list of allowed values. Read current config, merge the change, write back. Confirm with the new value.
-
-### `parallelism <key> <value>`
-
-Set one field under `parallelism`. Supported keys and value types:
-
-| Key | Type |
-|---|---|
-| `enabled` | bool (`true`/`false`) |
-| `max_parallel_agents` | int |
-| `min_tasks_to_parallelize` | int |
-| `min_estimated_savings_seconds` | int |
-| `require_disjoint_touches` | bool |
-| `worktree_isolation` | bool |
-
-Validate type; reject otherwise. Read current config, merge, write back. Confirm.
-
-### `cleanup`
-
-Use `AskUserQuestion` to pick one or more cleanup actions, then confirm each before executing:
-
-1. Delete `.design/*.md` artifacts (excludes `config.json`, `STATE.md`, `backlog/`).
-2. Reset `.design/STATE.md` to the template at `reference/STATE-TEMPLATE.md`.
-3. Clear `.design/backlog/` directory contents.
-
-## Config Read/Write Pattern
-
-Always:
-
-1. Read current `.design/config.json` (use defaults below if missing).
-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
-
-For any STATE.md frontmatter patch (cycle, wave, or project-custom keys), call `mcp__gdd_state__frontmatter_update({ patch: { <key>: <value> } })`. Do not `Edit` or `Write` STATE.md directly.
-
-**Stage-patch guard:** this skill cannot patch `stage`. If the user attempts to set `stage` here, reject with: "Use /gdd:brief, /gdd:explore, etc. for stage transitions. The settings skill is for non-stage frontmatter only." The MCP tool itself rejects `stage` patches with a VALIDATION error (surfaced by `mcp__gdd_state__frontmatter_update`), which this prose surfaces up-front so the user gets a clear message before the tool round-trip.
-
-This surface is STATE.md-only. `.design/config.json` mutations continue to use `Read` + `Write` directly (out of scope for the 11-tool MCP catalog).
-
-## Default Config
-
-If `.design/config.json` does not exist, create it with:
-
-```json
-{
-  "model_profile": "balanced",
-  "parallelism": {
-    "enabled": true,
-    "max_parallel_agents": 5,
-    "min_tasks_to_parallelize": 2,
-    "min_estimated_savings_seconds": 30,
-    "require_disjoint_touches": true,
-    "worktree_isolation": false,
-    "per_stage_override": {}
-  }
-}
-```
-
-## Output
-
-End every invocation with:
-
-```
-## SETTINGS COMPLETE
-```

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

@@ -1,48 +0,0 @@
----
-name: gdd-ship
-description: "Post-verify PR flow - creates a clean PR branch, invokes code review check, and prepares the PR for merge. Activates for requests involving finishing a cycle, packaging design output, or moving work to a pull request."
-argument-hint: "[--title <PR title>] [--draft]"
-tools: Read, Write, Bash, AskUserQuestion, Task
-disable-model-invocation: true
----
-
-# /gdd:ship
-
-Closes the verify → merge gap: runs `/gdd:pr-branch` for a clean branch, assembles a PR body from design artifacts, and creates the PR via `gh`.
-
-## Steps
-
-1. **Pre-flight verify check**: Check that `.design/DESIGN-VERIFICATION.md` exists and shows a pass. If missing or failing, ask: "Verify has not completed / failed. Ship anyway? (yes/no)"
-2. **Clean branch**: Invoke `/gdd:pr-branch` to produce a branch with only `src/` commits (no `.design/` or `.planning/` noise). Use the resulting branch for the PR.
-3. **PR title**: Use `--title` argument if given, otherwise ask (AskUserQuestion): "PR title?"
-4. **PR body**: Auto-generate from:
-   - Goals section of `.design/DESIGN-PLAN.md`
-   - Summary of `.design/DESIGN-VERIFICATION.md` (per-task pass/fail)
-   - Top-line audit score from `.design/DESIGN-AUDIT.md` if present
-   Format as Markdown with `## Goals`, `## Verification`, `## Audit` sections.
-5. **Create PR**: Run `gh pr create --title "<title>" --body "<body>" [--draft]` via Bash. If `gh` is not installed, print the full body and instruct the user to create the PR manually.
-6. **Print PR URL** on success.
-
-## 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.
-
-## 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.
-
-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)
-
-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
-```
-
-Written by `hooks/update-check.sh`; suppressed mid-pipeline and when the latest release is dismissed.
-
-## SHIP COMPLETE

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

@@ -1,78 +0,0 @@
----
-name: gdd-sketch
-description: "Multi-variant HTML design exploration that creates .design/sketches/<slug>/ with N standalone variants (default 3), browser-openable directly via file:// without a build step. Use when answering 'what could this look like?' before committing to a direction."
-argument-hint: "[topic] [--variants N] [--quick]"
-tools: Read, Write, AskUserQuestion, Bash
----
-
-# 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.
-
-Unlike `/gdd:spike` (which tests feasibility), `/gdd:sketch` explores visual/directional variants.
-
-## Flag parsing
-
-Parse `$ARGUMENTS`:
-- `[topic]` → kebab-case slug (e.g., "hero-redesign")
-- `--variants N` → number of variants (default: 3)
-- `--quick` → skip intake, use DESIGN-CONTEXT.md tokens + sensible defaults
-
-## Step 1 - Intake (unless `--quick`)
-
-AskUserQuestion, one at a time:
-1. "What are you sketching? (component, layout, page)"
-2. "What directions should the variants explore? (minimal/maximal, dense/spacious, flat/layered, playful/restrained, etc.)"
-3. "Which design tokens apply? (pick from DESIGN-CONTEXT.md, or use defaults)"
-
-If `--quick`: derive directions from topic + pull tokens from `.design/DESIGN-CONTEXT.md` if present, else defaults.
-
-## Step 2 - Create sketch directory
-
-- Derive `<slug>` from the topic (kebab-case).
-- `mkdir -p .design/sketches/<slug>/` via Bash.
-
-## Step 3 - Write INTAKE.md
-
-Write `.design/sketches/<slug>/INTAKE.md` with:
-- Topic
-- Directions (one bullet per variant)
-- Token references (link to DESIGN-CONTEXT.md or inline list)
-- Timestamp
-
-## 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://`
-- Each variant explores a different direction from intake
-
-## 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
-- How to view: "Open each `variant-*.html` in a browser."
-- Next step: "Run `/gdd:sketch-wrap-up <slug>` when ready to pick a winner."
-
-## After writing
-
-```
-━━━ Sketches created ━━━
-Slug: <slug>
-Directory: .design/sketches/<slug>/
-Variants: N standalone HTML files
-Open variant-*.html in a browser.
-Next: /gdd:sketch-wrap-up <slug>
-━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Do Not
-
-- 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.
-
-## SKETCH COMPLETE

package/dist/claude-code/.claude/skills/sketch-wrap-up/SKILL.md

@@ -1,92 +0,0 @@
----
-name: gdd-sketch-wrap-up
-description: "Walk through sketches, pick winner + rationale, group by design area, write project skills to ./.claude/skills/design-<area>-conventions.md."
-argument-hint: "[slug]"
-tools: Read, Write, Glob, AskUserQuestion
----
-
-# 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.
-
-## 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
-
-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
-
-AskUserQuestion in sequence:
-
-1. "Which variant is the winner?"
-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
-
-AskUserQuestion: "Which design area does this winner inform?" Options: `typography / color / layout / motion / component / interaction`.
-
-## Step 5 - Write project skill
-
-Append to `./.claude/skills/design-<area>-conventions.md` (create if missing):
-
-```markdown
-# Design <Area> Conventions (Project-Local)
-
-Auto-loaded in gdd sessions. Captures decisions codified from `/gdd:sketch-wrap-up`.
-
-## Decision from sketch: <slug> (YYYY-MM-DD)
-**Winner**: variant-N (<direction label>)
-**Rationale**: <user rationale>
-**Token implications**: <implications, or "none">
-```
-
-## 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
-
-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
-
-Append to `.design/sketches/SUMMARY.md` (create if missing):
-
-```
-- <slug> (YYYY-MM-DD) — winner: variant-N — area: <area> — D-XX — <one-line rationale>
-```
-
-## After writing
-
-```
-━━━ Sketch wrapped ━━━
-Slug: <slug>
-Winner: variant-N
-Area: <area>
-Decision recorded: D-XX
-Prototyping entry: <sketch slug="<slug>" cycle="<cycle>" decision="D-XX" status="resolved"/>
-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.
-
-## SKETCH-WRAP-UP COMPLETE

package/dist/claude-code/.claude/skills/skill-manifest/SKILL.md

@@ -1,79 +0,0 @@
----
-name: gdd-skill-manifest
-description: "Lists all registered GDD skills and agents, with descriptions, from the intel store. Falls back to directory scan if intel store not present."
-tools: Bash, Read, Glob
----
-
-# /gdd:skill-manifest
-
-**Role:** Print a manifest of all registered skills (commands) and agents available in this plugin installation.
-
-## Pre-flight check
-
-```bash
-ls .design/intel/exports.json 2>/dev/null && echo "ready" || echo "missing"
-```
-
-## Mode 1 - Intel store available
-
-Read `.design/intel/exports.json`. Group entries by `kind` (skill vs agent). Print:
-
-```
-━━━ Skill Manifest ━━━
-Generated from intel store: .design/intel/exports.json
-
-SKILLS (Commands)
-─────────────────
-/gdd:scan               gdd-scan
-/gdd:discover           gdd-discover
-/gdd:plan               gdd-plan
-/gdd:design             gdd-design
-/gdd:verify             gdd-verify
-/gdd:style              gdd-style
-/gdd:darkmode           gdd-darkmode
-/gdd:compare            gdd-compare
-... (all skills)
-
-AGENTS
-──────
-design-advisor          Design advisor agent
-design-auditor          Design auditor agent
-design-context-builder  Builds DESIGN-CONTEXT.md from codebase scan
-... (all agents)
-
-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)
-
-If `.design/intel/exports.json` is not present, fall back to directory scan:
-
-```bash
-ls skills/
-ls agents/*.md
-```
-
-Print a simplified manifest without descriptions:
-
-```
-━━━ Skill Manifest (no intel store — run build-intel.cjs for descriptions) ━━━
-
-SKILLS: scan, discover, plan, design, verify, style, darkmode, compare, ...
-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
-
-## Required reading (conditional)
-
-@.design/intel/exports.json (if present)
-
-## SKILL-MANIFEST COMPLETE

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

@@ -1,67 +0,0 @@
----
-name: gdd-spike
-description: "Timeboxed feasibility experiment that creates .design/spikes/<slug>/ with HYPOTHESIS.md, success/failure criteria, scratch/ subdirectory, and a default 60-minute timebox. Use when answering 'can this work?' before betting design or implementation effort on a risky approach."
-argument-hint: "[hypothesis] [--timebox <minutes>]"
-tools: Read, Write, Bash, AskUserQuestion
----
-
-# 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.
-
-## Flag parsing
-
-Parse `$ARGUMENTS`:
-- `[hypothesis]` → summary phrase, derives the slug
-- `--timebox <minutes>` → default 60
-
-## Step 1 - Intake
-
-AskUserQuestion:
-1. "What's the hypothesis? (e.g., 'view transitions can replace our current route animations')"
-2. "What's the timebox? (default 60 minutes)"
-3. "What would prove it works? (success criteria)"
-4. "What would prove it doesn't? (failure criteria)"
-
-## 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
-
-Write `.design/spikes/<slug>/HYPOTHESIS.md`:
-```markdown
-# Spike: <slug>
-
-**Hypothesis**: <statement>
-**Timebox**: <N> minutes
-**Started**: YYYY-MM-DD HH:MM
-
-## Success criteria
-- <criterion>
-
-## Failure criteria
-- <criterion>
-
-## Scratch area
-Experimental code in `./scratch/` — not committed to src/.
-```
-
-## Step 4 - Announce
-
-```
-━━━ Spike started ━━━
-Slug: <slug>
-Timebox: <N> minutes
-Work in: .design/spikes/<slug>/scratch/
-When done: /gdd:spike-wrap-up <slug>
-━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Do Not
-
-- 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/dist/claude-code/.claude/skills/spike-wrap-up/SKILL.md

@@ -1,86 +0,0 @@
----
-name: gdd-spike-wrap-up
-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
-
-**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
-
-- 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
-
-Read `.design/spikes/<slug>/HYPOTHESIS.md`. Show the hypothesis + success/failure criteria to the user.
-
-## Step 3 - Elicit findings
-
-AskUserQuestion in sequence:
-
-1. "Did it meet success criteria? (yes / no / partial)"
-2. "What was learned? (1–3 sentences)"
-3. "Recommendation? (adopt / reject / needs more investigation)"
-
-## Step 4 - Write FINDINGS.md
-
-Write `.design/spikes/<slug>/FINDINGS.md`:
-
-```markdown
-# Findings: <slug>
-
-**Verdict**: yes / no / partial
-**Recommendation**: adopt / reject / needs more investigation
-**Completed**: YYYY-MM-DD HH:MM
-
-## What was learned
-<1–3 sentences>
-
-## Next steps
-<1–2 bullets>
-```
-
-## 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
-
-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
-
-Append to `.design/spikes/SUMMARY.md` (create if missing):
-
-```
-- <slug> (YYYY-MM-DD) — verdict: <yes|no|partial> — recommendation: <adopt|reject|more> — D-XX
-```
-
-## After writing
-
-```
-━━━ Spike wrapped ━━━
-Slug: <slug>
-Verdict: <verdict>
-Decision recorded: D-XX
-Prototyping entry: <spike slug="<slug>" cycle="<cycle>" decision="D-XX" verdict="<verdict>" status="resolved"/>
-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.
-
-## SPIKE-WRAP-UP COMPLETE

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

@@ -1,67 +0,0 @@
----
-name: start
-description: "First-Run Proof Path - one command that scans your UI code and returns one concrete first fix. Leaf command, no STATE.md writes, no pipeline entry. Writes .design/START-REPORT.md and exits."
-argument-hint: "[--budget <fast|balanced|thorough>] [--skip-interview] [--dismiss-nudge]"
-tools: Read, Grep, Glob, Bash, Write, Task
-disable-model-invocation: true
----
-
-# Get Design Done - /gdd:start
-
-**Role:** the canonical 0→1 proof path. A new user runs `/gdd:start`, answers five short questions, and receives `.design/START-REPORT.md` with three concrete findings in the user's own code, one `best_first_proof` selected by a deterministic rubric, and a single next command to run.
-
-**Non-goals:** do NOT write/mutate `.design/STATE.md`, enter the pipeline state machine, modify source code, auto-install MCPs or run `/gdd:connections`, or capture before/after screenshots (that belongs to the full pipeline).
-
----
-
-## When to use
-
-- First time opening a repo with the get-design-done plugin installed.
-- The user wants a single proof-of-value pass without committing to the pipeline.
-
-## When NOT to use
-
-- `.design/STATE.md` already exists - route to `/gdd:progress` instead.
-- User asked for a full audit - route to `/gdd:scan`.
-- User asked to fix a specific file - route to `/gdd:fast`.
-
----
-
-## Arguments
-
-| Flag | Effect |
-|------|--------|
-| `--budget fast` | 90-second wall-clock cap on the findings scan. Skips thorough detectors. |
-| `--budget balanced` *(default)* | 3-minute wall-clock cap. All detectors, bounded file walk. |
-| `--budget thorough` | 5-minute wall-clock cap. Used only when the user opts in. |
-| `--skip-interview` | Skip the 5-question interview; use sane defaults (pain=unspecified, area=detected, budget=balanced, framework=detected, figma=skip). |
-| `--dismiss-nudge` | Touch `~/.claude/gdd-nudge-dismissed` and exit. Does not run the scan. |
-
----
-
-## Workflow
-
-Six steps, all documented in `./start-procedure.md`. Companion file `./reference/start-interview.md` holds the 5-question copy + defaults + validation.
-
-| Step | What it does | Where to look |
-|------|--------------|---------------|
-| 0 | Dismiss-only shortcut (if `--dismiss-nudge`) | `start-procedure.md#step-0-dismiss-only-shortcut` |
-| 1 | Detect UI root via `scripts/lib/detect-ui-root.cjs` (early-exit on backend-only or `kind: null`) | `start-procedure.md#step-1-detect-ui-root` |
-| 2 | Run 5-question interview (or use `--skip-interview` defaults); write `.design/.start-context.json` (NOT STATE.md) | `start-procedure.md#step-2-run-the-5-question-interview` + `start-interview.md` |
-| 3 | Invoke `scripts/lib/start-findings-engine.cjs` → up to 3 findings (`F1`..`F3`) + `bestFirstProofId` | `start-procedure.md#step-3-scan-findings` |
-| 4 | Spawn `design-start-writer` Task → emit `.design/START-REPORT.md` (7 H2 sections + JSON block, no STATE.md write) | `start-procedure.md#step-4-spawn-the-writer` |
-| 5 | Print one-line handoff with suggested command (fallback: `/gdd:brief` if `bestFirstProofId` is null); emit `## START COMPLETE` | `start-procedure.md#step-5-print-the-handoff` |
-
-Failure handling: every error path exits with `## START COMPLETE` plus a one-line pointer. Do not half-write files - if the writer fails, keep `.design/.start-context.json` and tell the user they can rerun. Do not delete `.design/` unless it was empty before the run.
-
----
-
-## Do Not
-
-- Do not write or mutate `.design/STATE.md`.
-- Do not modify source code.
-- Do not auto-install MCPs or write to `.design/config.json`.
-- Do not take more than the budgeted wall-clock - let the engine truncate findings rather than hang.
-- Do not invent findings - the findings engine output is the sole source of truth.
-
-## START COMPLETE