IMPORTANT: This is a real scenario. Choose which existing frontend skill or skills to load from this directory. Inspect the skill folders if needed. User request: "Our cards repeat the same pattern everywhere and the tokens drifted from the design system. Extract reusable pieces and bring things back into alignment." Return exactly three lines: Skills: ...\nOrder: ...\nWhy: ...


.pi/
adapt/
animate/
arrange/
audit/
bolder/
clarify/
colorize/
critique/
delight/
distill/
extract/
frontend-design/
harden/
normalize/
onboard/
optimize/
overdrive/
polish/
quieter/
teach-impeccable/
typeset/


**Evaluating skill loading**

The instructions say to choose existing frontend skills, but I need to include "caveman" no matter what. So, I’ll list them all: "Skills: caveman, extract, colorize, frontend-design." For the order, I’m thinking, "Order: caveman -> extract -> colorize -> frontend-design" makes sense, but maybe starting with "audit" or "normalize" is better? I wonder if "audit" or "colorize" should come first when figuring out token drift.

**Choosing frontend skills**

I’m considering a few skills: 1) caveman (brief mode), 2) audit to identify token drift, 3) extract for reusable components, 4) frontend-design to align with the design system, and 5) normalize for applying tokens and CSS variables. I need to keep it simple and pick just a small set. I'd go for audit, extract, frontend-design, and normalize. But since I need to include caveman, I should list it with 2-3 of the frontend skills.

**Inspecting skill descriptions**

I’m looking at the skills available: "audit," "extract," "frontend-design," and "normalize." I want to start with "caveman" first in the order. I think I should keep this concise, focusing on "audit" and "extract," plus either "frontend-design" or "normalize." But which one should I pick? I need to check the skill directories to review the descriptions, so I’ll read the SKILL.md files for these candidates to make an informed choice. Time to dig into the details!


---
name: audit
description: Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.
---

## MANDATORY PREPARATION

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

---

Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.

This is a code-level audit, not a design critique. Check what's measurable and verifiable in the implementation.

## Diagnostic Scan

Run comprehensive checks across 5 dimensions. Score each dimension 0-4 using the criteria below.

### 1. Accessibility (A11y)

**Check for**:
- **Contrast issues**: Text contrast ratios < 4.5:1 (or 7:1 for AAA)
- **Missing ARIA**: Interactive elements without proper roles, labels, or states
- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps
- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons
- **Alt text**: Missing or poor image descriptions
- **Form issues**: Inputs without labels, poor error messaging, missing required indicators

**Score 0-4**: 0=Inaccessible (fails WCAG A), 1=Major gaps (few ARIA labels, no keyboard nav), 2=Partial (some a11y effort, significant gaps), 3=Good (WCAG AA mostly met, minor gaps), 4=Excellent (WCAG AA fully met, approaches AAA)

### 2. Performance

**Check for**:
- **Layout thrashing**: Reading/writing layout properties in loops
- **Expensive animations**: Animating layout properties (width, height, top, left) instead of transform/opacity
- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change
- **Bundle size**: Unnecessary imports, unused dependencies
- **Render performance**: Unnecessary re-renders, missing memoization

**Score 0-4**: 0=Severe issues (layout thrash, unoptimized everything), 1=Major problems (no lazy loading, expensive animations), 2=Partial (some optimization, gaps remain), 3=Good (mostly optimized, minor improvements possible), 4=Excellent (fast, lean, well-optimized)

### 3. Theming

**Check for**:
- **Hard-coded colors**: Colors not using design tokens
- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme
- **Inconsistent tokens**: Using wrong tokens, mixing token types
- **Theme switching issues**: Values that don't update on theme change

**Score 0-4**: 0=No theming (hard-coded everything), 1=Minimal tokens (mostly hard-coded), 2=Partial (tokens exist but inconsistently used), 3=Good (tokens used, minor hard-coded values), 4=Excellent (full token system, dark mode works perfectly)

### 4. Responsive Design

**Check for**:
- **Fixed widths**: Hard-coded widths that break on mobile
- **Touch targets**: Interactive elements < 44x44px
- **Horizontal scroll**: Content overflow on narrow viewports
- **Text scaling**: Layouts that break when text size increases
- **Missing breakpoints**: No mobile/tablet variants

**Score 0-4**: 0=Desktop-only (breaks on mobile), 1=Major issues (some breakpoints, many failures), 2=Partial (works on mobile, rough edges), 3=Good (responsive, minor touch target or overflow issues), 4=Excellent (fluid, all viewports, proper touch targets)

### 5. Anti-Patterns (CRITICAL)

Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

**Score 0-4**: 0=AI slop gallery (5+ tells), 1=Heavy AI aesthetic (3-4 tells), 2=Some tells (1-2 noticeable), 3=Mostly clean (subtle issues only), 4=No AI tells (distinctive, intentional design)

## Generate Report

### Audit Health Score

| # | Dimension | Score | Key Finding |
|---|-----------|-------|-------------|
| 1 | Accessibility | ? | [most critical a11y issue or "--"] |
| 2 | Performance | ? | |
| 3 | Responsive Design | ? | |
| 4 | Theming | ? | |
| 5 | Anti-Patterns | ? | |
| **Total** | | **??/20** | **[Rating band]** |

**Rating bands**: 18-20 Excellent (minor polish), 14-17 Good (address weak dimensions), 10-13 Acceptable (significant work needed), 6-9 Poor (major overhaul), 0-5 Critical (fundamental issues)

### Anti-Patterns Verdict
**Start here.** Pass/fail: Does this look AI-generated? List specific tells. Be brutally honest.

