Reorganize: Move all skills to skills/ folder

- Created skills/ directory
- Moved 272 skills to skills/ subfolder
- Kept agents/ at root level
- Kept installation scripts and docs at root level

Repository structure:
- skills/           - All 272 skills from skills.sh
- agents/           - Agent definitions
- *.sh, *.ps1       - Installation scripts
- README.md, etc.   - Documentation

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
admin
2026-01-23 18:05:17 +00:00
Unverified
parent 2b4e974878
commit b723e2bd7d
4083 changed files with 1056 additions and 1098063 deletions

View File

@@ -0,0 +1,15 @@
{
"name": "design-plugins",
"description": "Design exploration plugins for Claude Code",
"owner": {
"name": "0xdesigner"
},
"plugins": [
{
"name": "design-and-refine",
"source": "./design-and-refine",
"description": "Generate UI variations, collect feedback, synthesize the best elements, and iterate to confident design decisions",
"version": "0.1.0"
}
]
}

View File

@@ -0,0 +1,157 @@
# Design and Refine
A Claude Code plugin that helps you make confident UI design decisions through rapid iteration.
## What It Does
Design and Refine generates multiple distinct UI variations for any component or page, lets you compare them side-by-side in your browser, collects your feedback on what you like about each, and synthesizes a refined version—repeating until you're confident in the result.
Instead of guessing at the right design or going back-and-forth on revisions, you see real options, pick what works, and iterate quickly.
## When to Use It
- **Starting a new component or page** — explore different approaches before committing
- **Redesigning existing UI** — see alternatives to what you have today
- **Stuck on a design direction** — generate options when you're not sure what you want
- **Getting stakeholder buy-in** — show concrete variations instead of describing ideas
- **Learning what works** — see how different layouts, densities, and patterns feel in your actual codebase
## Why Use It
1. **Uses your existing design system** — infers colors, typography, spacing from your Tailwind config, CSS variables, or component library
2. **Generates real code** — not mockups, actual working components in your framework
3. **Side-by-side comparison** — view all variations at `/__design_lab` in your dev server
4. **Iterative refinement** — tell it what you like about each, get a synthesized version
5. **Clean handoff** — outputs `DESIGN_PLAN.md` with implementation steps when you're done
6. **No mess left behind** — automatically cleans up all temporary files
---
## Setup
### 1. Add the marketplace
In Claude Code, run:
```
/plugin marketplace add 0xdesign/design-plugin
```
### 2. Install the plugin
```
/plugin install design-and-refine@design-plugins
```
That's it. The plugin is now available in any project.
---
## Usage
### Start a session
```
/design-and-refine:start
```
Or with a specific target:
```
/design-and-refine:start ProfileCard
```
### What happens next
1. **Preflight** — detects your framework (Next.js, Vite, etc.) and styling system (Tailwind, MUI, etc.)
2. **Style inference** — reads your existing design tokens from Tailwind config, CSS variables, or theme files
3. **Interview** — asks about:
- What you're designing (component vs page, new vs redesign)
- Pain points and what should improve
- Visual and interaction inspiration
- Target user and key tasks
4. **Generation** — creates 5 distinct variations exploring different:
- Information hierarchy
- Layout models (cards, lists, tables, split-pane)
- Density (compact vs spacious)
- Interaction patterns (modal, inline, drawer)
- Visual expression
5. **Review** — open `http://localhost:3000/__design_lab` (or your dev server port) to see all variations side-by-side
6. **Feedback** — tell Claude:
- If one is already good → select it, make minor tweaks
- If you like parts of different ones → describe what you like about each, get a synthesized version
7. **Iterate** — repeat until you're confident
8. **Finalize** — all temp files are deleted, `DESIGN_PLAN.md` is generated with implementation steps
### Clean up manually (if needed)
```
/design-and-refine:cleanup
```
---
## Supported Frameworks
- Next.js (App Router & Pages Router)
- Vite (React, Vue)
- Remix
- Astro
- Create React App
## Supported Styling
- Tailwind CSS
- CSS Modules
- Material UI (MUI)
- Chakra UI
- Ant Design
- styled-components
- Emotion
---
## Tips for Best Results
**Be specific in the interview.** The more context you give about pain points, target users, and inspiration, the more distinct and useful the variations will be.
**Reference products you admire.** "Like Linear's density" or "Stripe's clarity" gives Claude concrete direction.
**Don't settle on round one.** The synthesis step is where it gets good—describe what you like about each variant and let it combine them.
**Keep your dev server running.** The plugin won't start it for you (that would block). Just have it running in another terminal.
**Check the DESIGN_PLAN.md.** After finalizing, this file contains the implementation steps, component API, accessibility checklist, and testing guidance.
---
## What Gets Created (Temporarily)
During the session:
- `.claude-design/` — variants, previews, design brief
- `app/__design_lab/` or `pages/__design_lab.tsx` — the comparison route
All of this is deleted when you finalize or abort. Nothing is left behind.
## What Gets Created (Permanently)
After finalizing:
- `DESIGN_PLAN.md` — implementation plan for your chosen design
- `DESIGN_MEMORY.md` — captured style decisions (speeds up future sessions)
---
## License
MIT
---
Made by [0xdesigner](https://github.com/0xdesign)

View File

@@ -0,0 +1,10 @@
{
"name": "design-and-refine",
"description": "Generate distinct UI design variations, collect feedback, synthesize the best elements, and produce implementation plans",
"version": "0.1.0",
"author": {
"name": "0xdesigner"
},
"keywords": ["design", "ui", "frontend", "prototyping", "refine", "iterate"],
"license": "MIT"
}

View File

@@ -0,0 +1,82 @@
# Design and Refine
Generate UI design variations, collect feedback, synthesize the best elements, and iterate to confident design decisions.
## Installation
### Local Testing
```bash
claude --plugin-dir /path/to/design-variations-plugin
```
### From Marketplace
```bash
/plugin marketplace add 0xdesigner/design-plugin
/plugin install design-and-refine@design-plugins
```
## Commands
### `/design-and-refine:start [target]`
Start a design and refine session.
**Arguments:**
- `target` (optional): Component or page to design/redesign
**Example:**
```
/design-and-refine:start CheckoutSummary
/design-and-refine:start
```
### `/design-and-refine:cleanup`
Remove all temporary design lab files.
## How It Works
1. **Preflight**: Detects framework, package manager, styling system
2. **Style Inference**: Reads your existing design tokens and patterns
3. **Interview**: Asks about requirements, pain points, and direction
4. **Generate**: Creates 5 distinct variations using your project's visual language
5. **Review**: Preview variants side-by-side at `/__design_lab`
6. **Feedback**: Tell me what you like about each variant
7. **Synthesize**: Creates a refined version combining the best elements
8. **Iterate**: Repeat until you're confident
9. **Finalize**: Cleans up temp files, produces `DESIGN_PLAN.md`
## Supported Frameworks
- Next.js (App Router & Pages Router)
- Vite (React, Vue)
- Remix
- Astro
- Create React App
## Supported Styling
- Tailwind CSS
- CSS Modules
- Material UI
- Chakra UI
- Ant Design
- styled-components
- Emotion
## Files Created
### Temporary (cleaned up on completion or abort)
- `.claude-design/` - All temporary variants and previews
- `app/__design_lab/` or `pages/__design_lab.tsx` - Lab route
- `app/__design_preview/` or `pages/__design_preview.tsx` - Preview route
### Permanent (kept after finalization)
- `DESIGN_PLAN.md` - Implementation plan for the chosen design
- `DESIGN_MEMORY.md` - Reusable style decisions for future runs
## License
MIT

View File

@@ -0,0 +1,47 @@
---
description: Remove all temporary design lab files created during a design-and-refine session
---
# Cleanup Command
Manually clean up all temporary files created during a design-and-refine session.
## Usage
```
/design-and-refine:cleanup
```
## What This Does
Removes all temporary files and directories created during design exploration:
1. **`.claude-design/`** - The main temporary directory containing:
- Design lab variants
- Preview files
- Design brief JSON
- Run logs
2. **Temporary routes:**
- `app/__design_lab/` (Next.js App Router)
- `app/__design_preview/` (Next.js App Router)
- `pages/__design_lab.tsx` (Next.js Pages Router)
- `pages/__design_preview.tsx` (Next.js Pages Router)
3. **Any App.tsx modifications** (for Vite projects without routers)
## Instructions
When this command is invoked:
1. Check if `.claude-design/` directory exists
2. If it exists, list the contents and ask for confirmation before deleting
3. Check for temporary route files in common locations
4. Delete confirmed files
5. Report what was deleted
**Safety rules:**
- ONLY delete files inside `.claude-design/`
- ONLY delete route files that match the plugin's naming pattern (`__design_lab`, `__design_preview`)
- Always confirm with the user before deleting
- Never delete user-authored files

View File

@@ -0,0 +1,40 @@
---
description: Start a design and refine session - generate variations, collect feedback, and iterate to the perfect design
---
# Start Design & Refine
Begin an interactive design session that generates UI variations, collects your feedback, and iterates until you're confident in the result.
## Usage
```
/design-and-refine:start [target]
```
**Arguments:**
- `target` (optional): The component or page to design/redesign. If not provided, you'll be asked.
## What This Does
1. **Interviews you** about requirements, pain points, and style direction
2. **Infers visual styles** from your existing codebase
3. **Generates five distinct variations** in a temporary Design Lab route
4. **Collects your feedback** on what you like about each
5. **Synthesizes a refined version** combining the best elements
6. **Iterates until you're confident** in the final design
7. **Cleans up** all temporary files and produces an implementation plan
## Instructions
When this command is invoked, follow the Design Lab skill workflow exactly. The skill contains:
- The complete interview script
- Framework and styling detection logic
- Visual style inference from the project
- Variant generation guidelines
- Feedback collection and synthesis process
- Cleanup procedures
$ARGUMENTS will contain any target specified by the user.
Begin by running the preflight detection, then start the interview process. Use the AskUserQuestion tool for all interview steps.

View File

@@ -0,0 +1,27 @@
{
"description": "Check for leftover design lab files on session end",
"hooks": {
"SessionEnd": [
{
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-check.sh",
"timeout": 10
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-check.sh",
"timeout": 10
}
]
}
]
}
}

