Design auto

Integrated Design Workflow

Handle the request directly. Do not invoke a chain of overlapping design skills. Select the smallest mode below, read only its reference file, and continue to the mode's natural stopping point.

Modes

Goal	Mode	Required reference
New page, feature, component, or redesign	build	BUILD.md
UX, accessibility, visual, or technical review	audit	AUDIT.md
Nearly finished UI needs refinement	polish	POLISH.md
Explore visual directions before implementation	prototype	PROTOTYPE.md
Add, review, audit, name, or improve motion	motion	MOTION.md

Combine references only when the outcome truly crosses modes:

• Build with important motion: BUILD.md + MOTION.md.
• Full release review: AUDIT.md + MOTION.md.
• Motion-only review or codebase audit: MOTION.md alone.
• Prototype then implement only when the user has asked for both.

Invocation variants

• --shape: clarify users, hierarchy, flows, and acceptance criteria before code.
• --craft: implement from a clear or confirmed brief.
• --component: constrain work to one component and direct dependencies.
• --visual, --tech, --a11y, --full: select audit depth.
• --bolder, --quieter, --typeset, --layout, --clarify, --harden: select polish focus.
• --animate: add purposeful motion using MOTION.md.
• --motion-review: review motion in a diff and return Block/Approve.
• --motion-audit [quick|standard|deep]: survey the codebase and produce prioritized findings; write implementation plans only after selection.
• --gesture: design drag, swipe, sheet, spring, or momentum interactions.
• --vocabulary: identify the precise name for a described animation effect.
• --deep: exhaustive, phase-gated design work. Use only when explicitly requested.

Required context

Before judging or changing an existing interface:

1. Read the target and at least one representative neighboring component.
2. Read the project's tokens, theme, global styles, and shared primitives.
3. Infer the product register: task-focused product UI or expressive brand/marketing.
4. Preserve established conventions unless a concrete UX gain justifies changing them.
5. If .superdesign/init/ exists and the mode is prototype, read all of it.

Do not block ordinary work merely because PRODUCT.md, DESIGN.md, or a specific design tool is absent. Existing code and the user's brief are valid context.

Operating rules

• With a target but an unclear goal, perform lightweight triage and choose the safest mode.
• With neither a target nor an actionable outcome, ask one concise blocking question.
• Ask only when the missing answer materially changes the design or causes destructive work.
• Use real content when available. Do not ship placeholder-only UI unless asked for a wireframe.
• Extend existing primitives before creating new abstractions.
• Implementation requests authorize relevant code edits; reviews and audits remain read-only unless fixes are requested.
• Never commit, publish, or deploy without explicit permission.
• Verify in proportion to risk: static inspection, tests, responsive checks, keyboard flow, and browser interaction where available.

--deep

Start with a phase plan containing:

1. Context and current-system discovery
2. Shape or prototype
3. Build
4. Audit
5. Polish

State the aesthetic direction, measurable success criteria, and stop condition before implementation. Do not use --deep for ordinary broad requests.

Output

Lead with the outcome. End with a compact execution summary:

• completed work
• design decisions
• verification performed
• blockers or assumptions
• artifacts or files produced
• next safe action, only if one remains

For audits, prioritize evidence and concrete fixes over generic advice. For implementations, report files changed rather than repeating the code.

Sources

This integrated workflow incorporates and adapts guidance from Emil Kowalski's skills repository, Apple's fluid-interface principles, Vercel's Web Interface Guidelines, and the previously installed local design workflows. Emil-derived material is used under the MIT license; see LICENSE-EMIL-KOWALSKI.md.