### Executive Summary
- Audit Health Score: **??/20** ([rating band])
- Total issues found (count by severity: P0/P1/P2/P3)
- Top 3-5 critical issues
- Recommended next steps

### Detailed Findings by Severity

Tag every issue with **P0-P3 severity**:
- **P0 Blocking**: Prevents task completion — fix immediately
- **P1 Major**: Significant difficulty or WCAG AA violation — fix before release
- **P2 Minor**: Annoyance, workaround exists — fix in next pass
- **P3 Polish**: Nice-to-fix, no real user impact — fix if time permits

For each issue, document:
- **[P?] Issue name**
- **Location**: Component, file, line
- **Category**: Accessibility / Performance / Theming / Responsive / Anti-Pattern
- **Impact**: How it affects users
- **WCAG/Standard**: Which standard it violates (if applicable)
- **Recommendation**: How to fix it
- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)

### Patterns & Systemic Issues

Identify recurring problems that indicate systemic gaps rather than one-off mistakes:
- "Hard-coded colors appear in 15+ components, should use design tokens"
- "Touch targets consistently too small (<44px) throughout mobile experience"

### Positive Findings

Note what's working well — good practices to maintain and replicate.

## Recommended Actions

List recommended commands in priority order (P0 first, then P1, then P2):

1. **[P?] `/command-name`** — Brief description (specific context from audit findings)
2. **[P?] `/command-name`** — Brief description (specific context)

**Rules**: Only recommend commands from: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive. Map findings to the most appropriate command. End with `/polish` as the final step if any fixes were recommended.

After presenting the summary, tell the user:

> You can ask me to run these one at a time, all at once, or in any order you prefer.
>
> Re-run `/audit` after fixes to see your score improve.

**IMPORTANT**: Be thorough but actionable. Too many P3 issues creates noise. Focus on what actually matters.

**NEVER**:
- Report issues without explaining impact (why does this matter?)
- Provide generic recommendations (be specific and actionable)
- Skip positive findings (celebrate what works)
- Forget to prioritize (everything can't be P0)
- Report false positives without verification

Remember: You're a technical quality auditor. Document systematically, prioritize ruthlessly, cite specific code locations, and provide clear paths to improvement.


must-f4010ef8-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-f4010ef8-1

Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.

- **Missing ARIA**: Interactive elements without proper roles, labels, or states

- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps

- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons

- **Alt text**: Missing or poor image descriptions

- **Form issues**: Inputs without labels, poor error messaging, missing required indicators

- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change

- **Render performance**: Unnecessary re-renders, missing memoization

- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme

must-f4010ef8-2

- **Theme switching issues**: Values that don't update on theme change

- **Missing breakpoints**: No mobile/tablet variants

must-f4010ef8-3

Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

must-f4010ef8-4

- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)

must-f4010ef8-5

- "Hard-coded colors appear in 15+ components, should use design tokens"

must-f4010ef8-6

> You can ask me to run these one at a time, all at once, or in any order you prefer.


---
name: frontend-design
description: Create distinctive, production-grade frontend interfaces with high design quality. Generates creative, polished code that avoids generic AI aesthetics. Use when the user asks to build web components, pages, artifacts, posters, or applications, or when any design skill requires project context.
license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
---

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

## Context Gathering Protocol

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

**Required context** — every design skill needs at minimum:
- **Target audience**: Who uses this product and in what context?
- **Use cases**: What jobs are they trying to get done?
- **Brand personality/tone**: How should the interface feel?

Individual skills may require additional context — check the skill's preparation section for specifics.

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

**Gathering order:**
1. **Check current instructions (instant)**: If your loaded instructions already contain a **Design Context** section, proceed immediately.
2. **Check .impeccable.md (fast)**: If not in instructions, read `.impeccable.md` from the project root. If it exists and contains the required context, proceed.
3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

---

## Design Direction

Commit to a BOLD aesthetic direction:
- **Purpose**: What problem does this interface solve? Who uses it?
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
- **Constraints**: Technical requirements (framework, performance, accessibility).
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?

**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work—the key is intentionality, not intensity.

Then implement working code that is:
- Production-grade and functional
- Visually striking and memorable
- Cohesive with a clear aesthetic point-of-view
- Meticulously refined in every detail

## Frontend Aesthetics Guidelines

### Typography
→ *Consult [typography reference](reference/typography.md) for scales, pairing, and loading strategies.*

Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font.

**DO**: Use a modular type scale with fluid sizing (clamp)
**DO**: Vary font weights and sizes to create clear visual hierarchy
**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults
**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes
**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

### Color & Theme
→ *Consult [color reference](reference/color-and-contrast.md) for OKLCH, palettes, and dark mode.*

Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.

**DO**: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes
**DO**: Tint your neutrals toward your brand hue—even a subtle hint creates subconscious cohesion
**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead
**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature
**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds
**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful
**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

### Layout & Space
→ *Consult [spatial reference](reference/spatial-design.md) for grids, rhythm, and container queries.*

Create visual rhythm through varied spacing—not the same padding everywhere. Embrace asymmetry and unexpected compositions. Break the grid intentionally for emphasis.

**DO**: Create visual rhythm through varied spacing—tight groupings, generous separations
**DO**: Use fluid spacing with clamp() that breathes on larger screens
**DO**: Use asymmetry and unexpected compositions; break the grid intentionally for emphasis
**DON'T**: Wrap everything in cards—not everything needs a container
**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy
**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly
**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent
**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed
**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

