design

# Design

Umbrella skill for design workflows: UX copy, design systems, critique, accessibility review, developer handoff, and user research synthesis. Each mode loads its own reference files on demand.

---

## Mode Detection

Classify into one mode before proceeding.

| Mode | Signal Phrases | Reference |
|------|---------------|-----------|
| **UX-COPY** | write copy, button text, error message, empty state, onboarding copy, tooltip text, confirmation dialog, notification copy | `references/ux-copy.md` |
| **DESIGN-SYSTEM** | design tokens, component library, naming conventions, audit components, document component, extend system, theme architecture | `references/design-systems.md` |
| **CRITIQUE** | review design, critique mockup, design feedback, evaluate screen, visual hierarchy, usability review | `references/design-critique.md` |
| **ACCESSIBILITY** | WCAG, accessibility audit, color contrast, keyboard navigation, screen reader, a11y, focus management, ARIA | `references/accessibility-review.md` |
| **HANDOFF** | developer handoff, spec sheet, handoff doc, implementation spec, design-to-dev, responsive spec | `references/design-handoff.md` |
| **RESEARCH** | synthesize research, interview analysis, usability findings, survey results, user segments, research themes | (inline — see workflow) |

If the request spans modes, pick the primary mode and note the secondary.

---

## Workflow by Mode

### UX-COPY Mode

**Load**: `references/ux-copy.md`, `references/llm-design-failure-modes.md`

1. **Gather context** — Ask conversationally:
   - Component type (button, error, empty state, tooltip, confirmation, notification, onboarding)
   - User state and emotional context (frustrated, exploring, completing a task)
   - Brand voice (formal, friendly, playful, reassuring)
   - Constraints (character limits, platform guidelines, localization needs)
   - Existing copy patterns (what terminology the product already uses)

2. **Generate copy** using component-specific patterns from reference:
   - Primary recommendation with rationale
   - 2-3 alternatives with tone/context guidance
   - Localization notes (character expansion, idiom risks, cultural context)

3. **Validate** — Check against these gates:
   - Copy uses product's existing terminology consistently
   - Action labels match outcomes (button says what it does)
   - Error messages follow What happened + Why + How to fix
   - Character limits respected for target platform
   - No jargon without explanation

**Gate**: Copy exists for all requested components. Each piece has rationale tied to user context. Alternatives provided with differentiated use cases.

### DESIGN-SYSTEM Mode

**Load**: `references/design-systems.md`, `references/llm-design-failure-modes.md`

1. **Determine operation**:

| Operation | Inputs | Key Actions |
|-----------|--------|-------------|
| Audit | Component library or codebase | Check naming consistency, token coverage, hardcoded values, state completeness, documentation gaps |
| Document | Component name + context | Generate props/variants/states/accessibility/usage spec |
| Extend | Gap description + existing system | Propose new component using existing tokens and patterns, show relationship to existing components |

2. **Execute** using design token architecture from reference:
   - Tokens: color (brand, semantic, neutral), typography (scale, weights, line heights), spacing (scale, component padding), borders (radius, width), shadows (elevation), motion (duration, easing)
   - Components: variants, states (default, hover, active, disabled, loading, error), sizes, accessibility, composition patterns
   - Patterns: form patterns, navigation patterns, data display, feedback

3. **Validate**:

| Check | Criteria |
|-------|----------|
| Naming | Consistent convention across all components |
| Tokens | No hardcoded values — everything references a token |
| States | All interactive states defined (default, hover, active, disabled, loading, error) |
| A11y | ARIA roles, keyboard behavior, screen reader announcements documented |
| Composition | Component works standalone and composed with others |

**Gate**: Output uses consistent naming. All values reference tokens. Interactive states complete. Accessibility documented.

### CRITIQUE Mode

**Load**: `references/design-critique.md`, `references/llm-design-failure-modes.md`

1. **Gather context**:
   - Design stage (exploration, refinement, final polish)
   - Target users and their goals
   - Focus area (optional — "just the navigation" vs full review)
   - Platform (web desktop, web mobile, native iOS, native Android)

2. **Apply structured critique** — Four-step method:
   - **Describe**: What is present? Elements, layout, visual relationships. No judgment yet.
   - **Analyze**: How are design principles applied? Hierarchy, contrast, alignment, proximity, repetition.
   - **Interpret**: What does the design communicate? Emotional tone, brand alignment, user expectations.
   - **Evaluate**: What works, what could improve, and specific recommendations.

3. **Evaluate against heuristics** — Apply Nielsen's 10 to the specific design:

| Heuristic | Key Question |
|-----------|-------------|
| Visibility of system status | Does the user know what's happening? |
| Match with real world | Does it use the user's language and mental models? |
| User control and freedom | Can the user undo, go back, escape? |
| Consistency and standards | Does it follow platform conventions and its own patterns? |
| Error prevention | Does the design prevent errors before they happen? |
| Recognition over recall | Are options visible, not memorized? |
| Flexibility and efficiency | Does it serve both novices and experts? |
| Aesthetic and minimalist design | Does every element earn its space? |
| Error recovery | Are errors explained with clear recovery paths? |
| Help and documentation | Is contextual help available where needed? |

4. **Match feedback to stage**:

| Stage | Focus | A