View File

@@ -0,0 +1,21 @@
#!/bin/bash
# Design Variations Plugin - Cleanup Check Script
# This runs on session end to check for leftover temporary files
# Check if .claude-design directory exists in current project
if [ -d ".claude-design" ]; then
echo "[Design Variations] Warning: Temporary design files found in .claude-design/"
echo "[Design Variations] Run '/design-variations:cleanup' to remove them, or delete manually."
fi
# Check for leftover route files (Next.js)
if [ -d "app/__design_lab" ] || [ -d "app/__design_preview" ]; then
echo "[Design Variations] Warning: Temporary route directories found in app/"
fi
if [ -f "pages/__design_lab.tsx" ] || [ -f "pages/__design_preview.tsx" ]; then
echo "[Design Variations] Warning: Temporary route files found in pages/"
fi
exit 0

View File

@@ -0,0 +1,503 @@
# Design Principles Reference
This document contains curated best practices from world-class designers and design systems. Reference these principles when generating design variations.
---
## Part 1: UX Foundations
### Jakob Nielsen's 10 Usability Heuristics
1. **Visibility of system status** - Always keep users informed through appropriate feedback within reasonable time
2. **Match between system and real world** - Use familiar language, concepts, and conventions
3. **User control and freedom** - Provide clear "emergency exits" (undo, cancel, back)
4. **Consistency and standards** - Follow platform conventions; same words mean same things
5. **Error prevention** - Eliminate error-prone conditions or ask for confirmation
6. **Recognition over recall** - Minimize memory load; make options visible
7. **Flexibility and efficiency** - Provide accelerators for expert users (shortcuts, defaults)
8. **Aesthetic and minimalist design** - Remove irrelevant information; every element competes
9. **Help users recover from errors** - Plain language errors with constructive solutions
10. **Help and documentation** - Provide concise, task-focused help when needed
### Don Norman's Design Principles
- **Affordances** - Design elements should suggest their usage
- **Signifiers** - Visual cues that indicate where actions should happen
- **Mapping** - Controls should relate spatially to their effects
- **Feedback** - Every action needs a perceivable response
- **Conceptual model** - Users should understand how the system works
### Cognitive Load Principles
- **Limit choices** - 5-7 items max in navigation; 3-4 options in decisions
- **Progressive disclosure** - Show only what's needed at each step
- **Chunking** - Group related items; break long forms into steps
- **Visual hierarchy** - Guide attention with size, color, contrast, position
- **Reduce cognitive friction** - Minimize decisions, clicks, and reading
---
## Part 2: Visual Design Systems
### Typography (from iA, Stripe, Linear)
**Hierarchy:**
```
Display: 32-48px, -0.02em tracking, 700 weight
Heading 1: 24-32px, -0.02em tracking, 600 weight
Heading 2: 20-24px, -0.01em tracking, 600 weight
Heading 3: 16-18px, normal tracking, 600 weight
Body: 14-16px, normal tracking, 400 weight
Caption: 12-13px, +0.01em tracking, 400-500 weight
```
**Best practices:**
- Max 60-75 characters per line for readability
- Line height: 1.4-1.6 for body text, 1.2-1.3 for headings
- Use weight contrast (400 vs 600) more than size contrast
- Limit to 2 font families maximum
- System fonts for performance: `-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif`
### Spacing System (8px grid)
```
4px - Tight: icon padding, inline spacing
8px - Base: related elements, form field padding
12px - Comfortable: between form fields
16px - Standard: section padding, card padding
24px - Relaxed: between sections
32px - Spacious: major section breaks
48px - Generous: page section separation
64px+ - Hero: landing page sections
```
**Spacing principles:**
- Related items closer together (Gestalt proximity)
- Consistent internal padding (all sides equal, or vertical > horizontal)
- White space is not wasted space—it creates focus
- Touch targets minimum 44x44px (Apple HIG)
### Color (from Stripe, Linear, Vercel)
**Neutral foundation:**
```
Background: #FFFFFF / #000000 (dark)
Surface: #FAFAFA / #111111 (dark)
Border: #E5E5E5 / #333333 (dark)
Text primary: #171717 / #EDEDED (dark)
Text secondary: #737373 / #A3A3A3 (dark)
Text tertiary: #A3A3A3 / #737373 (dark)
```
**Accent usage:**
- Primary action: single brand color, used sparingly
- Interactive elements: consistent color for all clickable items
- Semantic colors: red (error), green (success), yellow (warning), blue (info)
- Hover states: 10% darker or add subtle background
- Focus states: 2px ring with offset, high contrast
**Color principles:**
- WCAG AA minimum: 4.5:1 for text, 3:1 for UI elements
- One primary accent color; avoid rainbow interfaces
- Use opacity for secondary states (hover, disabled)
- Dark mode: don't just invert—reduce contrast, use darker surfaces
### Border Radius (from modern SaaS)
```
None (0px): Tables, dividers, full-bleed images
Small (4px): Buttons, inputs, tags, badges
Medium (8px): Cards, modals, dropdowns
Large (12px): Feature cards, hero elements
Full (9999px): Avatars, pills, toggle tracks
```
**Principles:**
- Consistency: pick 2-3 radius values and stick to them
- Nested elements: inner radius = outer radius - padding
- Sharp corners feel technical/precise; round feels friendly/approachable
### Shadows & Elevation (from Material, Linear)
```
Level 0: none (flat, on surface)
Level 1: 0 1px 2px rgba(0,0,0,0.05) - Subtle lift (cards)
Level 2: 0 4px 6px rgba(0,0,0,0.07) - Raised (dropdowns)
Level 3: 0 10px 15px rgba(0,0,0,0.1) - Floating (modals)
Level 4: 0 20px 25px rgba(0,0,0,0.15) - High (popovers)
```
**Principles:**
- Shadows should feel like natural light (top-down, slight offset)
- Dark mode: use lighter surface colors instead of shadows
- Combine with subtle border for definition
- Interactive elements can elevate on hover
---
## Part 3: Component Patterns
### Buttons (from Stripe, Linear)
**Hierarchy:**
1. **Primary** - One per view, main action, filled with brand color
2. **Secondary** - Supporting actions, outlined or ghost style
3. **Tertiary** - Low-emphasis actions, text-only with hover state
4. **Destructive** - Delete/remove actions, red with confirmation
**States:**
- Default → Hover (+shadow or darken) → Active (scale 0.98) → Disabled (50% opacity)
- Loading: replace text with spinner, maintain width
- Min width: 80px; min height: 36px (touch-friendly: 44px)
**Best practices:**
- Verb + noun labels: "Create project" not "Create"
- Sentence case, not ALL CAPS
- Icon left of text (or icon-only with tooltip)
- Primary button right-aligned in forms/dialogs
### Forms (from Airbnb, Stripe)
**Input anatomy:**
```
┌─────────────────────────────────┐
│ Label │
│ ┌─────────────────────────────┐ │
│ │ Placeholder / Value │ │
│ └─────────────────────────────┘ │
│ Helper text or error message │
└─────────────────────────────────┘
```
**Best practices:**
- Labels above inputs (not inside—accessibility)
- Placeholder ≠ label; use for format hints only
- Inline validation on blur, not on every keystroke
- Error messages: specific and actionable ("Email must include @")
- Success state: checkmark icon, green border (brief)
- Required fields: mark optional ones instead of required
- Single column forms outperform multi-column
### Cards (from Material, Apple)
**Anatomy:**
```
┌────────────────────────────────┐
│ [Media/Image] │ ← Optional
├────────────────────────────────┤
│ Eyebrow · Metadata │ ← Optional
│ Title │ ← Required
│ Description text that can │ ← Optional
│ wrap to multiple lines... │
├────────────────────────────────┤
│ [Actions] [More] │ ← Optional
└────────────────────────────────┘
```
**Best practices:**
- Entire card clickable for primary action
- Consistent padding (16-24px)
- Image aspect ratios: 16:9, 4:3, 1:1 (be consistent)
- Limit to 2 actions max; overflow to menu
- Hover: subtle lift (translateY -2px + shadow increase)
### Tables (from Linear, Notion)
**Best practices:**
- Left-align text, right-align numbers
- Zebra striping OR row hover, not both
- Sticky header on scroll
- Sortable columns: show current sort indicator
- Actions: row hover reveals action buttons (or kebab menu)
- Empty state: helpful message + action
- Pagination vs infinite scroll: pagination for data accuracy, infinite for browsing
- Min row height: 48px for touch; 40px for dense
### Navigation (from Apple HIG, Material)
**Patterns by scale:**
- **2-5 items**: Tab bar / horizontal tabs
- **5-10 items**: Side navigation (collapsible)
- **10+ items**: Side nav with sections/groups
**Best practices:**
- Current location always visible
- Breadcrumbs for deep hierarchy (not for flat structures)
- Mobile: bottom nav for primary actions (thumb-friendly)
- Icons + labels together; icon-only needs tooltip
- Consistent order across pages
---
## Part 4: Interaction Design
### Feedback Patterns (from Dan Saffer's Microinteractions)
**Every action needs feedback:**
1. **Immediate** - Button press visual (scale, color change)
2. **Progress** - Loading states for anything >1s
3. **Completion** - Success confirmation (toast, checkmark, animation)
4. **Failure** - Clear error with recovery path
**Loading states:**
- 0-100ms: No indicator needed
- 100-300ms: Subtle change (opacity, skeleton)
- 300ms-1s: Spinner or progress bar
- 1s+: Skeleton screens + progress indication
- 10s+: Background processing with notification
### State Handling
**Every component needs these states:**
```
Default → Base appearance
Hover → Interactive hint (cursor change, highlight)
Focus → Keyboard navigation (visible ring)
Active → Being pressed/activated
Loading → Async operation in progress
Disabled → Not available (reduce opacity, remove pointer)
Error → Invalid input or failed operation
Success → Completed successfully (brief)
Empty → No data to display (helpful message + action)
```
### Optimistic Updates (from Linear, Notion)
- Update UI immediately, sync in background
- Show subtle "Saving..." indicator
- On failure: revert UI + show error toast with retry
- Best for: toggles, reordering, text edits
- Avoid for: destructive actions, payments
### Progressive Disclosure
**Reveal complexity gradually:**
- Show essential options first
- "Advanced" or "More options" for power features
- Inline expansion over page navigation
- Tooltips for supplementary information
- Context menus for secondary actions
---
## Part 5: Motion & Animation
### The 12 Principles (Adapted for UI)
1. **Timing** - Fast for small changes (150-200ms), slow for large (300-500ms)
2. **Easing** - Never linear; use ease-out for entrances, ease-in for exits
3. **Anticipation** - Slight scale up before action (button press)
4. **Follow-through** - Elements settle into place (subtle overshoot)
5. **Staging** - Direct attention; one thing animates at a time
6. **Secondary action** - Supporting elements animate subtly with primary
### Timing Guidelines (from Material Motion)
```
Micro-interactions: 100-150ms (buttons, toggles, hover)
Small transitions: 150-200ms (dropdowns, tooltips)
Medium transitions: 200-300ms (modals, panels)
Large transitions: 300-500ms (page transitions, complex reveals)
Staggered lists: 50-100ms between items
```
### Easing Functions
```css
/* Standard easings */
--ease-out: cubic-bezier(0.16, 1, 0.3, 1); /* Entrances */
--ease-in: cubic-bezier(0.7, 0, 0.84, 0); /* Exits */
--ease-in-out: cubic-bezier(0.65, 0, 0.35, 1); /* Move/resize */
/* Expressive easings */
--ease-spring: cubic-bezier(0.34, 1.56, 0.64, 1); /* Playful bounce */
--ease-smooth: cubic-bezier(0.4, 0, 0.2, 1); /* Material standard */
```
### Animation Patterns
**Entrances:**
- Fade in + slide up (8-16px)
- Scale from 0.95 to 1 + fade
- Stagger children by 50ms
**Exits:**
- Fade out (faster than entrance)
- Scale to 0.95 + fade
- Slide in direction of dismissal
**Hover/Focus:**
- TranslateY -2px (lift)
- Scale 1.02-1.05 (grow)
- Shadow increase
- Background color shift
**Loading:**
- Skeleton shimmer (gradient animation)
- Pulse (opacity 0.5-1)
- Spinner (rotate continuously)
### Reduced Motion
```css
@media (prefers-reduced-motion: reduce) {
*, *::before, *::after {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
```
Always respect user preferences. Replace motion with:
- Instant state changes
- Opacity transitions only
- No parallax or auto-playing video
---
## Part 6: Accessibility Essentials
### WCAG Quick Reference
**Perceivable:**
- Color contrast: 4.5:1 text, 3:1 UI components
- Don't rely on color alone (add icons, patterns)
- Text resizable to 200% without loss
- Captions for video; transcripts for audio
**Operable:**
- All functionality via keyboard
- No keyboard traps
- Skip links for repeated content
- Touch targets: 44x44px minimum
**Understandable:**
- Consistent navigation
- Identify input errors clearly
- Labels and instructions for forms
**Robust:**
- Semantic HTML elements
- ARIA only when HTML isn't enough
- Tested with screen readers
### Focus Management
```css
/* Visible focus for keyboard users */
:focus-visible {
outline: 2px solid var(--color-primary);
outline-offset: 2px;
}
/* Remove default only if custom focus exists */
:focus:not(:focus-visible) {
outline: none;
}
```
### ARIA Patterns
```html
<!-- Button (when not using <button>) -->
<div role="button" tabindex="0" aria-pressed="false">
<!-- Modal -->
<div role="dialog" aria-modal="true" aria-labelledby="title">
<!-- Tab panel -->
<div role="tablist">
<button role="tab" aria-selected="true" aria-controls="panel1">
</div>
<div role="tabpanel" id="panel1">
<!-- Live region (for dynamic updates) -->
<div aria-live="polite" aria-atomic="true">
<!-- Loading state -->
<button aria-busy="true" aria-describedby="loading-text">
```
---
## Part 7: Design System References
### Study These Systems
**For Clarity & Precision:**
- [Linear](https://linear.app) - Information density done right
- [Stripe](https://stripe.com) - Trust through craft
- [Vercel](https://vercel.com) - Developer-focused simplicity
**For Warmth & Approachability:**
- [Airbnb](https://airbnb.com) - Friendly, image-forward
- [Notion](https://notion.so) - Flexible, playful
- [Slack](https://slack.com) - Conversational, colorful
**For Data & Density:**
- [Bloomberg Terminal](https://bloomberg.com) - Maximum information
- [Figma](https://figma.com) - Tool-like precision
- [GitHub](https://github.com) - Code-centric clarity
**For Motion & Delight:**
- [Apple](https://apple.com) - Cinematic quality
- [Framer](https://framer.com) - Motion-first
- [Lottie examples](https://lottiefiles.com) - Micro-animation inspiration
### When Generating Variants
Reference specific aspects:
- "Use Linear's density approach"
- "Stripe's button hierarchy"
- "Airbnb's card layout"
- "Notion's toggle interaction"
- "Vercupdate the el's dark mode palette"
---
## Quick Decision Framework
When unsure, ask:
1. **Is it clear?** → User knows what to do and what happened
2. **Is it fast?** → Minimum steps, appropriate feedback
3. **Is it consistent?** → Matches patterns elsewhere in the app
4. **Is it accessible?** → Keyboard, screen reader, color contrast
5. **Is it calm?** → No unnecessary motion, color, or elements

View File

@@ -0,0 +1,792 @@
---
name: design-lab
description: Conduct design interviews, generate five distinct UI variations in a temporary design lab, collect feedback, and produce implementation plans. Use when the user wants to explore UI design options, redesign existing components, or create new UI with multiple approaches to compare.
---
# Design Lab Skill
This skill implements a complete design exploration workflow: interview, generate variations, collect feedback, refine, preview, and finalize.
## CRITICAL: Cleanup Behavior
**All temporary files MUST be deleted when the process ends, whether by:**
- User confirms final design → cleanup, then generate plan
- User aborts/cancels → cleanup immediately, no plan generated
**Never leave `.claude-design/` or `__design_lab` routes behind.** If the user says "cancel", "abort", "stop", or "nevermind" at any point, confirm and then delete all temporary artifacts.
---
## Phase 0: Preflight Detection
Before starting the interview, automatically detect:
### Package Manager
Check for lock files in the project root:
- `pnpm-lock.yaml` → use `pnpm`
- `yarn.lock` → use `yarn`
- `package-lock.json` → use `npm`
- `bun.lockb` → use `bun`
### Framework Detection
Check for config files:
- `next.config.js` or `next.config.mjs` or `next.config.ts`**Next.js**
- Check for `app/` directory → App Router
- Check for `pages/` directory → Pages Router
- `vite.config.js` or `vite.config.ts`**Vite**
- `remix.config.js`**Remix**
- `nuxt.config.js` or `nuxt.config.ts`**Nuxt**
- `astro.config.mjs`**Astro**
### Styling System Detection
Check `package.json` dependencies and config files:
- `tailwind.config.js` or `tailwind.config.ts`**Tailwind CSS**
- `@mui/material` in dependencies → **Material UI**
- `@chakra-ui/react` in dependencies → **Chakra UI**
- `antd` in dependencies → **Ant Design**
- `styled-components` in dependencies → **styled-components**
- `@emotion/react` in dependencies → **Emotion**
- `.css` or `.module.css` files → **CSS Modules**
### Design Memory Check
Look for existing Design Memory file:
- `docs/design-memory.md`
- `DESIGN_MEMORY.md`
- `.claude-design/design-memory.md`
If found, read it and use to prefill defaults and skip redundant questions.
### Visual Style Inference (CRITICAL)
**DO NOT use generic/predefined styles. Extract visual language from the project:**
**If Tailwind detected**, read `tailwind.config.js` or `tailwind.config.ts`:
```javascript
// Extract and use:
theme.colors // Color palette
theme.spacing // Spacing scale
theme.borderRadius // Radius values
theme.fontFamily // Typography
theme.boxShadow // Elevation system
```
**If CSS Variables exist**, read `globals.css`, `variables.css`, or `:root` definitions:
```css
:root {
--color-* /* Color tokens */
--spacing-* /* Spacing tokens */
--font-* /* Typography tokens */
--radius-* /* Border radius tokens */
}
```
**If UI library detected** (MUI, Chakra, Ant), read the theme configuration:
- MUI: `theme.ts` or `createTheme()` call
- Chakra: `theme/index.ts` or `extendTheme()` call
- Ant: `ConfigProvider` theme prop
**Always scan existing components** to understand patterns:
- Find 2-3 existing buttons → note their styling patterns
- Find 2-3 existing cards → note padding, borders, shadows
- Find existing forms → note input styles, label placement
- Find existing typography → note heading sizes, body text
**Store inferred styles in the Design Brief** for consistent use across all variants.
---
## Phase 1: Interview
Use the **AskUserQuestion** tool for all interview steps. Adapt questions based on Design Memory if it exists.
### Step 1.1: Scope & Target
Ask these questions (can combine into single AskUserQuestion with multiple questions):
**Question 1: Scope**
- Header: "Scope"
- Question: "Are we designing a single component or a full page?"
- Options:
- "Component" - A reusable UI element (button, card, form, modal, etc.)
- "Page" - A complete page or screen layout
**Question 2: New or Redesign**
- Header: "Type"
- Question: "Is this a new design or a redesign of something existing?"
- Options:
- "New" - Creating something from scratch
- "Redesign" - Improving an existing component/page
If "Redesign" selected, ask:
**Question 3: Existing Path**
- Header: "Location"
- Question: "What is the file path or route of the existing UI?"
- Options: (let user provide via "Other")
If target is unclear, propose a name based on repo patterns and confirm.
### Step 1.2: Pain Points & Inspiration
**Question 1: Pain Points**
- Header: "Problems"
- Question: "What are the top pain points with the current design (or what should this new design avoid)?"
- Options:
- "Too cluttered/dense" - Information overload, hard to scan
- "Unclear hierarchy" - Primary actions aren't obvious
- "Poor mobile experience" - Doesn't work well on small screens
- "Outdated look" - Feels old or inconsistent with brand
- multiSelect: true
**Question 2: Visual Inspiration**
- Header: "Visual style"
- Question: "What products or brands should I reference for visual inspiration?"
- Options:
- "Stripe" - Clean, minimal, trustworthy
- "Linear" - Dense, keyboard-first, developer-focused
- "Notion" - Flexible, content-focused, playful
- "Apple" - Premium, spacious, refined
- multiSelect: true
**Question 3: Functional Inspiration**
- Header: "Interactions"
- Question: "What interaction patterns should I emulate?"
- Options:
- "Inline editing" - Edit in place without modals
- "Progressive disclosure" - Show more as needed
- "Optimistic updates" - Instant feedback, sync in background
- "Keyboard shortcuts" - Power user efficiency
### Step 1.3: Brand & Style Direction
**Question 1: Brand Adjectives**
- Header: "Brand tone"
- Question: "What 3-5 adjectives describe the desired brand feel?"
- Options:
- "Minimal" - Clean, simple, uncluttered
- "Premium" - High-end, polished, refined
- "Playful" - Fun, friendly, approachable
- "Utilitarian" - Functional, efficient, no-nonsense
- multiSelect: true
**Question 2: Density**
- Header: "Density"
- Question: "What information density do you prefer?"
- Options:
- "Compact" - More information visible, tighter spacing
- "Comfortable" - Balanced spacing, easy scanning
- "Spacious" - Generous whitespace, focused attention
**Question 3: Dark Mode**
- Header: "Dark mode"
- Question: "Is dark mode required?"
- Options:
- "Yes" - Must support dark mode
- "No" - Light mode only
- "Nice to have" - Support if easy, not required
### Step 1.4: Persona & Jobs-to-be-Done
**Question 1: Primary User**
- Header: "User"
- Question: "Who is the primary end user?"
- Options:
- "Developer" - Technical, keyboard-oriented
- "Designer" - Visual, detail-oriented
- "Business user" - Efficiency-focused, less technical
- "End consumer" - General public, varied technical ability
**Question 2: Context**
- Header: "Context"
- Question: "What's the primary usage context?"
- Options:
- "Desktop-first" - Primarily used on larger screens
- "Mobile-first" - Primarily used on phones
- "Both equally" - Must work well on all devices
**Question 3: Key Tasks**
- Header: "Key tasks"
- Question: "What are the top 3 tasks users must complete?"
- (Let user provide via "Other" - this is open-ended)
### Step 1.5: Constraints
**Question 1: Must-Keep Elements**
- Header: "Keep"
- Question: "Are there elements that must be preserved?"
- Options:
- "Existing copy/labels" - Keep current text
- "Current fields/inputs" - Keep form structure
- "Navigation structure" - Keep current nav
- "None" - Free to change everything
**Question 2: Technical Constraints**
- Header: "Constraints"
- Question: "Any technical constraints?"
- Options:
- "No new dependencies" - Use existing libraries only
- "Use existing components" - Build on current design system
- "Must be accessible (WCAG)" - Strict accessibility requirements
- "None" - No special constraints
- multiSelect: true
---
## Phase 2: Generate Design Brief
After the interview, create a structured Design Brief as JSON and save to `.claude-design/design-brief.json`:
```json
{
"scope": "component|page",
"isRedesign": true|false,
"targetPath": "src/components/Example.tsx",
"targetName": "Example",
"painPoints": ["Too dense", "Primary action unclear"],
"inspiration": {
"visual": ["Stripe", "Linear"],
"functional": ["Inline validation"]
},
"brand": {
"adjectives": ["minimal", "trustworthy"],
"density": "comfortable",
"darkMode": true
},
"persona": {
"primary": "Developer",
"context": "desktop-first",
"keyTasks": ["Complete checkout", "Review order", "Apply discount"]
},
"constraints": {
"mustKeep": ["existing fields"],
"technical": ["no new dependencies", "WCAG accessible"]
},
"framework": "nextjs-app",
"packageManager": "pnpm",
"stylingSystem": "tailwind"
}
```
Display a summary to the user before proceeding.
---
## Phase 3: Generate Design Lab
### Directory Structure
Create all files under `.claude-design/`:
```
.claude-design/
├── lab/
│ ├── page.tsx # Main lab page (framework-specific)
│ ├── variants/
│ │ ├── VariantA.tsx
│ │ ├── VariantB.tsx
│ │ ├── VariantC.tsx
│ │ ├── VariantD.tsx
│ │ └── VariantE.tsx
│ ├── components/
│ │ └── LabShell.tsx # Lab layout wrapper
│ └── data/
│ └── fixtures.ts # Shared mock data
├── design-brief.json
└── run-log.md
```
### Route Integration
**Next.js App Router:**
Create `app/__design_lab/page.tsx` that imports from `.claude-design/lab/`
**Next.js Pages Router:**
Create `pages/__design_lab.tsx` that imports from `.claude-design/lab/`
**Vite React:**
- If React Router exists: add route to `/__design_lab`
- If no router: create a conditional render in `App.tsx` based on `?design_lab=true` query param
**Other frameworks:**
Create the most appropriate temporary route for the detected framework.
### Variant Generation Guidelines
**IMPORTANT:** Read `DESIGN_PRINCIPLES.md` for UX, interaction, and motion best practices. But **DO NOT use predefined visual styles**—infer them from the project.
**Apply universal principles (from DESIGN_PRINCIPLES.md):**
- **UX**: Nielsen's heuristics, cognitive load reduction, progressive disclosure
- **Component behavior**: Button states, form anatomy, card structure
- **Interaction**: Feedback patterns, state handling, optimistic updates
- **Motion**: Timing (150-300ms), easing (ease-out entrances, ease-in exits)
- **Accessibility**: Focus states, ARIA patterns, touch targets (44px min)
**Infer visual styles from the project:**
- Colors → from Tailwind config, CSS variables, or existing components
- Typography → from existing headings, body text in the codebase
- Spacing → from the project's spacing scale or existing patterns
- Border radius → from existing cards, buttons, inputs
- Shadows → from existing elevated components
---
Each variant MUST explore a different design axis. Do not create minor variations—make them meaningfully distinct. **Use the project's existing visual language for all variants.**
**Variant A: Information Hierarchy Focus**
- Restructure content hierarchy (what's most important?)
- Apply Gestalt proximity—group related items closer
- One primary action per view
- Use existing typography scale to create clear levels
**Variant B: Layout Model Exploration**
- Try a different layout approach (card vs list vs table vs split-pane)
- Apply card anatomy or table behavior patterns from DESIGN_PRINCIPLES
- Consider responsive behavior at each breakpoint
- Use the project's existing grid/layout system
**Variant C: Density Variation**
- If brief says "comfortable", try a more compact version
- If brief says "compact", try a more spacious version
- Use the project's existing spacing tokens—just apply them differently
- Show the tradeoffs: more visible data vs easier scanning
**Variant D: Interaction Model**
- Different interaction pattern (modal vs inline vs panel vs drawer)
- Apply feedback patterns: immediate → progress → completion
- Implement all required states (loading, error, empty, disabled)
- Consider optimistic updates for non-destructive actions
**Variant E: Expressive Direction**
- Push the brand direction the user described in the interview
- Explore different uses of the project's existing design tokens
- More or less use of shadows, borders, background colors
- Apply motion where it adds meaning (hover, focus, transitions)
### Lab Page Requirements
The Design Lab page must include:
1. **Header** with:
- Design Brief summary (target, scope, key requirements)
- Instructions for reviewing
2. **Variant Grid** with:
- Clear labels (A, B, C, D, E)
- Brief rationale for each variant ("Why this exists")
- The actual rendered variant
- Notes highlighting key differences
3. **Responsive behavior**:
- Desktop: side-by-side grid (2-3 columns)
- Mobile: horizontal scroll or tabs
4. **Shared Data**:
- All variants use the same fixture data from `data/fixtures.ts`
- Ensures fair comparison
### Code Quality
**Conventions:**
- Follow the project's existing code conventions (file naming, imports, etc.)
- Use the detected styling system (Tailwind, CSS modules, etc.)
- Use existing components from the project where appropriate
**Accessibility (from DESIGN_PRINCIPLES):**
- Semantic HTML: `<button>` not `<div onclick>`, `<nav>`, `<main>`, `<section>`
- Keyboard navigation: all interactive elements focusable and operable
- Focus states: visible `:focus-visible` with 2px ring and offset
- Color contrast: 4.5:1 for text, 3:1 for UI elements
- Touch targets: minimum 44x44px
- ARIA only when HTML semantics aren't enough
**States (every component needs):**
- Default, Hover, Focus, Active, Disabled, Loading, Error, Empty
- See DESIGN_PRINCIPLES "State Handling" section
**Motion:**
- Use appropriate timing: 150-200ms for micro-interactions, 200-300ms for transitions
- Use ease-out for entrances, ease-in for exits
- Respect `prefers-reduced-motion`
---
## Phase 4: Present Design Lab to User
After generating the lab files, **immediately** present the lab to the user. Do NOT attempt to:
- Start the dev server yourself (it runs forever and will block)
- Check if ports are open
- Open a browser
- Wait for any server response
### What to Do
1. **Output the lab location and URL:**
```
✅ Design Lab created!
I've generated 5 design variants in `.claude-design/lab/`
To view them:
1. Make sure your dev server is running (run `pnpm dev` if not)
2. Open: http://localhost:3000/__design_lab
Take your time reviewing the variants side-by-side, then come back and tell me:
- Which variant wins (A-E)
- What you like about it
- What should change
```
2. **Immediately proceed to Phase 5** - ask for feedback. Do NOT wait for the user to say they've opened the browser. Just present the feedback questions right away so they're ready when the user returns.
### Why Not Start the Server
Running `pnpm dev` or `npm run dev` starts a long-running process that never exits. If you run it, you'll wait forever. The user likely already has their dev server running, or can start it themselves in another terminal.
---
## Phase 5: Collect Feedback
After presenting the lab URL, collect feedback in two stages:
### Stage 1: Check for a Winner
**Question 1: Ready to pick?**
- Header: "Decision"
- Question: "Is there one variant you like as is?"
- Options:
- "Yes - I found one I like" - Ready to select a winner and refine
- "No - I like parts of different ones" - Need to synthesize a new variant
### Stage 2A: If User Found a Winner
If user said "Yes", ask:
**Question 2a: Which one?**
- Header: "Winner"
- Question: "Which variant do you want to go with?"
- Options:
- "Variant A" - [brief description of A]
- "Variant B" - [brief description of B]
- "Variant C" - [brief description of C]
- "Variant D" - [brief description of D]
- "Variant E" - [brief description of E]
**Question 3a: Any tweaks?**
- Header: "Tweaks"
- Question: "Any small changes needed, or is it good as is?"
- Options:
- "Good as is" - No changes needed, proceed to final preview
- "Minor tweaks needed" - I'll describe what to adjust
If "Minor tweaks needed", ask user to describe changes via text input.
Then proceed to **Phase 7: Final Preview**.
### Stage 2B: If User Wants to Synthesize
If user said "No - I like parts of different ones", ask:
**Question 2b: What do you like about each?**
- Header: "Feedback"
- Question: "What do you like about each variant? (mention specific elements from A, B, C, D, E)"
- (Let user provide detailed feedback via "Other" text input)
Example response format to guide user:
```
- A: Love the card layout and spacing
- B: The color scheme feels right
- C: The interaction on hover is great
- D: Nothing stands out
- E: The typography hierarchy is clearest
```
Then proceed to **Phase 6: Synthesize New Variant**.
---
## Phase 6: Synthesize New Variant
Based on the user's feedback about what they liked from each variant:
1. **Create a new hybrid variant** (Variant F) that combines:
- The specific elements the user called out from each
- The best structural decisions across all variants
- Any patterns that appeared in multiple variants
2. **Replace the Design Lab** with a comparison view:
- Show the new synthesized Variant F prominently
- Keep 1-2 of the original variants that were closest for comparison
- Remove variants that had nothing the user liked
3. **Update the `/__design_lab` route** to show the new arrangement
4. **Ask for feedback again:**
**Question: How's the new variant?**
- Header: "Review"
- Question: "How does the synthesized variant (F) look?"
- Options:
- "This is it!" - Proceed to final preview
- "Getting closer" - Need another iteration
- "Went the wrong direction" - Let me clarify what I want
If "Getting closer" or "Went the wrong direction", gather more specific feedback and iterate. Support multiple synthesis passes until user is satisfied.
Then proceed to **Phase 7: Final Preview**.
---
## Phase 7: Final Preview
Once user is satisfied:
1. Create `.claude-design/preview/` directory:
```
.claude-design/preview/
├── page.tsx # Preview page
└── FinalDesign.tsx # The winning design
```
2. Create route at `/__design_preview`
3. For redesigns, include before/after comparison:
- Toggle switch or split view
- Show original alongside proposed
4. Ask for final confirmation:
**Question: Confirm final design?**
- Header: "Confirm"
- Question: "Ready to finalize this design?"
- Options:
- "Yes, finalize it" - Proceed to cleanup and generate implementation plan
- "No, needs changes" - Tell me what to adjust
- "Abort - cancel everything" - Delete all temp files, no plan generated
If "No, needs changes": gather feedback and iterate.
If "Abort": proceed to **Abort Handling** below.
---
## Abort Handling
If the user wants to cancel/abort at ANY point during the process (not just final confirmation), they may say things like:
- "cancel"
- "abort"
- "stop"
- "nevermind"
- "forget it"
- "I changed my mind"
When abort is detected:
1. **Confirm the abort:**
- "Are you sure you want to cancel? This will delete all the design lab files I created."
2. **If confirmed, clean up immediately:**
- Delete `.claude-design/` directory entirely
- Delete temporary route files (`app/__design_lab/`, etc.)
- Do NOT generate any implementation plan
- Do NOT update Design Memory
3. **Acknowledge:**
- "Design exploration cancelled. All temporary files have been cleaned up. Let me know if you want to start fresh later."
---
## Phase 8: Finalize
When user confirms (selected "Yes, finalize it"):
### 8.1: Cleanup
Delete all temporary files:
- Remove `.claude-design/` directory entirely
- Remove temporary route files:
- `app/__design_lab/` (Next.js App Router)
- `pages/__design_lab.tsx` (Next.js Pages Router)
- `app/__design_preview/`
- `pages/__design_preview.tsx`
- Revert any `App.tsx` modifications (Vite)
**Safety rules:**
- ONLY delete files inside `.claude-design/`
- ONLY delete route files that the plugin created
- NEVER delete user-authored files
- Verify file paths before deletion
### 8.2: Generate Implementation Plan
Create `DESIGN_PLAN.md` in the project root:
```markdown
# Design Implementation Plan: [TargetName]
## Summary
- **Scope:** [component/page]
- **Target:** [file path]
- **Winner variant:** [A-E]
- **Key improvements:** [from feedback]
## Files to Change
- [ ] `src/components/Example.tsx` - Main component refactor
- [ ] `src/styles/example.css` - Style updates
- [ ] ... (list all affected files)
## Implementation Steps
1. [Specific step with code guidance]
2. [Next step]
3. ...
## Component API
- **Props:**
- `prop1: type` - description
- ...
- **State:**
- Internal state requirements
- **Events:**
- Callbacks and handlers
## Required UI States
- **Loading:** [description]
- **Empty:** [description]
- **Error:** [description]
- **Disabled:** [description]
- **Validation:** [description]
## Accessibility Checklist
- [ ] Keyboard navigation works
- [ ] Focus states visible
- [ ] Labels and aria-* attributes correct
- [ ] Color contrast meets WCAG AA
- [ ] Screen reader tested
## Testing Checklist
- [ ] Unit tests for logic
- [ ] Component tests for rendering
- [ ] Visual regression tests (if applicable)
- [ ] E2E smoke test (if applicable)
## Design Tokens
- [Any new tokens to add]
- [Existing tokens to use]
---
*Generated by Design Variations plugin*
```
### 8.3: Update Design Memory
Create or update `DESIGN_MEMORY.md`:
If new file:
```markdown
# Design Memory
## Brand Tone
- **Adjectives:** [from interview]
- **Avoid:** [anti-patterns discovered]
## Layout & Spacing
- **Density:** [preference]
- **Grid:** [if established]
- **Corner radius:** [if consistent]
- **Shadows:** [if consistent]
## Typography
- **Headings:** [font, weights used]
- **Body:** [font, size]
- **Emphasis:** [patterns]
## Color
- **Primary:** [color tokens]
- **Secondary:** [color tokens]
- **Neutral strategy:** [approach]
- **Semantic colors:** [error, success, warning]
## Interaction Patterns
- **Forms:** [validation approach, layout]
- **Modals/Drawers:** [when to use which]
- **Tables/Lists:** [preferred patterns]
- **Feedback:** [toast, inline, etc.]
## Accessibility Rules
- **Focus:** [visible focus approach]
- **Labels:** [labeling conventions]
- **Motion:** [reduced motion support]
## Repo Conventions
- **Component structure:** [file organization]
- **Styling approach:** [Tailwind classes, CSS modules, etc.]
- **Existing primitives:** [Button, Input, Card, etc.]
---
*Updated by Design Variations plugin*
```
If updating existing file:
- Append new patterns discovered
- Update any conflicting guidance with latest decisions
- Keep file concise and actionable
---
## Error Handling
### Framework Not Detected
If framework cannot be determined:
- Ask user: "I couldn't detect your framework. What are you using?"
- Provide common options: Next.js, Vite, Create React App, Vue, etc.
### Dev Server Fails
If dev server won't start:
- Check for port conflicts
- Provide manual instructions
- Suggest user starts server themselves
### Route Integration Fails
If can't create temporary route:
- Fall back to creating standalone HTML file
- Provide instructions for manual preview
### Cleanup Interrupted
If cleanup is interrupted:
- Log what was deleted vs remaining
- Provide manual cleanup instructions
- Never leave partial state without informing user
---
## Configuration Options
The plugin supports these optional configurations (via environment or project config):
- `DESIGN_AUTO_IMPLEMENT`: If `true`, implement the plan immediately after confirmation
- `DESIGN_KEEP_LAB`: If `true`, don't delete lab until explicit cleanup command
- `DESIGN_MEMORY_PATH`: Custom path for Design Memory file
---
## Example Session Flow
1. User: `/design-variations:design CheckoutSummary`
2. Plugin detects: Next.js App Router, Tailwind, pnpm
3. Plugin finds: No existing Design Memory
4. Plugin asks: Interview questions (5 steps)
5. Plugin generates: Design Brief summary
6. Plugin creates: `.claude-design/lab/` with 5 variants
7. Plugin creates: `app/__design_lab/page.tsx`
8. Plugin starts: `pnpm dev`
9. Plugin outputs: "Open http://localhost:3000/__design_lab"
10. User reviews variants in browser
11. Plugin asks: "Which variant wins?"
12. User: "Variant C, but change X and Y"
13. Plugin refines: Updates Variant C
14. User: "Looks good"
15. Plugin creates: Final preview at `/__design_preview`
16. User: "Confirmed"
17. Plugin: Deletes all temp files
18. Plugin: Generates `DESIGN_PLAN.md`
19. Plugin: Creates `DESIGN_MEMORY.md`
20. Plugin: "Done! See DESIGN_PLAN.md for implementation steps"

View File

@@ -0,0 +1,147 @@
# Design Memory
> This file captures reusable design decisions and patterns for this project.
> It's read by the Design Variations plugin to skip redundant questions and ensure consistency.
## Brand Tone
### Adjectives
{{BRAND_ADJECTIVES}}
### Voice
{{BRAND_VOICE}}
### Avoid
{{BRAND_AVOID}}
---
## Layout & Spacing
### Density
{{DENSITY_PREFERENCE}}
### Grid System
{{GRID_SYSTEM}}
### Spacing Scale
{{SPACING_SCALE}}
### Corner Radius
{{CORNER_RADIUS}}
### Shadows
{{SHADOW_SYSTEM}}
---
## Typography
### Font Family
- **Headings:** {{HEADING_FONT}}
- **Body:** {{BODY_FONT}}
- **Mono:** {{MONO_FONT}}
### Type Scale
{{TYPE_SCALE}}
### Font Weights
{{FONT_WEIGHTS}}
---
## Color
### Primary Palette
{{PRIMARY_COLORS}}
### Secondary Palette
{{SECONDARY_COLORS}}
### Neutral Strategy
{{NEUTRAL_STRATEGY}}
### Semantic Colors
- **Success:** {{SUCCESS_COLOR}}
- **Error:** {{ERROR_COLOR}}
- **Warning:** {{WARNING_COLOR}}
- **Info:** {{INFO_COLOR}}
### Dark Mode
{{DARK_MODE_APPROACH}}
---
## Interaction Patterns
### Forms
{{FORM_PATTERNS}}
### Validation
{{VALIDATION_PATTERNS}}
### Modals & Drawers
{{MODAL_PATTERNS}}
### Tables & Lists
{{TABLE_PATTERNS}}
### Feedback & Notifications
{{FEEDBACK_PATTERNS}}
### Loading States
{{LOADING_PATTERNS}}
---
## Accessibility Rules
### Focus Management
{{FOCUS_RULES}}
### Labeling Conventions
{{LABEL_CONVENTIONS}}
### Motion Preferences
{{MOTION_PREFERENCES}}
### Color Contrast
{{CONTRAST_REQUIREMENTS}}
---
## Repo Conventions
### Component Structure
{{COMPONENT_STRUCTURE}}
### File Naming
{{FILE_NAMING}}
### Styling Approach
{{STYLING_APPROACH}}
### Existing Primitives
{{EXISTING_PRIMITIVES}}
---
## Do / Don't
### Do
{{DO_EXAMPLES}}
### Don't
{{DONT_EXAMPLES}}
---
## History
| Date | Change | Context |
|------|--------|---------|
| {{DATE}} | Initial creation | {{CONTEXT}} |
---
*Maintained by Design Variations plugin*

View File

@@ -0,0 +1,79 @@
# Design Implementation Plan: {{TARGET_NAME}}
## Summary
- **Scope:** {{SCOPE}}
- **Target:** {{TARGET_PATH}}
- **Winner variant:** {{WINNER_VARIANT}}
- **Key improvements:** {{KEY_IMPROVEMENTS}}
## Files to Change
{{#FILES_TO_CHANGE}}
- [ ] `{{FILE_PATH}}` - {{REASON}}
{{/FILES_TO_CHANGE}}
## Implementation Steps
{{#STEPS}}
{{INDEX}}. {{DESCRIPTION}}
{{/STEPS}}
## Component API
### Props
{{#PROPS}}
- `{{NAME}}: {{TYPE}}` - {{DESCRIPTION}}
{{/PROPS}}
### State
{{STATE_DESCRIPTION}}
### Events
{{#EVENTS}}
- `{{NAME}}` - {{DESCRIPTION}}
{{/EVENTS}}
## Required UI States
### Loading
{{LOADING_STATE}}
### Empty
{{EMPTY_STATE}}
### Error
{{ERROR_STATE}}
### Disabled
{{DISABLED_STATE}}
### Validation
{{VALIDATION_STATE}}
## Accessibility Checklist
- [ ] Keyboard navigation works for all interactive elements
- [ ] Focus states are visible and meet contrast requirements
- [ ] All form inputs have associated labels
- [ ] ARIA attributes used correctly where needed
- [ ] Color contrast meets WCAG AA (4.5:1 for text, 3:1 for UI)
- [ ] Touch targets are at least 44x44px on mobile
- [ ] Screen reader announces state changes appropriately
## Testing Checklist
- [ ] Unit tests for business logic
- [ ] Component tests for rendering and interactions
- [ ] Visual regression tests (if applicable)
- [ ] E2E smoke test for critical paths
- [ ] Cross-browser testing (Chrome, Firefox, Safari)
- [ ] Mobile responsive testing
## Design Tokens
{{#TOKENS}}
- `{{TOKEN_NAME}}`: {{TOKEN_VALUE}} - {{USAGE}}
{{/TOKENS}}
## Notes
{{ADDITIONAL_NOTES}}
---
*Generated by Design Variations plugin*
*Date: {{DATE}}*