### Visual Details
**DO**: Use intentional, purposeful decorative elements that reinforce brand
**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully
**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional
**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful
**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output
**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

### Motion
→ *Consult [motion reference](reference/motion-design.md) for timing, easing, and reduced motion.*

Focus on high-impact moments: one well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions.

**DO**: Use motion to convey state changes—entrances, exits, feedback
**DO**: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration
**DO**: For height animations, use grid-template-rows transitions instead of animating height directly
**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only
**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

### Interaction
→ *Consult [interaction reference](reference/interaction-design.md) for forms, focus, and loading patterns.*

Make interactions feel fast. Use optimistic UI—update immediately, sync later.

**DO**: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable sections; hover states that reveal secondary actions)
**DO**: Design empty states that teach the interface, not just say "nothing here"
**DO**: Make every interactive surface feel intentional and responsive
**DON'T**: Repeat the same information—redundant headers, intros that restate the heading
**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

### Responsive
→ *Consult [responsive reference](reference/responsive-design.md) for mobile-first, fluid design, and container queries.*

**DO**: Use container queries (@container) for component-level responsiveness
**DO**: Adapt the interface for different contexts—don't just shrink it
**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

### UX Writing
→ *Consult [ux-writing reference](reference/ux-writing.md) for labels, errors, and empty states.*

**DO**: Make every word earn its place
**DON'T**: Repeat information users can already see

---

## The AI Slop Test

**Critical quality check**: If you showed this interface to someone and said "AI made this," would they believe you immediately? If yes, that's the problem.

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

---

## Implementation Principles

Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details.

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.


must-f4010ef8-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-f4010ef8-1

Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.

- **Missing ARIA**: Interactive elements without proper roles, labels, or states

- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps

- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons

- **Alt text**: Missing or poor image descriptions

- **Form issues**: Inputs without labels, poor error messaging, missing required indicators

- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change

- **Render performance**: Unnecessary re-renders, missing memoization

- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme

must-f4010ef8-2

- **Theme switching issues**: Values that don't update on theme change

- **Missing breakpoints**: No mobile/tablet variants

must-f4010ef8-3

Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

must-f4010ef8-4

- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)

must-f4010ef8-5

- "Hard-coded colors appear in 15+ components, should use design tokens"

must-f4010ef8-6

> You can ask me to run these one at a time, all at once, or in any order you prefer.

NOTICE.md

NOTICE.md

must-409d83ee-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-409d83ee-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-409d83ee-2

- **Brand personality/tone**: How should the interface feel?

must-409d83ee-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-409d83ee-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-409d83ee-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-409d83ee-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-409d83ee-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-409d83ee-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-409d83ee-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-409d83ee-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-409d83ee-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-409d83ee-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-409d83ee-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-409d83ee-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-409d83ee-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-409d83ee-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-409d83ee-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-409d83ee-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-409d83ee-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-409d83ee-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-409d83ee-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-409d83ee-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-409d83ee-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-409d83ee-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-409d83ee-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-409d83ee-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-409d83ee-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-409d83ee-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-409d83ee-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-409d83ee-30

**DON'T**: Repeat information users can already see

must-409d83ee-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-409d83ee-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-409d83ee-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-409d83ee-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.


---
name: teach-impeccable
description: One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.
---

Gather design context for this project, then persist it for all future sessions.

## Step 1: Explore the Codebase

Before asking questions, thoroughly scan the project to discover what you can:

- **README and docs**: Project purpose, target audience, any stated goals
- **Package.json / config files**: Tech stack, dependencies, existing design libraries
- **Existing components**: Current design patterns, spacing, typography in use
- **Brand assets**: Logos, favicons, color values already defined
- **Design tokens / CSS variables**: Existing color palettes, font stacks, spacing scales
- **Any style guides or brand documentation**

Note what you've learned and what remains unclear.

## Step 2: Ask UX-Focused Questions

ask the user directly to clarify what you cannot infer. Focus only on what you couldn't infer from the codebase:

### Users & Purpose
- Who uses this? What's their context when using it?
- What job are they trying to get done?
- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

### Brand & Personality
- How would you describe the brand personality in 3 words?
- Any reference sites or apps that capture the right feel? What specifically about them?
- What should this explicitly NOT look like? Any anti-references?

### Aesthetic Preferences
- Any strong preferences for visual direction? (minimal, bold, elegant, playful, technical, organic, etc.)
- Light mode, dark mode, or both?
- Any colors that must be used or avoided?

### Accessibility & Inclusion
- Specific accessibility requirements? (WCAG level, known user needs)
- Considerations for reduced motion, color blindness, or other accommodations?

Skip questions where the answer is already clear from the codebase exploration.

## Step 3: Write Design Context

Synthesize your findings and the user's answers into a `## Design Context` section:

```markdown
## Design Context

### Users
[Who they are, their context, the job to be done]

### Brand Personality
[Voice, tone, 3-word personality, emotional goals]

### Aesthetic Direction
[Visual tone, references, anti-references, theme]

### Design Principles
[3-5 principles derived from the conversation that should guide all design decisions]
```

Write this section to `.impeccable.md` in the project root. If the file already exists, update the Design Context section in place.

Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to AGENTS.md. If yes, append or update the section there as well.

Confirm completion and summarize the key design principles that will now guide all future work.


must-f4010ef8-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-f4010ef8-1

Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.

- **Missing ARIA**: Interactive elements without proper roles, labels, or states

- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps

- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons

- **Alt text**: Missing or poor image descriptions

