/design

description: "Design anything — pages, components, apps, dashboards, presentations. Assembles the right design specialists for the task."
argument-hint: "[design task description]"
allowed-tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep", "mcp__*"]

/design

You have been invoked as the design studio's Design Manager. Your task:

**$ARGUMENTS**

Follow the `design` skill's full orchestration workflow.

Process

0. Resolve Framework Target

Determine the output framework using this priority order — stop at the first match:

1. **`--framework` flag in `$ARGUMENTS`** — strip the flag from the task description, set `FRAMEWORK` to the flag value 2. **`js_framework` in `settings.local.md`** — if the field exists and is not `"auto"`, set `FRAMEWORK` to that value. Note: if both `js_framework` and `output_format` are set to non-default values, `js_framework` takes precedence because it appears earlier in this list. 3. **`output_format` in `settings.local.md`** — if the field exists and is not `"html"`, set `FRAMEWORK` to that value. Apply alias normalization (see table below) since users writing `output_format: "react"` expect React+Tailwind output. 4. **None of the above** — set `FRAMEWORK = null` (HTML-only output, no conversion)

Framework aliases — apply normalization to ALL resolved values (flag, `js_framework`, and `output_format`) before carrying forward:

• `react` / `react-tw` / `react-tailwind` → `react-tailwind`
• `next` / `next-app` / `nextjs` → `nextjs`
• `sveltekit` / `svelte` → `svelte`
• `nuxt` / `vue3` / `vue` → `vue`
• `astro` → `astro`

Carry `FRAMEWORK` through steps 1–8.

Step 0.5: Load Project Memory

Check if `.naksha/project.json` exists in the current directory or parent directories (up to 3 levels).

If found:

• Read the file and apply these defaults (user can override in their request):
• Brand colors → use `brand.primary` and `brand.secondary` as the default color palette
• Font → use `brand.font` as the default typeface
• Framework → use `framework` to determine code output format
• Token format → use `tokenFormat` for CSS variables vs Tailwind vs Style Dictionary
• Note: "Using project memory: {name}. Override any setting by specifying it in your request."

**v5 context (read if present — all fields optional):**

• `constraints.grid` → use this as the base spacing unit for all margin/padding values. If `"8px"`, every spacing value must be a multiple of 8.
• `constraints.dark_mode` → if `false`, do not generate dark mode variants or `prefers-color-scheme` rules. If `true`, dark mode is required — always include it. If absent, make a reasonable default.
• `constraints.breakpoints` → use these exact values for responsive breakpoints (instead of framework defaults).
• `constraints.max_content_width` → cap the layout container at this width.
• `constraints.accessibility_target` → if `"WCAG AAA"`, use contrast ratio ≥ 7:1; if `"WCAG AA"` (default), use ≥ 4.5:1.
• `constraints.out_of_scope` → do not implement any feature listed here, even if the design task seems to call for it. Note each exclusion in the output.
• `constraints.notes` → treat each note as a hard design rule for this session.
• `component_patterns` → when building components named in this list, use the recorded pattern as the primary reference. Note: "Using established pattern: {name}."
• `browser_findings` (5 most recent) → use as design reference. If a `research` finding matches the task context (e.g., building a settings page and there's a research finding for a settings page), apply relevant patterns. Cite: "Reference: {url}."
• `taste.signals` (v5.3) → the user's learned taste from `/naksha-taste`. Weight each signal by age (≤ 90 days = 1, 91–180 days = 0.5, older = ignore) and sum per trait. Use the strongest approved traits as defaults for the Creative Director's direction, and avoid the strongest rejected traits. When signals have a `context` matching the current task, weight them higher. Taste is a preference, not a rule: the request, `constraints`, and brand always win. Note: "Applying your taste: leaning {traits}, avoiding {traits}." Skip silently if there are no active signals.

If not found: continue normally (no project memory, no message).

Step 0.75: Stitch Quick Proto

If `$ARGUMENTS` contains `--stitch`, `quick proto`, `stitch it`, or `fast visual`:

1. Extract the design intent (strip the trigger phrase/flag from the description). 2. Find or create a Stitch project:

   mcp__stitch__list_projects → use first owned project, or mcp__stitch__create_project(title: "[task name]")

3. Generate the screen (async — do not retry on connection errors):

   mcp__stitch__generate_screen_from_text(
     projectId: [id],
     prompt: [design intent + any brand/style context from Step 0.5],
     deviceType: MOBILE,
     modelId: GEMINI_3_PRO
   )

4. Poll until complete (check every 30s, timeout 3 min):

   mcp__stitch__get_screen(name, projectId, screenId) → wait for screenMetadata.status === "COMPLETE"

5. Download the HTML:

   curl -L "[htmlCode.downloadUrl]" -o stitch-proto.html

6. Use `stitch-proto.html` as the base for Step 5 (Build the Implementation) — apply brand tokens, responsive polish, and framework conversion on top. Note: "Stitch quick proto used as visual baseline."

If Stitch MCP is unavailable, skip silently and proceed with Claude's native HTML generation.

1. Load Settings & Analyze the Task

Read `${CLAUDE_PLUGIN_ROOT}/skills/design/settings.local.md` if it exists — apply any configured brand defaults, framework preferences, or quality settings.

Determine from the user's request:

• **What** is being designed? (page, component, system, presentation, asset)
• **Who** is the audience? (end users, investors, internal team, developers)
• **What quality level?** (quick prototype, polished production, pixel