# Design

> Design workflows — UX copy, design systems, design critique, accessibility review, design handoff, user research synthesis. Use when writing UI copy, reviewing designs, building component systems, checking accessibility, or preparing developer handoffs.

- **Type:** Skill
- **Install:** `agentstack add skill-notque-vexjoy-agent-design`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [notque](https://agentstack.voostack.com/s/notque)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [notque](https://github.com/notque)
- **Source:** https://github.com/notque/vexjoy-agent/tree/main/skills/business/design
- **Website:** https://vexjoy.com

## Install

```sh
agentstack add skill-notque-vexjoy-agent-design
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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 | Avoid |
|-------|-------|-------|
| Exploration | Concept direction, user flow logic, information architecture | Pixel-level visual polish |
| Refinement | Visual hierarchy, interaction patterns, consistency, edge cases | Questioning the fundamental approach |
| Final | Color contrast, spacing precision, copy accuracy, accessibility | Structural redesign suggestions |

**Gate**: Critique covers usability, visual hierarchy, consistency, and accessibility. Feedback is specific (element + issue + recommendation). Positive observations included. Stage-appropriate depth.

### ACCESSIBILITY Mode

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

1. **Determine scope**: Full WCAG 2.1 AA audit vs targeted check (contrast, keyboard, screen reader).

2. **Audit by WCAG principle**:

| Principle | Key Criteria |
|-----------|-------------|
| Perceivable | Alt text (1.1.1), semantic structure (1.3.1), text contrast 4.5:1 (1.4.3), UI contrast 3:1 (1.4.11) |
| Operable | Keyboard access (2.1.1), focus order (2.4.3), visible focus (2.4.7), touch targets 44x44px (2.5.5) |
| Understandable | Predictable behavior (3.2.1), error identification (3.3.1), input labels (3.3.2) |
| Robust | Name/role/value for all UI components (4.1.2) |

3. **Check component-specific patterns** from reference (buttons, forms, modals, navigation, data tables, carousels).

4. **Generate audit report** with:
   - Issue count by severity (Critical, Major, Minor)
   - Each finding: WCAG criterion, location, issue, severity, remediation
   - Color contrast check table (foreground, background, ratio, required, pass/fail)
   - Keyboard navigation map
   - Screen reader announcement check
   - Priority fixes ranked by user impact

**Gate**: Audit covers all four WCAG principles. Each finding cites a specific WCAG criterion. Remediation provided for every issue. Severity reflects real user impact.

### HANDOFF Mode

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

1. **Gather inputs**:
   - Design (Figma URL, screenshot, description)
   - Tech stack (framework, CSS approach, component library)
   - Design system tokens (if available)
   - Target breakpoints

2. **Generate spec** covering all artifact categories:

| Category | Contents |
|----------|----------|
| Layout | Grid system, breakpoints, responsive behavior rules |
| Design tokens | Color, typography, spacing, elevation — token names mapped to values |
| Components | Name, variant, props, special behavior notes |
| States | Every interactive element: default, hover, active, disabled, loading, error |
| Interactions | Click/tap, hover, transitions (duration + easing), gestures |
| Content | Character limits, truncation rules, empty states, loading states |
| Edge cases | Min/max content, i18n text expansion, slow connections, missing data |
| Accessibility | Focus order, ARIA labels/roles, keyboard interactions, screen reader announcements |
| Animation | Element, trigger, description, duration (ms), easing function |

3. **Validate completeness**:
   - Every interactive element has all states specified
   - Token references used (not raw values)
   - Edge cases documented (empty, loading, error, overflow, missing data)
   - Responsive behavior explicit at each breakpoint
   - Accessibility requirements stated

**Gate**: Spec covers all categories in the table. Uses token references. All states documented. Edge cases present. A developer can build from this spec without guessing.

### RESEARCH Mode

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

1. **Accept inputs** — Interview transcripts, survey data, usability test notes, support tickets, app reviews, NPS responses.

2. **Process each source**:
   - Extract observations (what happened), verbatim quotes, behaviors (vs stated preferences), pain points, positive signals, context
   - Behavioral data outweighs stated preferences. What users do > what users say.

3. **Synthesize**:
   - Affinity mapping: one observation per note, let clusters emerge, split large clusters
   - Theme development: initial codes -> theme candidates -> review against evidence -> refined themes
   - Triangulation: findings supported by multiple sources are stronger. Flag single-source findings.

4. **Priority matrix**:

| | High Impact | Low Impact |
|---|---|---|
| **High Frequency** | Top priority | Quality-of-life |
| **Low Frequency** | Segment-specific | Note and deprioritize |

5. **Generate synthesis**:
   - Executive summary (3-4 sentences)
   - Key themes: name, prevalence (X of Y participants), summary, supporting evidence with quotes, implication
   - Insights-to-opportunities table: insight, opportunity, impact, effort
   - User segments identified: name, characteristics, needs, rough size
   - Prioritized recommendations with evidence basis
   - Questions for further research
   - Methodology notes and limitations

**Gate**: Themes supported by evidence with quotes. Behaviors distinguished from stated preferences. Quote attribution uses participant type ("Enterprise admin, 200-person team"), not names. Recommendations tied to specific findings.

---

## LLM Failure Modes in Design Work

**Load `references/llm-design-failure-modes.md` for all modes.** These are specific ways LLMs fail at design tasks:

| Failure Mode | What Happens | Defense |
|-------------|-------------|---------|
| Generic copy | Copy sounds professional but lacks product personality and context | Ground every piece in the product's existing voice, user's emotional state, and specific feature context |
| Inaccessible suggestions | Recommends color combinations or patterns that fail WCAG | Check every color pairing against 4.5:1 (text) and 3:1 (UI) ratios. Verify keyboard paths. |
| Platform-blind critique | Applies desktop heuristics to mobile or iOS patterns to Android | Identify target platform first. Apply platform-specific conventions. |
| Missing edge cases | Specs cover happy path but omit empty, loading, error, overflow, i18n states | Use the edge case checklist from handoff reference for every spec. |
| Surface-level critique | "Looks clean" or "good hierarchy" without specificity | Every critique finding names the element, the issue, and a concrete recommendation. |
| Fabricated research | Invents plausible user quotes, statistics, or persona details | Every finding cites user-provided source material. Flag confidence levels. Mark assumptions explicitly. |
| Token-value confusion | Specs use raw px/hex values instead of design tokens | Reference token names. Flag any raw value as "needs token mapping." |
| Framework dumping | Lists heuristics or WCAG criteria as a checklist without applying to the specific design | Apply each criterion to the actual design. Skip criteria that do not apply. Explain how each applies. |

---

## Output Conventions

- Markdown with clear headers. Scannable by busy designers and developers.
- Tables for comparisons, audit findings, component specs, token mappings.
- Severity labels: **Critical** (blocks users), **Major** (degrades experience), **Minor** (polish).
- Every recommendation is specific enough to act on. "Improve contrast" is not actionable. "Change body text from #999 to #595959 on #fff background to meet 4.5:1 ratio" is.
- Include what works well alongside what needs improvement.

---

## Reference Loading Table

| Mode | Primary Reference | Secondary Reference |
|------|------------------|-------------------|
| UX-COPY | `references/ux-copy.md` | `references/llm-design-failure-modes.md` |
| DESIGN-SYSTEM | `references/design-systems.md` | `references/llm-design-failure-modes.md` |
| CRITIQUE | `references/design-critique.md` | `references/llm-design-failure-modes.md` |
| ACCESSIBILITY | `references/accessibility-review.md` | `references/llm-design-failure-modes.md` |
| HANDOFF | `references/design-handoff.md` | `references/llm-design-failure-modes.md` |
| RESEARCH | (inline) | `references/llm-design-failure-modes.md` |

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [notque](https://github.com/notque)
- **Source:** [notque/vexjoy-agent](https://github.com/notque/vexjoy-agent)
- **License:** MIT
- **Homepage:** https://vexjoy.com

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-notque-vexjoy-agent-design
- Seller: https://agentstack.voostack.com/s/notque
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.