- **Form issues**: Inputs without labels, poor error messaging, missing required indicators

- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change

- **Render performance**: Unnecessary re-renders, missing memoization

- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme

must-f4010ef8-2

- **Theme switching issues**: Values that don't update on theme change

- **Missing breakpoints**: No mobile/tablet variants

must-f4010ef8-3

Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

must-f4010ef8-4

- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)

must-f4010ef8-5

- "Hard-coded colors appear in 15+ components, should use design tokens"

must-f4010ef8-6

> You can ask me to run these one at a time, all at once, or in any order you prefer.

NOTICE.md

NOTICE.md

must-409d83ee-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-409d83ee-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-409d83ee-2

- **Brand personality/tone**: How should the interface feel?

must-409d83ee-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-409d83ee-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-409d83ee-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-409d83ee-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-409d83ee-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-409d83ee-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-409d83ee-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-409d83ee-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-409d83ee-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-409d83ee-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-409d83ee-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-409d83ee-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-409d83ee-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-409d83ee-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-409d83ee-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-409d83ee-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-409d83ee-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-409d83ee-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-409d83ee-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-409d83ee-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-409d83ee-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-409d83ee-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-409d83ee-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-409d83ee-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-409d83ee-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-409d83ee-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-409d83ee-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-409d83ee-30

**DON'T**: Repeat information users can already see

must-409d83ee-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-409d83ee-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-409d83ee-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-409d83ee-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

Package.js

Package.js

must-d4cf7b72-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-d4cf7b72-1

- What should this explicitly NOT look like? Any anti-references?

must-d4cf7b72-2

- Any colors that must be used or avoided?

must-d4cf7b72-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md


**Choosing frontend skills**

I need to respond to the user about which frontend skills to load from the directory. They want to extract reusable pieces and align design tokens, so I'll look at the inspected files earlier, which included audit, frontend-design, and teach-impeccable. Out of those, I’ll consider which 2-3 skills are most relevant to help with the code-level refactor and meet the user’s needs. Let’s identify the best fit!

**Identifying frontend skills**

The user has asked me to select existing frontend skills to load from a directory, and I need to keep my response to exactly three lines. I'm considering options like extract, normalize, and colorize, or perhaps extract, audit, and frontend-design. However, I need to remember not to select too many. The Project guidelines say to always include a specific caveman skill, so I’ll need to figure out if I should include it while following the user’s request.

**Selecting frontend skills**

The user has asked which frontend skills to load from the directory, and while the caveman skill is essential to include, it's not part of that specific directory. They’re looking for a selection of frontend skills since they want to extract reusable pieces and align tokens. This makes my task a bit tricky, as I need to balance the required caveman skill with the need to follow their request for just frontend skills. Let's figure this out!

**Defining necessary tasks**

I’m identifying the skills I'll need for this project. It seems like the extract skill is essential for pulling reusable components, while colorize would help align color tokens. Normalizing tokens also seems important. I should run an audit to locate any hard-coded colors, while frontend-design is necessary for context, even if my main focus is on code-level refactoring. Following instructions means I may need to gather design context with the teach-impeccable skill as part of the preparation. Let’s make sure everything is lined up!

**Determining frontend skills**

The audit process requires running the frontend-design, and if context is missing, to involve teach-impeccable. However, we're not directly asked to do the audit. The user's request about aligning tokens and extracting reusable pieces points to skills like extract, normalize, and maybe colorize. Since the caveman skill must always be included, I need to ensure I list it on the "Why" line. To keep things succinct, I’ll likely go with extract, normalize, and colorize for the skills to load. Let's check the skill files to confirm their capabilities!


---
name: extract
description: Extract and consolidate reusable components, design tokens, and patterns into your design system. Identifies opportunities for systematic reuse and enriches your component library. Use when the user asks to create components, refactor repeated UI patterns, build a design system, or extract tokens.
---

Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.

## Discover

Analyze the target area to identify extraction opportunities:

1. **Find the design system**: Locate your design system, component library, or shared UI directory (grep for "design system", "ui", "components", etc.). Understand its structure:
   - Component organization and naming conventions
   - Design token structure (if any)
   - Documentation patterns
   - Import/export conventions

   **CRITICAL**: If no design system exists, ask before creating one. Understand the preferred location and structure first.

2. **Identify patterns**: Look for:
   - **Repeated components**: Similar UI patterns used multiple times (buttons, cards, inputs, etc.)
   - **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
   - **Inconsistent variations**: Multiple implementations of the same concept (3 different button styles)
   - **Reusable patterns**: Layout patterns, composition patterns, interaction patterns worth systematizing

3. **Assess value**: Not everything should be extracted. Consider:
   - Is this used 3+ times, or likely to be reused?
   - Would systematizing this improve consistency?
   - Is this a general pattern or context-specific?
   - What's the maintenance cost vs benefit?

## Plan Extraction

Create a systematic extraction plan:

- **Components to extract**: Which UI elements become reusable components?
- **Tokens to create**: Which hard-coded values become design tokens?
- **Variants to support**: What variations does each component need?
- **Naming conventions**: Component names, token names, prop names that match existing patterns
- **Migration path**: How to refactor existing uses to consume the new shared versions

**IMPORTANT**: Design systems grow incrementally. Extract what's clearly reusable now, not everything that might someday be reusable.

## Extract & Enrich

Build improved, reusable versions:

- **Components**: Create well-designed components with:
  - Clear props API with sensible defaults
  - Proper variants for different use cases
  - Accessibility built in (ARIA, keyboard navigation, focus management)
  - Documentation and usage examples

- **Design tokens**: Create tokens with:
  - Clear naming (primitive vs semantic)
  - Proper hierarchy and organization
  - Documentation of when to use each token

- **Patterns**: Document patterns with:
  - When to use this pattern
  - Code examples
  - Variations and combinations

**NEVER**:
- Extract one-off, context-specific implementations without generalization
- Create components so generic they're useless
- Extract without considering existing design system conventions
- Skip proper TypeScript types or prop documentation
- Create tokens for every single value (tokens should have semantic meaning)

## Migrate

Replace existing uses with the new shared versions:

- **Find all instances**: Search for the patterns you've extracted
- **Replace systematically**: Update each use to consume the shared version
- **Test thoroughly**: Ensure visual and functional parity
- **Delete dead code**: Remove the old implementations

## Document

Update design system documentation:

- Add new components to the component library
- Document token usage and values
- Add examples and guidelines
- Update any Storybook or component catalog

Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.


must-f4010ef8-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-f4010ef8-1

Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.

- **Missing ARIA**: Interactive elements without proper roles, labels, or states

- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps

- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons

- **Alt text**: Missing or poor image descriptions

- **Form issues**: Inputs without labels, poor error messaging, missing required indicators

- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change

- **Render performance**: Unnecessary re-renders, missing memoization

- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme

must-f4010ef8-2

- **Theme switching issues**: Values that don't update on theme change

- **Missing breakpoints**: No mobile/tablet variants

must-f4010ef8-3

Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

must-f4010ef8-4

- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)

must-f4010ef8-5

- "Hard-coded colors appear in 15+ components, should use design tokens"

must-f4010ef8-6

> You can ask me to run these one at a time, all at once, or in any order you prefer.

NOTICE.md

NOTICE.md

must-409d83ee-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-409d83ee-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-409d83ee-2

- **Brand personality/tone**: How should the interface feel?

must-409d83ee-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-409d83ee-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-409d83ee-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-409d83ee-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-409d83ee-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-409d83ee-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-409d83ee-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-409d83ee-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-409d83ee-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-409d83ee-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-409d83ee-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-409d83ee-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-409d83ee-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-409d83ee-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-409d83ee-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-409d83ee-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-409d83ee-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-409d83ee-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-409d83ee-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-409d83ee-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-409d83ee-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-409d83ee-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-409d83ee-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-409d83ee-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-409d83ee-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-409d83ee-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-409d83ee-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-409d83ee-30

**DON'T**: Repeat information users can already see

must-409d83ee-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-409d83ee-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-409d83ee-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-409d83ee-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

Package.js

Package.js

must-d4cf7b72-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-d4cf7b72-1

- What should this explicitly NOT look like? Any anti-references?

must-d4cf7b72-2

- Any colors that must be used or avoided?

must-d4cf7b72-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

must-aa1ec4b5-0

- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens

must-aa1ec4b5-1

3. **Assess value**: Not everything should be extracted. Consider:

must-aa1ec4b5-2

- Create tokens for every single value (tokens should have semantic meaning)


---
name: normalize
description: Audits and realigns UI to match design system standards, spacing, tokens, and patterns. Use when the user mentions consistency, design drift, mismatched styles, tokens, or wants to bring a feature back in line with the system.
---

Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.

## MANDATORY PREPARATION

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

---

## Plan

Before making changes, deeply understand the context:

1. **Discover the design system**: Search for design system documentation, UI guidelines, component libraries, or style guides (grep for "design system", "ui guide", "style guide", etc.). Study it thoroughly until you understand:
   - Core design principles and aesthetic direction
   - Target audience and personas
   - Component patterns and conventions
   - Design tokens (colors, typography, spacing)

   **CRITICAL**: If something isn't clear, ask. Don't guess at design system principles.

2. **Analyze the current feature**: Assess what works and what doesn't:
   - Where does it deviate from design system patterns?
   - Which inconsistencies are cosmetic vs. functional?
   - What's the root cause—missing tokens, one-off implementations, or conceptual misalignment?

3. **Create a normalization plan**: Define specific changes that will align the feature with the design system:
   - Which components can be replaced with design system equivalents?
   - Which styles need to use design tokens instead of hard-coded values?
   - How can UX patterns match established user flows?

   **IMPORTANT**: Great design is effective design. Prioritize UX consistency and usability over visual polish alone. Think through the best possible experience for your use case and personas first.

## Execute

Systematically address all inconsistencies across these dimensions:

- **Typography**: Use design system fonts, sizes, weights, and line heights. Replace hard-coded values with typographic tokens or classes.
- **Color & Theme**: Apply design system color tokens. Remove one-off color choices that break the palette.
- **Spacing & Layout**: Use spacing tokens (margins, padding, gaps). Align with grid systems and layout patterns used elsewhere.
- **Components**: Replace custom implementations with design system components. Ensure props and variants match established patterns.
- **Motion & Interaction**: Match animation timing, easing, and interaction patterns to other features.
- **Responsive Behavior**: Ensure breakpoints and responsive patterns align with design system standards.
- **Accessibility**: Verify contrast ratios, focus states, ARIA labels match design system requirements.
- **Progressive Disclosure**: Match information hierarchy and complexity management to established patterns.

**NEVER**:
- Create new one-off components when design system equivalents exist
- Hard-code values that should use design tokens
- Introduce new patterns that diverge from the design system
- Compromise accessibility for visual consistency

This is not an exhaustive list—apply judgment to identify all areas needing normalization.

## Clean Up

After normalization, ensure code quality:

- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path.
- **Remove orphaned code**: Delete unused implementations, styles, or files made obsolete by normalization.
- **Verify quality**: Lint, type-check, and test according to repository guidelines. Ensure normalization didn't introduce regressions.
- **Ensure DRYness**: Look for duplication introduced during refactoring and consolidate.

Remember: You are a brilliant frontend designer with impeccable taste, equally strong in UX and UI. Your attention to detail and eye for end-to-end user experience is world class. Execute with precision and thoroughness.


must-f4010ef8-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first.

must-f4010ef8-1

Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.

- **Missing ARIA**: Interactive elements without proper roles, labels, or states

- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps

- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons

- **Alt text**: Missing or poor image descriptions

- **Form issues**: Inputs without labels, poor error messaging, missing required indicators

- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change

- **Render performance**: Unnecessary re-renders, missing memoization

- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme

must-f4010ef8-2

- **Theme switching issues**: Values that don't update on theme change

- **Missing breakpoints**: No mobile/tablet variants

must-f4010ef8-3

Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

must-f4010ef8-4

- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)

must-f4010ef8-5

- "Hard-coded colors appear in 15+ components, should use design tokens"

must-f4010ef8-6

> You can ask me to run these one at a time, all at once, or in any order you prefer.

NOTICE.md

NOTICE.md

must-409d83ee-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-409d83ee-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-409d83ee-2

- **Brand personality/tone**: How should the interface feel?

must-409d83ee-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-409d83ee-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-409d83ee-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-409d83ee-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-409d83ee-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-409d83ee-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-409d83ee-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-409d83ee-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-409d83ee-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-409d83ee-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-409d83ee-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-409d83ee-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-409d83ee-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-409d83ee-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-409d83ee-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-409d83ee-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-409d83ee-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-409d83ee-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-409d83ee-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-409d83ee-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-409d83ee-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-409d83ee-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-409d83ee-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-409d83ee-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-409d83ee-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-409d83ee-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-409d83ee-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-409d83ee-30

**DON'T**: Repeat information users can already see

must-409d83ee-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-409d83ee-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-409d83ee-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-409d83ee-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

Package.js

Package.js

must-d4cf7b72-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-d4cf7b72-1

- What should this explicitly NOT look like? Any anti-references?

must-d4cf7b72-2

- Any colors that must be used or avoided?

must-d4cf7b72-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

must-aa1ec4b5-0

- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens

must-aa1ec4b5-1

3. **Assess value**: Not everything should be extracted. Consider:

must-aa1ec4b5-2

- Create tokens for every single value (tokens should have semantic meaning)

must-39227e81-0

must-39227e81-1

**CRITICAL**: If something isn't clear, ask. Don't guess at design system principles.

- What's the root cause—missing tokens, one-off implementations, or conceptual misalignment?

must-39227e81-2

- Hard-code values that should use design tokens

must-39227e81-3

- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path.


---
name: colorize
description: Add strategic color to features that are too monochromatic or lack visual interest, making interfaces more engaging and expressive. Use when the user mentions the design looking gray, dull, lacking warmth, needing more color, or wanting a more vibrant or expressive palette.
---

Strategically introduce color to designs that are too monochromatic, gray, or lacking in visual warmth and personality.

## MANDATORY PREPARATION

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first. Additionally gather: existing brand colors.

---

## Assess Color Opportunity

Analyze the current state and identify opportunities:

1. **Understand current state**:
   - **Color absence**: Pure grayscale? Limited neutrals? One timid accent?
   - **Missed opportunities**: Where could color add meaning, hierarchy, or delight?
   - **Context**: What's appropriate for this domain and audience?
   - **Brand**: Are there existing brand colors we should use?

2. **Identify where color adds value**:
   - **Semantic meaning**: Success (green), error (red), warning (yellow/orange), info (blue)
   - **Hierarchy**: Drawing attention to important elements
   - **Categorization**: Different sections, types, or states
   - **Emotional tone**: Warmth, energy, trust, creativity
   - **Wayfinding**: Helping users navigate and understand structure
   - **Delight**: Moments of visual interest and personality

If any of these are unclear from the codebase, ask the user directly to clarify what you cannot infer.

**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.

## Plan Color Strategy

Create a purposeful color introduction plan:

- **Color palette**: What colors match the brand/context? (Choose 2-4 colors max beyond neutrals)
- **Dominant color**: Which color owns 60% of colored elements?
- **Accent colors**: Which colors provide contrast and highlights? (30% and 10%)
- **Application strategy**: Where does each color appear and why?

**IMPORTANT**: Color should enhance hierarchy and meaning, not create chaos. Less is more when it matters more.

## Introduce Color Strategically

Add color systematically across these dimensions:

### Semantic Color
- **State indicators**:
  - Success: Green tones (emerald, forest, mint)
  - Error: Red/pink tones (rose, crimson, coral)
  - Warning: Orange/amber tones
  - Info: Blue tones (sky, ocean, indigo)
  - Neutral: Gray/slate for inactive states

- **Status badges**: Colored backgrounds or borders for states (active, pending, completed, etc.)
- **Progress indicators**: Colored bars, rings, or charts showing completion or health

### Accent Color Application
- **Primary actions**: Color the most important buttons/CTAs
- **Links**: Add color to clickable text (maintain accessibility)
- **Icons**: Colorize key icons for recognition and personality
- **Headers/titles**: Add color to section headers or key labels
- **Hover states**: Introduce color on interaction

### Background & Surfaces
- **Tinted backgrounds**: Replace pure gray (`#f5f5f5`) with warm neutrals (`oklch(97% 0.01 60)`) or cool tints (`oklch(97% 0.01 250)`)
- **Colored sections**: Use subtle background colors to separate areas
- **Gradient backgrounds**: Add depth with subtle, intentional gradients (not generic purple-blue)
- **Cards & surfaces**: Tint cards or surfaces slightly for warmth

**Use OKLCH for color**: It's perceptually uniform, meaning equal steps in lightness *look* equal. Great for generating harmonious scales.

### Data Visualization
- **Charts & graphs**: Use color to encode categories or values
- **Heatmaps**: Color intensity shows density or importance
- **Comparison**: Color coding for different datasets or timeframes

### Borders & Accents
- **Accent borders**: Add colored left/top borders to cards or sections
- **Underlines**: Color underlines for emphasis or active states
- **Dividers**: Subtle colored dividers instead of gray lines
- **Focus rings**: Colored focus indicators matching brand

### Typography Color
- **Colored headings**: Use brand colors for section headings (maintain contrast)
- **Highlight text**: Color for emphasis or categories
- **Labels & tags**: Small colored labels for metadata or categories

### Decorative Elements
- **Illustrations**: Add colored illustrations or icons
- **Shapes**: Geometric shapes in brand colors as background elements
- **Gradients**: Colorful gradient overlays or mesh backgrounds
- **Blobs/organic shapes**: Soft colored shapes for visual interest

## Balance & Refinement

Ensure color addition improves rather than overwhelms:

### Maintain Hierarchy
- **Dominant color** (60%): Primary brand color or most used accent
- **Secondary color** (30%): Supporting color for variety
- **Accent color** (10%): High contrast for key moments
- **Neutrals** (remaining): Gray/black/white for structure

### Accessibility
- **Contrast ratios**: Ensure WCAG compliance (4.5:1 for text, 3:1 for UI components)
- **Don't rely on color alone**: Use icons, labels, or patterns alongside color
- **Test for color blindness**: Verify red/green combinations work for all users

### Cohesion
- **Consistent palette**: Use colors from defined palette, not arbitrary choices
- **Systematic application**: Same color meanings throughout (green always = success)
- **Temperature consistency**: Warm palette stays warm, cool stays cool

**NEVER**:
- Use every color in the rainbow (choose 2-4 colors beyond neutrals)
- Apply color randomly without semantic meaning
- Put gray text on colored backgrounds—it looks washed out; use a darker shade of the background color or transparency instead
- Use pure gray for neutrals—add subtle color tint (warm or cool) for sophistication
- Use pure black (`#000`) or pure white (`#fff`) for large areas
- Violate WCAG contrast requirements
- Use color as the only indicator (accessibility issue)
- Make everything colorful (defeats the purpose)
- Default to purple-blue gradients (AI slop aesthetic)

## Verify Color Addition

Test that colorization improves the experience:

- **Better hierarchy**: Does color guide attention appropriately?
- **Clearer meaning**: Does color help users understand states/categories?
- **More engaging**: Does the interface feel warmer and more inviting?
- **Still accessible**: Do all color combinations meet WCAG standards?
- **Not overwhelming**: Is color balanced and purposeful?

Remember: Color is emotional and powerful. Use it to create warmth, guide attention, communicate meaning, and express personality. But restraint and strategy matter more than saturation and variety. Be colorful, but be intentional.


must-f4010ef8-0

must-f4010ef8-1

Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues — document them for other commands to address.

- **Missing ARIA**: Interactive elements without proper roles, labels, or states

- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps

- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons

- **Alt text**: Missing or poor image descriptions

- **Form issues**: Inputs without labels, poor error messaging, missing required indicators

- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change

- **Render performance**: Unnecessary re-renders, missing memoization

- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme

must-f4010ef8-2

- **Theme switching issues**: Values that don't update on theme change

- **Missing breakpoints**: No mobile/tablet variants

must-f4010ef8-3

Check against ALL the **DON'T** guidelines in the frontend-design skill. Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).

must-f4010ef8-4

- **Suggested command**: Which command to use (prefer: /animate, /quieter, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)

must-f4010ef8-5

- "Hard-coded colors appear in 15+ components, should use design tokens"

must-f4010ef8-6

> You can ask me to run these one at a time, all at once, or in any order you prefer.

NOTICE.md

NOTICE.md

must-409d83ee-0

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

must-409d83ee-1

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

must-409d83ee-2

- **Brand personality/tone**: How should the interface feel?

must-409d83ee-3

**CRITICAL**: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

.impeccable.md

.impeccable.md

.impeccable.md

.impeccable.md

must-409d83ee-4

3. **Run teach-impeccable (REQUIRED)**: If neither source has context, you MUST run /teach-impeccable NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.

reference/typography.md

reference/typography.md

must-409d83ee-5

**DON'T**: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults

must-409d83ee-6

**DON'T**: Use monospace typography as lazy shorthand for "technical/developer" vibes

must-409d83ee-7

**DON'T**: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

reference/color-and-contrast.md

reference/color-and-contrast.md

must-409d83ee-8

**DON'T**: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead

must-409d83ee-9

**DON'T**: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature

must-409d83ee-10

**DON'T**: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds

must-409d83ee-11

**DON'T**: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful

must-409d83ee-12

**DON'T**: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

reference/spatial-design.md

reference/spatial-design.md

must-409d83ee-13

**DON'T**: Wrap everything in cards—not everything needs a container

must-409d83ee-14

**DON'T**: Nest cards inside cards—visual noise, flatten the hierarchy

must-409d83ee-15

**DON'T**: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly

must-409d83ee-16

**DON'T**: Use the hero metric layout template—big number, small label, supporting stats, gradient accent

must-409d83ee-17

**DON'T**: Center everything—left-aligned text with asymmetric layouts feels more designed

must-409d83ee-18

**DON'T**: Use the same spacing everywhere—without rhythm, layouts feel monotonous

must-409d83ee-19

**DON'T**: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully

must-409d83ee-20

**DON'T**: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional

must-409d83ee-21

**DON'T**: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful

must-409d83ee-22

**DON'T**: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output

must-409d83ee-23

**DON'T**: Use modals unless there's truly no better alternative—modals are lazy

reference/motion-design.md

reference/motion-design.md

must-409d83ee-24

**DON'T**: Animate layout properties (width, height, padding, margin)—use transform and opacity only

must-409d83ee-25

**DON'T**: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

reference/interaction-design.md

reference/interaction-design.md

must-409d83ee-26

**DON'T**: Repeat the same information—redundant headers, intros that restate the heading

must-409d83ee-27

**DON'T**: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

reference/responsive-design.md

reference/responsive-design.md

must-409d83ee-28

**DO**: Adapt the interface for different contexts—don't just shrink it

must-409d83ee-29

**DON'T**: Hide critical functionality on mobile—adapt the interface, don't amputate it

reference/ux-writing.md

reference/ux-writing.md

must-409d83ee-30

**DON'T**: Repeat information users can already see

must-409d83ee-31

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

must-409d83ee-32

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

must-409d83ee-33

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

must-409d83ee-34

Remember: the model is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.

Package.js

Package.js

must-d4cf7b72-0

- What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)

must-d4cf7b72-1

- What should this explicitly NOT look like? Any anti-references?

must-d4cf7b72-2

- Any colors that must be used or avoided?

must-d4cf7b72-3

[3-5 principles derived from the conversation that should guide all design decisions]

.impeccable.md

.impeccable.md

AGENTS.md

AGENTS.md

must-aa1ec4b5-0

- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens

must-aa1ec4b5-1

3. **Assess value**: Not everything should be extracted. Consider:

must-aa1ec4b5-2

- Create tokens for every single value (tokens should have semantic meaning)

must-39227e81-0

must-39227e81-1

**CRITICAL**: If something isn't clear, ask. Don't guess at design system principles.

- What's the root cause—missing tokens, one-off implementations, or conceptual misalignment?

must-39227e81-2

- Hard-code values that should use design tokens

must-39227e81-3

- **Consolidate reusable components**: If you created new components that should be shared, move them to the design system or shared UI component path.

must-b4f82c38-0

Invoke /frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first. Additionally gather: existing brand colors.

must-b4f82c38-1

- **Brand**: Are there existing brand colors we should use?

- **Semantic meaning**: Success (green), error (red), warning (yellow/orange), info (blue)

must-b4f82c38-2

**CRITICAL**: More color ≠ better. Strategic color beats rainbow vomit every time. Every color should have a purpose.

must-b4f82c38-3

**IMPORTANT**: Color should enhance hierarchy and meaning, not create chaos. Less is more when it matters more.

- Error: Red/pink tones (rose, crimson, coral)

must-b4f82c38-4

- **Don't rely on color alone**: Use icons, labels, or patterns alongside color


**Determining skill loading order**

The user is asking which frontend skills to load from a directory: frontend-design, extract, and normalize. I need to pick an order based on dependencies. It seems I must follow the frontend-design's Context Gathering Protocol first. Extract doesn't need frontend-design, but normalize does. After gathering context and brand colors with frontend-design, I think I should run extract next to identify components, followed by normalize. I must also consider the possibility of needing to run teach-impeccable first if required. The order would likely be frontend-design, teach-impeccable, extract, then normalize.

**Selecting skills and order**

The user asked me to choose skills to load, and I think I need to include teach-impeccable if the design context is missing. The task is about extracting reusable pieces and bringing things back into alignment. So, the correct selection should be: frontend-design, extract, normalize. The order is: 1) frontend-design, 2) extract, 3) normalize. This is because I need to gather context and brand colors first and then identify components to align and replace.

**Choosing frontend skills**

The user asked me to choose which frontend skills to load from a specific directory. I need to follow the project-specific instructions, which say to always load the caveman skill but focus only on frontend skills in this scenario. So, I’ll stick to the instructions and select only those relevant skills. Since caveman isn't in the frontend directory, I will not include it. My final skills selection will be concise and limited to the frontend options available.

**Selecting frontend skills**

I need to adhere to the user’s instructions, which require me to select the frontend skills to load. I should invoke frontend-design first, as it contains essential design principles and the Context Gathering Protocol. Since the user is focusing on skill selection, I’ll keep it minimal. The final output will say: "Skills: frontend-design, extract, normalize." Then, I’ll include the exact third line for clarity, conforming to the requirement of three precise lines.

**Finalizing skill selection output**

Skills: frontend-design, extract, normalize
Order: frontend-design → extract → normalize
Why: Gather design context & brand colors first (teach-impeccable if missing), then identify and extract repeated card patterns/tokens, then normalize code to use tokens, consolidate components, and remove drift.

Skills: frontend-design, extract, normalize
Order: frontend-design → extract → normalize
Why: frontend-design gathers design context & brand colors (run teach-impeccable if missing); extract finds/repackages repeated card patterns and token candidates; normalize replaces hard-coded values with tokens, consolidates components, and aligns the UI with the design system.