diff --git a/.agents/skills/audit/SKILL.md b/.agents/skills/audit/SKILL.md
index 313959a02..1bbcb2693 100644
--- a/.agents/skills/audit/SKILL.md
+++ b/.agents/skills/audit/SKILL.md
@@ -108,7 +108,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -127,7 +127,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.agents/skills/critique/SKILL.md b/.agents/skills/critique/SKILL.md
index eba93446f..080a2b594 100644
--- a/.agents/skills/critique/SKILL.md
+++ b/.agents/skills/critique/SKILL.md
@@ -143,7 +143,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -208,7 +208,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.agents/skills/extract/SKILL.md b/.agents/skills/extract/SKILL.md
deleted file mode 100644
index 4b57ea396..000000000
--- a/.agents/skills/extract/SKILL.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[target]"
----
-
-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.
\ No newline at end of file
diff --git a/.agents/skills/frontend-design/SKILL.md b/.agents/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.agents/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.agents/skills/harden/SKILL.md b/.agents/skills/harden/SKILL.md
index d870ddd13..95c9d6366 100644
--- a/.agents/skills/harden/SKILL.md
+++ b/.agents/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 user-invocable: true
 argument-hint: "[target]"
 ---
@@ -224,6 +224,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.agents/skills/impeccable/SKILL.md b/.agents/skills/impeccable/SKILL.md
index e6ee18bd6..3b1b41484 100644
--- a/.agents/skills/impeccable/SKILL.md
+++ b/.agents/skills/impeccable/SKILL.md
@@ -1,11 +1,21 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 user-invocable: true
-argument-hint: "[craft|teach]"
+argument-hint: "[craft|teach|extract]"
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -95,7 +105,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -108,7 +118,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -340,4 +349,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to .github/copilot-instructions.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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.agents/skills/impeccable/reference/extract.md b/.agents/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.agents/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.agents/skills/arrange/SKILL.md b/.agents/skills/layout/SKILL.md
similarity index 99%
rename from .agents/skills/arrange/SKILL.md
rename to .agents/skills/layout/SKILL.md
index d63c1aab0..5567238e9 100644
--- a/.agents/skills/arrange/SKILL.md
+++ b/.agents/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 user-invocable: true
 argument-hint: "[target]"
diff --git a/.agents/skills/normalize/SKILL.md b/.agents/skills/normalize/SKILL.md
deleted file mode 100644
index cbc512296..000000000
--- a/.agents/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[feature (page, route, component...)]"
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.agents/skills/onboard/SKILL.md b/.agents/skills/onboard/SKILL.md
deleted file mode 100644
index 01a1d2dd6..000000000
--- a/.agents/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,245 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
-user-invocable: true
-argument-hint: "[target]"
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.agents/skills/polish/SKILL.md b/.agents/skills/polish/SKILL.md
index 1e8751a6a..b44930c4e 100644
--- a/.agents/skills/polish/SKILL.md
+++ b/.agents/skills/polish/SKILL.md
@@ -13,6 +13,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -188,6 +198,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -199,4 +211,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.agents/skills/shape/SKILL.md b/.agents/skills/shape/SKILL.md
index 330b9b02e..1d8652aa9 100644
--- a/.agents/skills/shape/SKILL.md
+++ b/.agents/skills/shape/SKILL.md
@@ -92,4 +92,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.agents/skills/teach-impeccable/SKILL.md b/.agents/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 4f39eb5ae..000000000
--- a/.agents/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
-user-invocable: true
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.claude/skills/audit/SKILL.md b/.claude/skills/audit/SKILL.md
index 313959a02..1bbcb2693 100644
--- a/.claude/skills/audit/SKILL.md
+++ b/.claude/skills/audit/SKILL.md
@@ -108,7 +108,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -127,7 +127,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.claude/skills/critique/SKILL.md b/.claude/skills/critique/SKILL.md
index 2c5864182..4e16e45ac 100644
--- a/.claude/skills/critique/SKILL.md
+++ b/.claude/skills/critique/SKILL.md
@@ -145,7 +145,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -210,7 +210,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.claude/skills/extract/SKILL.md b/.claude/skills/extract/SKILL.md
deleted file mode 100644
index 4b57ea396..000000000
--- a/.claude/skills/extract/SKILL.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[target]"
----
-
-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.
\ No newline at end of file
diff --git a/.claude/skills/frontend-design/SKILL.md b/.claude/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.claude/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.claude/skills/harden/SKILL.md b/.claude/skills/harden/SKILL.md
index d870ddd13..95c9d6366 100644
--- a/.claude/skills/harden/SKILL.md
+++ b/.claude/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 user-invocable: true
 argument-hint: "[target]"
 ---
@@ -224,6 +224,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.claude/skills/impeccable/SKILL.md b/.claude/skills/impeccable/SKILL.md
index 43aed2265..6838e6cfa 100644
--- a/.claude/skills/impeccable/SKILL.md
+++ b/.claude/skills/impeccable/SKILL.md
@@ -1,11 +1,21 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 user-invocable: true
-argument-hint: "[craft|teach]"
+argument-hint: "[craft|teach|extract]"
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -95,7 +105,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -108,7 +118,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -340,4 +349,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then STOP and call the AskUserQuestion tool to clarify. whether they'd also like the Design Context appended to CLAUDE.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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.claude/skills/impeccable/reference/extract.md b/.claude/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d094f5f8f
--- /dev/null
+++ b/.claude/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, STOP and call the AskUserQuestion tool to clarify. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.claude/skills/arrange/SKILL.md b/.claude/skills/layout/SKILL.md
similarity index 99%
rename from .claude/skills/arrange/SKILL.md
rename to .claude/skills/layout/SKILL.md
index d63c1aab0..5567238e9 100644
--- a/.claude/skills/arrange/SKILL.md
+++ b/.claude/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 user-invocable: true
 argument-hint: "[target]"
diff --git a/.claude/skills/normalize/SKILL.md b/.claude/skills/normalize/SKILL.md
deleted file mode 100644
index cbc512296..000000000
--- a/.claude/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[feature (page, route, component...)]"
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.claude/skills/onboard/SKILL.md b/.claude/skills/onboard/SKILL.md
deleted file mode 100644
index 01a1d2dd6..000000000
--- a/.claude/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,245 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
-user-invocable: true
-argument-hint: "[target]"
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.claude/skills/polish/SKILL.md b/.claude/skills/polish/SKILL.md
index 1e8751a6a..b44930c4e 100644
--- a/.claude/skills/polish/SKILL.md
+++ b/.claude/skills/polish/SKILL.md
@@ -13,6 +13,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -188,6 +198,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -199,4 +211,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.claude/skills/shape/SKILL.md b/.claude/skills/shape/SKILL.md
index 21af45c2d..c8937bec6 100644
--- a/.claude/skills/shape/SKILL.md
+++ b/.claude/skills/shape/SKILL.md
@@ -92,4 +92,4 @@ Anything unresolved that the implementer should resolve during build.
 
 STOP and call the AskUserQuestion tool to clarify. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.claude/skills/teach-impeccable/SKILL.md b/.claude/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 4f39eb5ae..000000000
--- a/.claude/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
-user-invocable: true
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.codex/skills/audit/SKILL.md b/.codex/skills/audit/SKILL.md
index 444fd5978..93ff9299b 100644
--- a/.codex/skills/audit/SKILL.md
+++ b/.codex/skills/audit/SKILL.md
@@ -107,7 +107,7 @@ For each issue, document:
 - **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, $shape, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive)
+- **Suggested command**: Which command to use (prefer: $animate, $quieter, $shape, $optimize, $adapt, $clarify, $layout, $distill, $delight, $audit, $harden, $polish, $bolder, $typeset, $critique, $colorize, $overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -126,7 +126,7 @@ 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, $shape, $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.
+**Rules**: Only recommend commands from: $animate, $quieter, $shape, $optimize, $adapt, $clarify, $layout, $distill, $delight, $audit, $harden, $polish, $bolder, $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:
 
diff --git a/.codex/skills/critique/SKILL.md b/.codex/skills/critique/SKILL.md
index 8dff55390..ab58c2f6d 100644
--- a/.codex/skills/critique/SKILL.md
+++ b/.codex/skills/critique/SKILL.md
@@ -142,7 +142,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: $animate, $quieter, $shape, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive)
+- **Suggested command**: Which command could address this (from: $animate, $quieter, $shape, $optimize, $adapt, $clarify, $layout, $distill, $delight, $audit, $harden, $polish, $bolder, $typeset, $critique, $colorize, $overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -207,7 +207,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: $animate, $quieter, $shape, $optimize, $adapt, $clarify, $distill, $delight, $onboard, $normalize, $audit, $harden, $polish, $extract, $bolder, $arrange, $typeset, $critique, $colorize, $overdrive
+- Only recommend commands from: $animate, $quieter, $shape, $optimize, $adapt, $clarify, $layout, $distill, $delight, $audit, $harden, $polish, $bolder, $typeset, $critique, $colorize, $overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.codex/skills/extract/SKILL.md b/.codex/skills/extract/SKILL.md
deleted file mode 100644
index 77b9d0da5..000000000
--- a/.codex/skills/extract/SKILL.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-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.
-argument-hint: "[target]"
----
-
-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.
\ No newline at end of file
diff --git a/.codex/skills/frontend-design/SKILL.md b/.codex/skills/frontend-design/SKILL.md
deleted file mode 100644
index 606847842..000000000
--- a/.codex/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `$impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `$impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `$impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `$impeccable` instead.
\ No newline at end of file
diff --git a/.codex/skills/harden/SKILL.md b/.codex/skills/harden/SKILL.md
index 8919f5e49..8b33ede31 100644
--- a/.codex/skills/harden/SKILL.md
+++ b/.codex/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 argument-hint: "[target]"
 ---
 
@@ -223,6 +223,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.codex/skills/impeccable/SKILL.md b/.codex/skills/impeccable/SKILL.md
index 9737441aa..29e31ef86 100644
--- a/.codex/skills/impeccable/SKILL.md
+++ b/.codex/skills/impeccable/SKILL.md
@@ -1,10 +1,20 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
-argument-hint: "[craft|teach]"
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
+argument-hint: "[craft|teach|extract]"
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -94,7 +104,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -107,7 +117,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -339,4 +348,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `$impeccable extract [target]`), follow the [extract flow](reference$extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.codex/skills/impeccable/reference/extract.md b/.codex/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.codex/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.codex/skills/arrange/SKILL.md b/.codex/skills/layout/SKILL.md
similarity index 99%
rename from .codex/skills/arrange/SKILL.md
rename to .codex/skills/layout/SKILL.md
index 0b371c586..3122feba6 100644
--- a/.codex/skills/arrange/SKILL.md
+++ b/.codex/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 argument-hint: "[target]"
 ---
diff --git a/.codex/skills/normalize/SKILL.md b/.codex/skills/normalize/SKILL.md
deleted file mode 100644
index b310d331e..000000000
--- a/.codex/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-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.
-argument-hint: "[feature (page, route, component...)]"
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## MANDATORY PREPARATION
-
-Invoke $impeccable — 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 $impeccable teach 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.
\ No newline at end of file
diff --git a/.codex/skills/onboard/SKILL.md b/.codex/skills/onboard/SKILL.md
deleted file mode 100644
index 8cc4f2105..000000000
--- a/.codex/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
-argument-hint: "[target]"
----
-
-## MANDATORY PREPARATION
-
-Invoke $impeccable — 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 $impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.codex/skills/polish/SKILL.md b/.codex/skills/polish/SKILL.md
index 56c006041..b47c8c44d 100644
--- a/.codex/skills/polish/SKILL.md
+++ b/.codex/skills/polish/SKILL.md
@@ -12,6 +12,16 @@ Invoke $impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -187,6 +197,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -198,4 +210,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.codex/skills/shape/SKILL.md b/.codex/skills/shape/SKILL.md
index 035f3e7fa..ee0911498 100644
--- a/.codex/skills/shape/SKILL.md
+++ b/.codex/skills/shape/SKILL.md
@@ -91,4 +91,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to $impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to $impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use $impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.codex/skills/teach-impeccable/SKILL.md b/.codex/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 1f7a00d09..000000000
--- a/.codex/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
----
-
-This command has been renamed. Run `$impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `$teach-impeccable` command has been renamed to `$impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.cursor/skills/audit/SKILL.md b/.cursor/skills/audit/SKILL.md
index 37f353e71..435c65c96 100644
--- a/.cursor/skills/audit/SKILL.md
+++ b/.cursor/skills/audit/SKILL.md
@@ -106,7 +106,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -125,7 +125,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.cursor/skills/critique/SKILL.md b/.cursor/skills/critique/SKILL.md
index 7f0204530..06f7f1206 100644
--- a/.cursor/skills/critique/SKILL.md
+++ b/.cursor/skills/critique/SKILL.md
@@ -141,7 +141,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -206,7 +206,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.cursor/skills/extract/SKILL.md b/.cursor/skills/extract/SKILL.md
deleted file mode 100644
index 83d952496..000000000
--- a/.cursor/skills/extract/SKILL.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-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.
\ No newline at end of file
diff --git a/.cursor/skills/frontend-design/SKILL.md b/.cursor/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.cursor/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.cursor/skills/harden/SKILL.md b/.cursor/skills/harden/SKILL.md
index bb2cc7fec..8c7d14b8c 100644
--- a/.cursor/skills/harden/SKILL.md
+++ b/.cursor/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 ---
 
 Strengthen interfaces against edge cases, errors, internationalization issues, and real-world usage scenarios that break idealized designs.
@@ -222,6 +222,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.cursor/skills/impeccable/SKILL.md b/.cursor/skills/impeccable/SKILL.md
index bb2bae466..2cb7fb2f1 100644
--- a/.cursor/skills/impeccable/SKILL.md
+++ b/.cursor/skills/impeccable/SKILL.md
@@ -1,9 +1,19 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -93,7 +103,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -106,7 +116,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -338,4 +347,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to .cursorrules. 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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.cursor/skills/impeccable/reference/extract.md b/.cursor/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.cursor/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.kiro/skills/arrange/SKILL.md b/.cursor/skills/layout/SKILL.md
similarity index 99%
rename from .kiro/skills/arrange/SKILL.md
rename to .cursor/skills/layout/SKILL.md
index f80a260e9..7a1a082af 100644
--- a/.kiro/skills/arrange/SKILL.md
+++ b/.cursor/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 ---
 
diff --git a/.cursor/skills/normalize/SKILL.md b/.cursor/skills/normalize/SKILL.md
deleted file mode 100644
index c3e3c6256..000000000
--- a/.cursor/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-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 /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.cursor/skills/onboard/SKILL.md b/.cursor/skills/onboard/SKILL.md
deleted file mode 100644
index cd529ecb9..000000000
--- a/.cursor/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.cursor/skills/polish/SKILL.md b/.cursor/skills/polish/SKILL.md
index 53c97fec8..228625d44 100644
--- a/.cursor/skills/polish/SKILL.md
+++ b/.cursor/skills/polish/SKILL.md
@@ -11,6 +11,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -186,6 +196,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -197,4 +209,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.cursor/skills/shape/SKILL.md b/.cursor/skills/shape/SKILL.md
index 7e520562f..4f97f8b9a 100644
--- a/.cursor/skills/shape/SKILL.md
+++ b/.cursor/skills/shape/SKILL.md
@@ -90,4 +90,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.cursor/skills/teach-impeccable/SKILL.md b/.cursor/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 0847a769f..000000000
--- a/.cursor/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.gemini/skills/audit/SKILL.md b/.gemini/skills/audit/SKILL.md
index 37f353e71..435c65c96 100644
--- a/.gemini/skills/audit/SKILL.md
+++ b/.gemini/skills/audit/SKILL.md
@@ -106,7 +106,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -125,7 +125,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.gemini/skills/critique/SKILL.md b/.gemini/skills/critique/SKILL.md
index 289476584..3057207e8 100644
--- a/.gemini/skills/critique/SKILL.md
+++ b/.gemini/skills/critique/SKILL.md
@@ -141,7 +141,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -206,7 +206,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.gemini/skills/extract/SKILL.md b/.gemini/skills/extract/SKILL.md
deleted file mode 100644
index 83d952496..000000000
--- a/.gemini/skills/extract/SKILL.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-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.
\ No newline at end of file
diff --git a/.gemini/skills/frontend-design/SKILL.md b/.gemini/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.gemini/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.gemini/skills/harden/SKILL.md b/.gemini/skills/harden/SKILL.md
index bb2cc7fec..8c7d14b8c 100644
--- a/.gemini/skills/harden/SKILL.md
+++ b/.gemini/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 ---
 
 Strengthen interfaces against edge cases, errors, internationalization issues, and real-world usage scenarios that break idealized designs.
@@ -222,6 +222,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.gemini/skills/impeccable/SKILL.md b/.gemini/skills/impeccable/SKILL.md
index 20a295b59..301f01554 100644
--- a/.gemini/skills/impeccable/SKILL.md
+++ b/.gemini/skills/impeccable/SKILL.md
@@ -1,8 +1,18 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -92,7 +102,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -105,7 +115,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -337,4 +346,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to GEMINI.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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.gemini/skills/impeccable/reference/extract.md b/.gemini/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.gemini/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.pi/skills/arrange/SKILL.md b/.gemini/skills/layout/SKILL.md
similarity index 99%
rename from .pi/skills/arrange/SKILL.md
rename to .gemini/skills/layout/SKILL.md
index f80a260e9..7a1a082af 100644
--- a/.pi/skills/arrange/SKILL.md
+++ b/.gemini/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 ---
 
diff --git a/.gemini/skills/normalize/SKILL.md b/.gemini/skills/normalize/SKILL.md
deleted file mode 100644
index c3e3c6256..000000000
--- a/.gemini/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-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 /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.gemini/skills/onboard/SKILL.md b/.gemini/skills/onboard/SKILL.md
deleted file mode 100644
index cd529ecb9..000000000
--- a/.gemini/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.gemini/skills/polish/SKILL.md b/.gemini/skills/polish/SKILL.md
index 53c97fec8..228625d44 100644
--- a/.gemini/skills/polish/SKILL.md
+++ b/.gemini/skills/polish/SKILL.md
@@ -11,6 +11,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -186,6 +196,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -197,4 +209,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.gemini/skills/shape/SKILL.md b/.gemini/skills/shape/SKILL.md
index 7e520562f..4f97f8b9a 100644
--- a/.gemini/skills/shape/SKILL.md
+++ b/.gemini/skills/shape/SKILL.md
@@ -90,4 +90,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.gemini/skills/teach-impeccable/SKILL.md b/.gemini/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 0847a769f..000000000
--- a/.gemini/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.kiro/skills/audit/SKILL.md b/.kiro/skills/audit/SKILL.md
index 37f353e71..435c65c96 100644
--- a/.kiro/skills/audit/SKILL.md
+++ b/.kiro/skills/audit/SKILL.md
@@ -106,7 +106,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -125,7 +125,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.kiro/skills/critique/SKILL.md b/.kiro/skills/critique/SKILL.md
index 4a40fa87b..19c189837 100644
--- a/.kiro/skills/critique/SKILL.md
+++ b/.kiro/skills/critique/SKILL.md
@@ -141,7 +141,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -206,7 +206,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.kiro/skills/extract/SKILL.md b/.kiro/skills/extract/SKILL.md
deleted file mode 100644
index 83d952496..000000000
--- a/.kiro/skills/extract/SKILL.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-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.
\ No newline at end of file
diff --git a/.kiro/skills/frontend-design/SKILL.md b/.kiro/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.kiro/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.kiro/skills/harden/SKILL.md b/.kiro/skills/harden/SKILL.md
index bb2cc7fec..8c7d14b8c 100644
--- a/.kiro/skills/harden/SKILL.md
+++ b/.kiro/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 ---
 
 Strengthen interfaces against edge cases, errors, internationalization issues, and real-world usage scenarios that break idealized designs.
@@ -222,6 +222,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.kiro/skills/impeccable/SKILL.md b/.kiro/skills/impeccable/SKILL.md
index e5c306f3c..b6be874ce 100644
--- a/.kiro/skills/impeccable/SKILL.md
+++ b/.kiro/skills/impeccable/SKILL.md
@@ -1,9 +1,19 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -93,7 +103,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -106,7 +116,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -338,4 +347,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to .kiro/settings.json. 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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.kiro/skills/impeccable/reference/extract.md b/.kiro/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.kiro/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.gemini/skills/arrange/SKILL.md b/.kiro/skills/layout/SKILL.md
similarity index 99%
rename from .gemini/skills/arrange/SKILL.md
rename to .kiro/skills/layout/SKILL.md
index f80a260e9..7a1a082af 100644
--- a/.gemini/skills/arrange/SKILL.md
+++ b/.kiro/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 ---
 
diff --git a/.kiro/skills/normalize/SKILL.md b/.kiro/skills/normalize/SKILL.md
deleted file mode 100644
index c3e3c6256..000000000
--- a/.kiro/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-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 /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.kiro/skills/onboard/SKILL.md b/.kiro/skills/onboard/SKILL.md
deleted file mode 100644
index cd529ecb9..000000000
--- a/.kiro/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.kiro/skills/polish/SKILL.md b/.kiro/skills/polish/SKILL.md
index 53c97fec8..228625d44 100644
--- a/.kiro/skills/polish/SKILL.md
+++ b/.kiro/skills/polish/SKILL.md
@@ -11,6 +11,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -186,6 +196,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -197,4 +209,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.kiro/skills/shape/SKILL.md b/.kiro/skills/shape/SKILL.md
index 7e520562f..4f97f8b9a 100644
--- a/.kiro/skills/shape/SKILL.md
+++ b/.kiro/skills/shape/SKILL.md
@@ -90,4 +90,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.kiro/skills/teach-impeccable/SKILL.md b/.kiro/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 0847a769f..000000000
--- a/.kiro/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.opencode/skills/audit/SKILL.md b/.opencode/skills/audit/SKILL.md
index 313959a02..1bbcb2693 100644
--- a/.opencode/skills/audit/SKILL.md
+++ b/.opencode/skills/audit/SKILL.md
@@ -108,7 +108,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -127,7 +127,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.opencode/skills/critique/SKILL.md b/.opencode/skills/critique/SKILL.md
index c76de0c3b..11911630d 100644
--- a/.opencode/skills/critique/SKILL.md
+++ b/.opencode/skills/critique/SKILL.md
@@ -145,7 +145,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -210,7 +210,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.opencode/skills/extract/SKILL.md b/.opencode/skills/extract/SKILL.md
deleted file mode 100644
index 4b57ea396..000000000
--- a/.opencode/skills/extract/SKILL.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[target]"
----
-
-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.
\ No newline at end of file
diff --git a/.opencode/skills/frontend-design/SKILL.md b/.opencode/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.opencode/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.opencode/skills/harden/SKILL.md b/.opencode/skills/harden/SKILL.md
index d870ddd13..95c9d6366 100644
--- a/.opencode/skills/harden/SKILL.md
+++ b/.opencode/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 user-invocable: true
 argument-hint: "[target]"
 ---
@@ -224,6 +224,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.opencode/skills/impeccable/SKILL.md b/.opencode/skills/impeccable/SKILL.md
index cd01aa772..ba0362b7b 100644
--- a/.opencode/skills/impeccable/SKILL.md
+++ b/.opencode/skills/impeccable/SKILL.md
@@ -1,11 +1,21 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 user-invocable: true
-argument-hint: "[craft|teach]"
+argument-hint: "[craft|teach|extract]"
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -95,7 +105,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -108,7 +118,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -340,4 +349,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then STOP and call the `question` tool to clarify. 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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.opencode/skills/impeccable/reference/extract.md b/.opencode/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..3eacdb2e4
--- /dev/null
+++ b/.opencode/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, STOP and call the `question` tool to clarify. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.opencode/skills/arrange/SKILL.md b/.opencode/skills/layout/SKILL.md
similarity index 99%
rename from .opencode/skills/arrange/SKILL.md
rename to .opencode/skills/layout/SKILL.md
index d63c1aab0..5567238e9 100644
--- a/.opencode/skills/arrange/SKILL.md
+++ b/.opencode/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 user-invocable: true
 argument-hint: "[target]"
diff --git a/.opencode/skills/normalize/SKILL.md b/.opencode/skills/normalize/SKILL.md
deleted file mode 100644
index cbc512296..000000000
--- a/.opencode/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[feature (page, route, component...)]"
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.opencode/skills/onboard/SKILL.md b/.opencode/skills/onboard/SKILL.md
deleted file mode 100644
index 01a1d2dd6..000000000
--- a/.opencode/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,245 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
-user-invocable: true
-argument-hint: "[target]"
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.opencode/skills/polish/SKILL.md b/.opencode/skills/polish/SKILL.md
index 1e8751a6a..b44930c4e 100644
--- a/.opencode/skills/polish/SKILL.md
+++ b/.opencode/skills/polish/SKILL.md
@@ -13,6 +13,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -188,6 +198,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -199,4 +211,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.opencode/skills/shape/SKILL.md b/.opencode/skills/shape/SKILL.md
index f841906a6..e3947a631 100644
--- a/.opencode/skills/shape/SKILL.md
+++ b/.opencode/skills/shape/SKILL.md
@@ -92,4 +92,4 @@ Anything unresolved that the implementer should resolve during build.
 
 STOP and call the `question` tool to clarify. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.opencode/skills/teach-impeccable/SKILL.md b/.opencode/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 4f39eb5ae..000000000
--- a/.opencode/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
-user-invocable: true
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.pi/skills/audit/SKILL.md b/.pi/skills/audit/SKILL.md
index 37f353e71..435c65c96 100644
--- a/.pi/skills/audit/SKILL.md
+++ b/.pi/skills/audit/SKILL.md
@@ -106,7 +106,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -125,7 +125,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.pi/skills/critique/SKILL.md b/.pi/skills/critique/SKILL.md
index f4081a9eb..c9b978974 100644
--- a/.pi/skills/critique/SKILL.md
+++ b/.pi/skills/critique/SKILL.md
@@ -143,7 +143,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -208,7 +208,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.pi/skills/extract/SKILL.md b/.pi/skills/extract/SKILL.md
deleted file mode 100644
index 83d952496..000000000
--- a/.pi/skills/extract/SKILL.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-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.
\ No newline at end of file
diff --git a/.pi/skills/frontend-design/SKILL.md b/.pi/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.pi/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.pi/skills/harden/SKILL.md b/.pi/skills/harden/SKILL.md
index bb2cc7fec..8c7d14b8c 100644
--- a/.pi/skills/harden/SKILL.md
+++ b/.pi/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 ---
 
 Strengthen interfaces against edge cases, errors, internationalization issues, and real-world usage scenarios that break idealized designs.
@@ -222,6 +222,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.pi/skills/impeccable/SKILL.md b/.pi/skills/impeccable/SKILL.md
index fc973b453..ed039d6bf 100644
--- a/.pi/skills/impeccable/SKILL.md
+++ b/.pi/skills/impeccable/SKILL.md
@@ -1,9 +1,19 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -93,7 +103,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -106,7 +116,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -338,4 +347,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.pi/skills/impeccable/reference/extract.md b/.pi/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.pi/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.cursor/skills/arrange/SKILL.md b/.pi/skills/layout/SKILL.md
similarity index 99%
rename from .cursor/skills/arrange/SKILL.md
rename to .pi/skills/layout/SKILL.md
index f80a260e9..7a1a082af 100644
--- a/.cursor/skills/arrange/SKILL.md
+++ b/.pi/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 ---
 
diff --git a/.pi/skills/normalize/SKILL.md b/.pi/skills/normalize/SKILL.md
deleted file mode 100644
index c3e3c6256..000000000
--- a/.pi/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-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 /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.pi/skills/onboard/SKILL.md b/.pi/skills/onboard/SKILL.md
deleted file mode 100644
index cd529ecb9..000000000
--- a/.pi/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.pi/skills/polish/SKILL.md b/.pi/skills/polish/SKILL.md
index 53c97fec8..228625d44 100644
--- a/.pi/skills/polish/SKILL.md
+++ b/.pi/skills/polish/SKILL.md
@@ -11,6 +11,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -186,6 +196,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -197,4 +209,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.pi/skills/shape/SKILL.md b/.pi/skills/shape/SKILL.md
index 7e520562f..4f97f8b9a 100644
--- a/.pi/skills/shape/SKILL.md
+++ b/.pi/skills/shape/SKILL.md
@@ -90,4 +90,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.pi/skills/teach-impeccable/SKILL.md b/.pi/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 0847a769f..000000000
--- a/.pi/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.rovodev/skills/audit/SKILL.md b/.rovodev/skills/audit/SKILL.md
index 313959a02..1bbcb2693 100644
--- a/.rovodev/skills/audit/SKILL.md
+++ b/.rovodev/skills/audit/SKILL.md
@@ -108,7 +108,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -127,7 +127,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.rovodev/skills/critique/SKILL.md b/.rovodev/skills/critique/SKILL.md
index 8ed006ad1..50932dfb9 100644
--- a/.rovodev/skills/critique/SKILL.md
+++ b/.rovodev/skills/critique/SKILL.md
@@ -145,7 +145,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -210,7 +210,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.rovodev/skills/extract/SKILL.md b/.rovodev/skills/extract/SKILL.md
deleted file mode 100644
index 4b57ea396..000000000
--- a/.rovodev/skills/extract/SKILL.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[target]"
----
-
-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.
\ No newline at end of file
diff --git a/.rovodev/skills/frontend-design/SKILL.md b/.rovodev/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.rovodev/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.rovodev/skills/harden/SKILL.md b/.rovodev/skills/harden/SKILL.md
index d870ddd13..95c9d6366 100644
--- a/.rovodev/skills/harden/SKILL.md
+++ b/.rovodev/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 user-invocable: true
 argument-hint: "[target]"
 ---
@@ -224,6 +224,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.rovodev/skills/impeccable/SKILL.md b/.rovodev/skills/impeccable/SKILL.md
index 6409ef7ff..ac09e5540 100644
--- a/.rovodev/skills/impeccable/SKILL.md
+++ b/.rovodev/skills/impeccable/SKILL.md
@@ -1,11 +1,21 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 user-invocable: true
-argument-hint: "[craft|teach]"
+argument-hint: "[craft|teach|extract]"
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -95,7 +105,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -108,7 +118,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -340,4 +349,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.rovodev/skills/impeccable/reference/extract.md b/.rovodev/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.rovodev/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.rovodev/skills/arrange/SKILL.md b/.rovodev/skills/layout/SKILL.md
similarity index 99%
rename from .rovodev/skills/arrange/SKILL.md
rename to .rovodev/skills/layout/SKILL.md
index d63c1aab0..5567238e9 100644
--- a/.rovodev/skills/arrange/SKILL.md
+++ b/.rovodev/skills/layout/SKILL.md
@@ -1,5 +1,5 @@
 ---
-name: arrange
+name: layout
 description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
 user-invocable: true
 argument-hint: "[target]"
diff --git a/.rovodev/skills/normalize/SKILL.md b/.rovodev/skills/normalize/SKILL.md
deleted file mode 100644
index cbc512296..000000000
--- a/.rovodev/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[feature (page, route, component...)]"
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.rovodev/skills/onboard/SKILL.md b/.rovodev/skills/onboard/SKILL.md
deleted file mode 100644
index 01a1d2dd6..000000000
--- a/.rovodev/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,245 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
-user-invocable: true
-argument-hint: "[target]"
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.rovodev/skills/polish/SKILL.md b/.rovodev/skills/polish/SKILL.md
index 1e8751a6a..b44930c4e 100644
--- a/.rovodev/skills/polish/SKILL.md
+++ b/.rovodev/skills/polish/SKILL.md
@@ -13,6 +13,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -188,6 +198,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -199,4 +211,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.rovodev/skills/shape/SKILL.md b/.rovodev/skills/shape/SKILL.md
index 330b9b02e..1d8652aa9 100644
--- a/.rovodev/skills/shape/SKILL.md
+++ b/.rovodev/skills/shape/SKILL.md
@@ -92,4 +92,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.rovodev/skills/teach-impeccable/SKILL.md b/.rovodev/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 4f39eb5ae..000000000
--- a/.rovodev/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
-user-invocable: true
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.trae-cn/skills/arrange/SKILL.md b/.trae-cn/skills/arrange/SKILL.md
deleted file mode 100644
index d63c1aab0..000000000
--- a/.trae-cn/skills/arrange/SKILL.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-name: arrange
-description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
-user-invocable: true
-argument-hint: "[target]"
----
-
-Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first.
-
----
-
-## Assess Current Layout
-
-Analyze what's weak about the current spatial design:
-
-1. **Spacing**:
-   - Is spacing consistent or arbitrary? (Random padding/margin values)
-   - Is all spacing the same? (Equal padding everywhere = no rhythm)
-   - Are related elements grouped tightly, with generous space between groups?
-
-2. **Visual hierarchy**:
-   - Apply the squint test: blur your (metaphorical) eyes — can you still identify the most important element, second most important, and clear groupings?
-   - Is hierarchy achieved effectively? (Space and weight alone can be enough — but is the current approach working?)
-   - Does whitespace guide the eye to what matters?
-
-3. **Grid & structure**:
-   - Is there a clear underlying structure, or does the layout feel random?
-   - Are identical card grids used everywhere? (Icon + heading + text, repeated endlessly)
-   - Is everything centered? (Left-aligned with asymmetric layouts feels more designed, but not a hard and fast rule)
-
-4. **Rhythm & variety**:
-   - Does the layout have visual rhythm? (Alternating tight/generous spacing)
-   - Is every section structured the same way? (Monotonous repetition)
-   - Are there intentional moments of surprise or emphasis?
-
-5. **Density**:
-   - Is the layout too cramped? (Not enough breathing room)
-   - Is the layout too sparse? (Excessive whitespace without purpose)
-   - Does density match the content type? (Data-dense UIs need tighter spacing; marketing pages need more air)
-
-**CRITICAL**: Layout problems are often the root cause of interfaces feeling "off" even when colors and fonts are fine. Space is a design material — use it with intention.
-
-## Plan Layout Improvements
-
-Consult the [spatial design reference](reference/spatial-design.md) from the impeccable skill for detailed guidance on grids, rhythm, and container queries.
-
-Create a systematic plan:
-
-- **Spacing system**: Use a consistent scale — whether that's a framework's built-in scale (e.g., Tailwind), rem-based tokens, or a custom system. The specific values matter less than consistency.
-- **Hierarchy strategy**: How will space communicate importance?
-- **Layout approach**: What structure fits the content? Flex for 1D, Grid for 2D, named areas for complex page layouts.
-- **Rhythm**: Where should spacing be tight vs generous?
-
-## Improve Layout Systematically
-
-### Establish a Spacing System
-
-- Use a consistent spacing scale — framework scales (Tailwind, etc.), rem-based tokens, or a custom scale all work. What matters is that values come from a defined set, not arbitrary numbers.
-- Name tokens semantically if using custom properties: `--space-xs` through `--space-xl`, not `--spacing-8`
-- Use `gap` for sibling spacing instead of margins — eliminates margin collapse hacks
-- Apply `clamp()` for fluid spacing that breathes on larger screens
-
-### Create Visual Rhythm
-
-- **Tight grouping** for related elements (8-12px between siblings)
-- **Generous separation** between distinct sections (48-96px)
-- **Varied spacing** within sections — not every row needs the same gap
-- **Asymmetric compositions** — break the predictable centered-content pattern when it makes sense
-
-### Choose the Right Layout Tool
-
-- **Use Flexbox for 1D layouts**: Rows of items, nav bars, button groups, card contents, most component internals. Flex is simpler and more appropriate for the majority of layout tasks.
-- **Use Grid for 2D layouts**: Page-level structure, dashboards, data-dense interfaces, anything where rows AND columns need coordinated control.
-- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.
-- Use `repeat(auto-fit, minmax(280px, 1fr))` for responsive grids without breakpoints.
-- Use named grid areas (`grid-template-areas`) for complex page layouts — redefine at breakpoints.
-
-### Break Card Grid Monotony
-
-- Don't default to card grids for everything — spacing and alignment create visual grouping naturally
-- Use cards only when content is truly distinct and actionable — never nest cards inside cards
-- Vary card sizes, span columns, or mix cards with non-card content to break repetition
-
-### Strengthen Visual Hierarchy
-
-- Use the fewest dimensions needed for clear hierarchy. Space alone can be enough — generous whitespace around an element draws the eye. Some of the most sophisticated designs achieve rhythm with just space and weight. Add color or size contrast only when simpler means aren't sufficient.
-- Be aware of reading flow — in LTR languages, the eye naturally scans top-left to bottom-right, but primary action placement depends on context (e.g., bottom-right in dialogs, top in navigation).
-- Create clear content groupings through proximity and separation.
-
-### Manage Depth & Elevation
-
-- Create a semantic z-index scale (dropdown → sticky → modal-backdrop → modal → toast → tooltip)
-- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle
-- Use elevation to reinforce hierarchy, not as decoration
-
-### Optical Adjustments
-
-- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.
-
-**NEVER**:
-- Use arbitrary spacing values outside your scale
-- Make all spacing equal — variety creates hierarchy
-- Wrap everything in cards — not everything needs a container
-- Nest cards inside cards — use spacing and dividers for hierarchy within
-- Use identical card grids everywhere (icon + heading + text, repeated)
-- Center everything — left-aligned with asymmetry feels more designed
-- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.
-- Default to CSS Grid when Flexbox would be simpler — use the simplest tool for the job
-- Use arbitrary z-index values (999, 9999) — build a semantic scale
-
-## Verify Layout Improvements
-
-- **Squint test**: Can you identify primary, secondary, and groupings with blurred vision?
-- **Rhythm**: Does the page have a satisfying beat of tight and generous spacing?
-- **Hierarchy**: Is the most important content obvious within 2 seconds?
-- **Breathing room**: Does the layout feel comfortable, not cramped or wasteful?
-- **Consistency**: Is the spacing system applied uniformly?
-- **Responsiveness**: Does the layout adapt gracefully across screen sizes?
-
-Remember: Space is the most underused design tool. A layout with the right rhythm and hierarchy can make even simple content feel polished and intentional.
\ No newline at end of file
diff --git a/.trae-cn/skills/audit/SKILL.md b/.trae-cn/skills/audit/SKILL.md
index 313959a02..1bbcb2693 100644
--- a/.trae-cn/skills/audit/SKILL.md
+++ b/.trae-cn/skills/audit/SKILL.md
@@ -108,7 +108,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -127,7 +127,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.trae-cn/skills/critique/SKILL.md b/.trae-cn/skills/critique/SKILL.md
index 8a86bd133..075081b3f 100644
--- a/.trae-cn/skills/critique/SKILL.md
+++ b/.trae-cn/skills/critique/SKILL.md
@@ -143,7 +143,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -208,7 +208,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.trae-cn/skills/extract/SKILL.md b/.trae-cn/skills/extract/SKILL.md
deleted file mode 100644
index 4b57ea396..000000000
--- a/.trae-cn/skills/extract/SKILL.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[target]"
----
-
-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.
\ No newline at end of file
diff --git a/.trae-cn/skills/frontend-design/SKILL.md b/.trae-cn/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.trae-cn/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.trae-cn/skills/harden/SKILL.md b/.trae-cn/skills/harden/SKILL.md
index d870ddd13..95c9d6366 100644
--- a/.trae-cn/skills/harden/SKILL.md
+++ b/.trae-cn/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 user-invocable: true
 argument-hint: "[target]"
 ---
@@ -224,6 +224,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.trae-cn/skills/impeccable/SKILL.md b/.trae-cn/skills/impeccable/SKILL.md
index 784258b53..0830286d9 100644
--- a/.trae-cn/skills/impeccable/SKILL.md
+++ b/.trae-cn/skills/impeccable/SKILL.md
@@ -1,11 +1,21 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 user-invocable: true
-argument-hint: "[craft|teach]"
+argument-hint: "[craft|teach|extract]"
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -95,7 +105,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -108,7 +118,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -340,4 +349,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to RULES.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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.trae-cn/skills/impeccable/reference/extract.md b/.trae-cn/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.trae-cn/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.trae-cn/skills/layout/SKILL.md b/.trae-cn/skills/layout/SKILL.md
new file mode 100644
index 000000000..5567238e9
--- /dev/null
+++ b/.trae-cn/skills/layout/SKILL.md
@@ -0,0 +1,124 @@
+---
+name: layout
+description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
+user-invocable: true
+argument-hint: "[target]"
+---
+
+Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.
+
+## MANDATORY PREPARATION
+
+Invoke /impeccable — 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 /impeccable teach first.
+
+---
+
+## Assess Current Layout
+
+Analyze what's weak about the current spatial design:
+
+1. **Spacing**:
+   - Is spacing consistent or arbitrary? (Random padding/margin values)
+   - Is all spacing the same? (Equal padding everywhere = no rhythm)
+   - Are related elements grouped tightly, with generous space between groups?
+
+2. **Visual hierarchy**:
+   - Apply the squint test: blur your (metaphorical) eyes — can you still identify the most important element, second most important, and clear groupings?
+   - Is hierarchy achieved effectively? (Space and weight alone can be enough — but is the current approach working?)
+   - Does whitespace guide the eye to what matters?
+
+3. **Grid & structure**:
+   - Is there a clear underlying structure, or does the layout feel random?
+   - Are identical card grids used everywhere? (Icon + heading + text, repeated endlessly)
+   - Is everything centered? (Left-aligned with asymmetric layouts feels more designed, but not a hard and fast rule)
+
+4. **Rhythm & variety**:
+   - Does the layout have visual rhythm? (Alternating tight/generous spacing)
+   - Is every section structured the same way? (Monotonous repetition)
+   - Are there intentional moments of surprise or emphasis?
+
+5. **Density**:
+   - Is the layout too cramped? (Not enough breathing room)
+   - Is the layout too sparse? (Excessive whitespace without purpose)
+   - Does density match the content type? (Data-dense UIs need tighter spacing; marketing pages need more air)
+
+**CRITICAL**: Layout problems are often the root cause of interfaces feeling "off" even when colors and fonts are fine. Space is a design material — use it with intention.
+
+## Plan Layout Improvements
+
+Consult the [spatial design reference](reference/spatial-design.md) from the impeccable skill for detailed guidance on grids, rhythm, and container queries.
+
+Create a systematic plan:
+
+- **Spacing system**: Use a consistent scale — whether that's a framework's built-in scale (e.g., Tailwind), rem-based tokens, or a custom system. The specific values matter less than consistency.
+- **Hierarchy strategy**: How will space communicate importance?
+- **Layout approach**: What structure fits the content? Flex for 1D, Grid for 2D, named areas for complex page layouts.
+- **Rhythm**: Where should spacing be tight vs generous?
+
+## Improve Layout Systematically
+
+### Establish a Spacing System
+
+- Use a consistent spacing scale — framework scales (Tailwind, etc.), rem-based tokens, or a custom scale all work. What matters is that values come from a defined set, not arbitrary numbers.
+- Name tokens semantically if using custom properties: `--space-xs` through `--space-xl`, not `--spacing-8`
+- Use `gap` for sibling spacing instead of margins — eliminates margin collapse hacks
+- Apply `clamp()` for fluid spacing that breathes on larger screens
+
+### Create Visual Rhythm
+
+- **Tight grouping** for related elements (8-12px between siblings)
+- **Generous separation** between distinct sections (48-96px)
+- **Varied spacing** within sections — not every row needs the same gap
+- **Asymmetric compositions** — break the predictable centered-content pattern when it makes sense
+
+### Choose the Right Layout Tool
+
+- **Use Flexbox for 1D layouts**: Rows of items, nav bars, button groups, card contents, most component internals. Flex is simpler and more appropriate for the majority of layout tasks.
+- **Use Grid for 2D layouts**: Page-level structure, dashboards, data-dense interfaces, anything where rows AND columns need coordinated control.
+- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.
+- Use `repeat(auto-fit, minmax(280px, 1fr))` for responsive grids without breakpoints.
+- Use named grid areas (`grid-template-areas`) for complex page layouts — redefine at breakpoints.
+
+### Break Card Grid Monotony
+
+- Don't default to card grids for everything — spacing and alignment create visual grouping naturally
+- Use cards only when content is truly distinct and actionable — never nest cards inside cards
+- Vary card sizes, span columns, or mix cards with non-card content to break repetition
+
+### Strengthen Visual Hierarchy
+
+- Use the fewest dimensions needed for clear hierarchy. Space alone can be enough — generous whitespace around an element draws the eye. Some of the most sophisticated designs achieve rhythm with just space and weight. Add color or size contrast only when simpler means aren't sufficient.
+- Be aware of reading flow — in LTR languages, the eye naturally scans top-left to bottom-right, but primary action placement depends on context (e.g., bottom-right in dialogs, top in navigation).
+- Create clear content groupings through proximity and separation.
+
+### Manage Depth & Elevation
+
+- Create a semantic z-index scale (dropdown → sticky → modal-backdrop → modal → toast → tooltip)
+- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle
+- Use elevation to reinforce hierarchy, not as decoration
+
+### Optical Adjustments
+
+- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.
+
+**NEVER**:
+- Use arbitrary spacing values outside your scale
+- Make all spacing equal — variety creates hierarchy
+- Wrap everything in cards — not everything needs a container
+- Nest cards inside cards — use spacing and dividers for hierarchy within
+- Use identical card grids everywhere (icon + heading + text, repeated)
+- Center everything — left-aligned with asymmetry feels more designed
+- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.
+- Default to CSS Grid when Flexbox would be simpler — use the simplest tool for the job
+- Use arbitrary z-index values (999, 9999) — build a semantic scale
+
+## Verify Layout Improvements
+
+- **Squint test**: Can you identify primary, secondary, and groupings with blurred vision?
+- **Rhythm**: Does the page have a satisfying beat of tight and generous spacing?
+- **Hierarchy**: Is the most important content obvious within 2 seconds?
+- **Breathing room**: Does the layout feel comfortable, not cramped or wasteful?
+- **Consistency**: Is the spacing system applied uniformly?
+- **Responsiveness**: Does the layout adapt gracefully across screen sizes?
+
+Remember: Space is the most underused design tool. A layout with the right rhythm and hierarchy can make even simple content feel polished and intentional.
\ No newline at end of file
diff --git a/.trae-cn/skills/normalize/SKILL.md b/.trae-cn/skills/normalize/SKILL.md
deleted file mode 100644
index cbc512296..000000000
--- a/.trae-cn/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[feature (page, route, component...)]"
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.trae-cn/skills/onboard/SKILL.md b/.trae-cn/skills/onboard/SKILL.md
deleted file mode 100644
index 01a1d2dd6..000000000
--- a/.trae-cn/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,245 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
-user-invocable: true
-argument-hint: "[target]"
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.trae-cn/skills/polish/SKILL.md b/.trae-cn/skills/polish/SKILL.md
index 1e8751a6a..b44930c4e 100644
--- a/.trae-cn/skills/polish/SKILL.md
+++ b/.trae-cn/skills/polish/SKILL.md
@@ -13,6 +13,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -188,6 +198,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -199,4 +211,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.trae-cn/skills/shape/SKILL.md b/.trae-cn/skills/shape/SKILL.md
index 330b9b02e..1d8652aa9 100644
--- a/.trae-cn/skills/shape/SKILL.md
+++ b/.trae-cn/skills/shape/SKILL.md
@@ -92,4 +92,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.trae-cn/skills/teach-impeccable/SKILL.md b/.trae-cn/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 4f39eb5ae..000000000
--- a/.trae-cn/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
-user-invocable: true
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/.trae/skills/arrange/SKILL.md b/.trae/skills/arrange/SKILL.md
deleted file mode 100644
index d63c1aab0..000000000
--- a/.trae/skills/arrange/SKILL.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-name: arrange
-description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
-user-invocable: true
-argument-hint: "[target]"
----
-
-Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first.
-
----
-
-## Assess Current Layout
-
-Analyze what's weak about the current spatial design:
-
-1. **Spacing**:
-   - Is spacing consistent or arbitrary? (Random padding/margin values)
-   - Is all spacing the same? (Equal padding everywhere = no rhythm)
-   - Are related elements grouped tightly, with generous space between groups?
-
-2. **Visual hierarchy**:
-   - Apply the squint test: blur your (metaphorical) eyes — can you still identify the most important element, second most important, and clear groupings?
-   - Is hierarchy achieved effectively? (Space and weight alone can be enough — but is the current approach working?)
-   - Does whitespace guide the eye to what matters?
-
-3. **Grid & structure**:
-   - Is there a clear underlying structure, or does the layout feel random?
-   - Are identical card grids used everywhere? (Icon + heading + text, repeated endlessly)
-   - Is everything centered? (Left-aligned with asymmetric layouts feels more designed, but not a hard and fast rule)
-
-4. **Rhythm & variety**:
-   - Does the layout have visual rhythm? (Alternating tight/generous spacing)
-   - Is every section structured the same way? (Monotonous repetition)
-   - Are there intentional moments of surprise or emphasis?
-
-5. **Density**:
-   - Is the layout too cramped? (Not enough breathing room)
-   - Is the layout too sparse? (Excessive whitespace without purpose)
-   - Does density match the content type? (Data-dense UIs need tighter spacing; marketing pages need more air)
-
-**CRITICAL**: Layout problems are often the root cause of interfaces feeling "off" even when colors and fonts are fine. Space is a design material — use it with intention.
-
-## Plan Layout Improvements
-
-Consult the [spatial design reference](reference/spatial-design.md) from the impeccable skill for detailed guidance on grids, rhythm, and container queries.
-
-Create a systematic plan:
-
-- **Spacing system**: Use a consistent scale — whether that's a framework's built-in scale (e.g., Tailwind), rem-based tokens, or a custom system. The specific values matter less than consistency.
-- **Hierarchy strategy**: How will space communicate importance?
-- **Layout approach**: What structure fits the content? Flex for 1D, Grid for 2D, named areas for complex page layouts.
-- **Rhythm**: Where should spacing be tight vs generous?
-
-## Improve Layout Systematically
-
-### Establish a Spacing System
-
-- Use a consistent spacing scale — framework scales (Tailwind, etc.), rem-based tokens, or a custom scale all work. What matters is that values come from a defined set, not arbitrary numbers.
-- Name tokens semantically if using custom properties: `--space-xs` through `--space-xl`, not `--spacing-8`
-- Use `gap` for sibling spacing instead of margins — eliminates margin collapse hacks
-- Apply `clamp()` for fluid spacing that breathes on larger screens
-
-### Create Visual Rhythm
-
-- **Tight grouping** for related elements (8-12px between siblings)
-- **Generous separation** between distinct sections (48-96px)
-- **Varied spacing** within sections — not every row needs the same gap
-- **Asymmetric compositions** — break the predictable centered-content pattern when it makes sense
-
-### Choose the Right Layout Tool
-
-- **Use Flexbox for 1D layouts**: Rows of items, nav bars, button groups, card contents, most component internals. Flex is simpler and more appropriate for the majority of layout tasks.
-- **Use Grid for 2D layouts**: Page-level structure, dashboards, data-dense interfaces, anything where rows AND columns need coordinated control.
-- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.
-- Use `repeat(auto-fit, minmax(280px, 1fr))` for responsive grids without breakpoints.
-- Use named grid areas (`grid-template-areas`) for complex page layouts — redefine at breakpoints.
-
-### Break Card Grid Monotony
-
-- Don't default to card grids for everything — spacing and alignment create visual grouping naturally
-- Use cards only when content is truly distinct and actionable — never nest cards inside cards
-- Vary card sizes, span columns, or mix cards with non-card content to break repetition
-
-### Strengthen Visual Hierarchy
-
-- Use the fewest dimensions needed for clear hierarchy. Space alone can be enough — generous whitespace around an element draws the eye. Some of the most sophisticated designs achieve rhythm with just space and weight. Add color or size contrast only when simpler means aren't sufficient.
-- Be aware of reading flow — in LTR languages, the eye naturally scans top-left to bottom-right, but primary action placement depends on context (e.g., bottom-right in dialogs, top in navigation).
-- Create clear content groupings through proximity and separation.
-
-### Manage Depth & Elevation
-
-- Create a semantic z-index scale (dropdown → sticky → modal-backdrop → modal → toast → tooltip)
-- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle
-- Use elevation to reinforce hierarchy, not as decoration
-
-### Optical Adjustments
-
-- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.
-
-**NEVER**:
-- Use arbitrary spacing values outside your scale
-- Make all spacing equal — variety creates hierarchy
-- Wrap everything in cards — not everything needs a container
-- Nest cards inside cards — use spacing and dividers for hierarchy within
-- Use identical card grids everywhere (icon + heading + text, repeated)
-- Center everything — left-aligned with asymmetry feels more designed
-- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.
-- Default to CSS Grid when Flexbox would be simpler — use the simplest tool for the job
-- Use arbitrary z-index values (999, 9999) — build a semantic scale
-
-## Verify Layout Improvements
-
-- **Squint test**: Can you identify primary, secondary, and groupings with blurred vision?
-- **Rhythm**: Does the page have a satisfying beat of tight and generous spacing?
-- **Hierarchy**: Is the most important content obvious within 2 seconds?
-- **Breathing room**: Does the layout feel comfortable, not cramped or wasteful?
-- **Consistency**: Is the spacing system applied uniformly?
-- **Responsiveness**: Does the layout adapt gracefully across screen sizes?
-
-Remember: Space is the most underused design tool. A layout with the right rhythm and hierarchy can make even simple content feel polished and intentional.
\ No newline at end of file
diff --git a/.trae/skills/audit/SKILL.md b/.trae/skills/audit/SKILL.md
index 313959a02..1bbcb2693 100644
--- a/.trae/skills/audit/SKILL.md
+++ b/.trae/skills/audit/SKILL.md
@@ -108,7 +108,7 @@ For each issue, document:
 - **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, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command to use (prefer: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 ### Patterns & Systemic Issues
 
@@ -127,7 +127,7 @@ 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, /shape, /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.
+**Rules**: Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /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:
 
diff --git a/.trae/skills/critique/SKILL.md b/.trae/skills/critique/SKILL.md
index 8a86bd133..075081b3f 100644
--- a/.trae/skills/critique/SKILL.md
+++ b/.trae/skills/critique/SKILL.md
@@ -143,7 +143,7 @@ For each issue, tag with **P0-P3 severity** (consult [heuristics-scoring](refere
 - **[P?] What**: Name the problem clearly
 - **Why it matters**: How this hurts users or undermines goals
 - **Fix**: What to do about it (be concrete)
-- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive)
+- **Suggested command**: Which command could address this (from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive)
 
 #### Persona Red Flags
 > *Consult [personas](reference/personas.md)*
@@ -208,7 +208,7 @@ List recommended commands in priority order, based on the user's answers:
 ...
 
 **Rules for recommendations**:
-- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /distill, /delight, /onboard, /normalize, /audit, /harden, /polish, /extract, /bolder, /arrange, /typeset, /critique, /colorize, /overdrive
+- Only recommend commands from: /animate, /quieter, /shape, /optimize, /adapt, /clarify, /layout, /distill, /delight, /audit, /harden, /polish, /bolder, /typeset, /critique, /colorize, /overdrive
 - Order by the user's stated priorities first, then by impact
 - Each item's description should carry enough context that the command knows what to focus on
 - Map each Priority Issue to the appropriate command
diff --git a/.trae/skills/extract/SKILL.md b/.trae/skills/extract/SKILL.md
deleted file mode 100644
index 4b57ea396..000000000
--- a/.trae/skills/extract/SKILL.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[target]"
----
-
-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.
\ No newline at end of file
diff --git a/.trae/skills/frontend-design/SKILL.md b/.trae/skills/frontend-design/SKILL.md
deleted file mode 100644
index 459cf0542..000000000
--- a/.trae/skills/frontend-design/SKILL.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-name: frontend-design
-description: DEPRECATED: This skill has been renamed to 'impeccable'. Run /impeccable instead.
----
-
-This skill has been renamed to **impeccable**. All design functionality now lives in the `/impeccable` skill.
-
-Check if the impeccable skill is available:
-- If `/impeccable` exists, use it directly. You can safely inform the user that the `frontend-design` folder is a deprecated leftover and can be deleted.
-- If `/impeccable` does NOT exist, tell the user to update their skills by running `npx impeccable skills update` in their terminal.
-
-Do NOT attempt any design work from this skill. Redirect to `/impeccable` instead.
\ No newline at end of file
diff --git a/.trae/skills/harden/SKILL.md b/.trae/skills/harden/SKILL.md
index d870ddd13..95c9d6366 100644
--- a/.trae/skills/harden/SKILL.md
+++ b/.trae/skills/harden/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: harden
-description: Improve interface resilience through better error handling, i18n support, text overflow handling, and edge case management. Makes interfaces robust and production-ready. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.
+description: Make interfaces production-ready: error handling, empty states, onboarding flows, i18n, text overflow, and edge case management. Use when the user asks to harden, make production-ready, handle edge cases, add error states, design empty states, improve onboarding, or fix overflow and i18n issues.
 user-invocable: true
 argument-hint: "[target]"
 ---
@@ -224,6 +224,40 @@ t('items', { count }) // Handles complex plural rules
 - Feature detection (not browser detection)
 - Test in target browsers
 
+### Onboarding & First-Run Experience
+
+Production-ready features work for first-time users, not just power users. Design the paths that get new users to value:
+
+**Empty states**: Every zero-data screen needs:
+- What will appear here (description or illustration)
+- Why it matters to the user
+- Clear CTA to create the first item or start from a template
+- Visual interest (not just blank space with "No items yet")
+
+Empty state types to handle:
+- **First use**: emphasize value, provide templates
+- **User cleared**: light touch, easy to recreate
+- **No results**: suggest a different query, offer to clear filters
+- **No permissions**: explain why, how to get access
+
+**First-run experience**: Get users to their "aha moment" as quickly as possible.
+- Show, don't tell -- working examples over descriptions
+- Progressive disclosure -- teach one thing at a time, not everything upfront
+- Make onboarding optional -- let experienced users skip
+- Provide smart defaults so required setup is minimal
+
+**Feature discovery**: Teach features when users need them, not upfront.
+- Contextual tooltips at point of use (brief, dismissable, one-time)
+- Badges or indicators on new or unused features
+- Celebrate activation events quietly (a toast, not a modal)
+
+**NEVER**:
+- Force long onboarding before users can touch the product
+- Show the same tooltip repeatedly (track and respect dismissals)
+- Block the entire UI during a guided tour
+- Create separate tutorial modes disconnected from the real product
+- Design empty states that just say "No items" with no next action
+
 ### Input Validation & Sanitization
 
 **Client-side validation**:
diff --git a/.trae/skills/impeccable/SKILL.md b/.trae/skills/impeccable/SKILL.md
index 784258b53..0830286d9 100644
--- a/.trae/skills/impeccable/SKILL.md
+++ b/.trae/skills/impeccable/SKILL.md
@@ -1,11 +1,21 @@
 ---
 name: impeccable
-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. Call with 'craft' to run the full shape-then-build flow, or 'teach' for design context setup.
+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. Call with 'craft' for shape-then-build, 'teach' for design context setup, or 'extract' to pull reusable components and tokens into the design system.
 user-invocable: true
-argument-hint: "[craft|teach]"
+argument-hint: "[craft|teach|extract]"
 license: Apache 2.0. Based on Anthropic's frontend-design skill. See NOTICE.md for attribution.
 ---
 
+<post-update-cleanup>
+BEFORE doing any design work, silently run this cleanup script to remove deprecated skill files from previous Impeccable versions:
+
+```bash
+node {{scripts_path}}/cleanup-deprecated.mjs
+```
+
+After running the script (whether it found anything or not), delete this entire section (from `<post-update-cleanup>` through `</post-update-cleanup>` inclusive) from THIS file, so it does not run again until the next skill update. Save the file after deleting the section.
+</post-update-cleanup>
+
 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
@@ -95,7 +105,7 @@ Instrument Sans
 Instrument Serif
 </reflex_fonts_to_reject>
 
-Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. **Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.**
+Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects.
 
 Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a *physical object* — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
 
@@ -108,7 +118,6 @@ DO vary font weights and sizes to create clear visual hierarchy.
 DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
 
 DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further.
-DO NOT use Syne. Ever. It is an instant AI design tell.
 DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes.
 DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated.
 DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font.
@@ -340,4 +349,10 @@ Write this section to `.impeccable.md` in the project root. If the file already
 
 Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to RULES.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.
\ No newline at end of file
+Confirm completion and summarize the key design principles that will now guide all future work.
+
+---
+
+## Extract Mode
+
+If this skill is invoked with the argument "extract" (e.g., `/impeccable extract [target]`), follow the [extract flow](reference/extract.md). Pass any additional arguments as the extraction target.
\ No newline at end of file
diff --git a/.trae/skills/impeccable/reference/extract.md b/.trae/skills/impeccable/reference/extract.md
new file mode 100644
index 000000000..d84f9cce1
--- /dev/null
+++ b/.trae/skills/impeccable/reference/extract.md
@@ -0,0 +1,70 @@
+# Extract Flow
+
+Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
+
+## Step 1: Discover the Design System
+
+Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
+
+**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
+
+## Step 2: Identify Patterns
+
+Look for extraction opportunities in the target area:
+
+- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
+- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
+- **Inconsistent variations**: Multiple implementations of the same concept
+- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
+- **Type styles**: Repeated font-size + weight + line-height combinations
+- **Animation patterns**: Repeated easing, duration, or keyframe combinations
+
+Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
+
+## Step 3: Plan Extraction
+
+Create a systematic 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 is clearly reusable now, not everything that might someday be reusable.
+
+## Step 4: Extract & Enrich
+
+Build improved, reusable versions:
+
+- **Components**: 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**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
+- **Patterns**: When to use this pattern, code examples, variations and combinations
+
+## Step 5: Migrate
+
+Replace existing uses with the new shared versions:
+
+- **Find all instances**: Search for the patterns you 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
+
+## Step 6: 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
+
+**NEVER**:
+- Extract one-off, context-specific implementations without generalization
+- Create components so generic they are 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)
+- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
+
+Remember: A good design system is a living system. Extract patterns as they emerge, enrich them thoughtfully, and maintain them consistently.
diff --git a/.trae/skills/layout/SKILL.md b/.trae/skills/layout/SKILL.md
new file mode 100644
index 000000000..5567238e9
--- /dev/null
+++ b/.trae/skills/layout/SKILL.md
@@ -0,0 +1,124 @@
+---
+name: layout
+description: Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
+user-invocable: true
+argument-hint: "[target]"
+---
+
+Assess and improve layout and spacing that feels monotonous, crowded, or structurally weak — turning generic arrangements into intentional, rhythmic compositions.
+
+## MANDATORY PREPARATION
+
+Invoke /impeccable — 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 /impeccable teach first.
+
+---
+
+## Assess Current Layout
+
+Analyze what's weak about the current spatial design:
+
+1. **Spacing**:
+   - Is spacing consistent or arbitrary? (Random padding/margin values)
+   - Is all spacing the same? (Equal padding everywhere = no rhythm)
+   - Are related elements grouped tightly, with generous space between groups?
+
+2. **Visual hierarchy**:
+   - Apply the squint test: blur your (metaphorical) eyes — can you still identify the most important element, second most important, and clear groupings?
+   - Is hierarchy achieved effectively? (Space and weight alone can be enough — but is the current approach working?)
+   - Does whitespace guide the eye to what matters?
+
+3. **Grid & structure**:
+   - Is there a clear underlying structure, or does the layout feel random?
+   - Are identical card grids used everywhere? (Icon + heading + text, repeated endlessly)
+   - Is everything centered? (Left-aligned with asymmetric layouts feels more designed, but not a hard and fast rule)
+
+4. **Rhythm & variety**:
+   - Does the layout have visual rhythm? (Alternating tight/generous spacing)
+   - Is every section structured the same way? (Monotonous repetition)
+   - Are there intentional moments of surprise or emphasis?
+
+5. **Density**:
+   - Is the layout too cramped? (Not enough breathing room)
+   - Is the layout too sparse? (Excessive whitespace without purpose)
+   - Does density match the content type? (Data-dense UIs need tighter spacing; marketing pages need more air)
+
+**CRITICAL**: Layout problems are often the root cause of interfaces feeling "off" even when colors and fonts are fine. Space is a design material — use it with intention.
+
+## Plan Layout Improvements
+
+Consult the [spatial design reference](reference/spatial-design.md) from the impeccable skill for detailed guidance on grids, rhythm, and container queries.
+
+Create a systematic plan:
+
+- **Spacing system**: Use a consistent scale — whether that's a framework's built-in scale (e.g., Tailwind), rem-based tokens, or a custom system. The specific values matter less than consistency.
+- **Hierarchy strategy**: How will space communicate importance?
+- **Layout approach**: What structure fits the content? Flex for 1D, Grid for 2D, named areas for complex page layouts.
+- **Rhythm**: Where should spacing be tight vs generous?
+
+## Improve Layout Systematically
+
+### Establish a Spacing System
+
+- Use a consistent spacing scale — framework scales (Tailwind, etc.), rem-based tokens, or a custom scale all work. What matters is that values come from a defined set, not arbitrary numbers.
+- Name tokens semantically if using custom properties: `--space-xs` through `--space-xl`, not `--spacing-8`
+- Use `gap` for sibling spacing instead of margins — eliminates margin collapse hacks
+- Apply `clamp()` for fluid spacing that breathes on larger screens
+
+### Create Visual Rhythm
+
+- **Tight grouping** for related elements (8-12px between siblings)
+- **Generous separation** between distinct sections (48-96px)
+- **Varied spacing** within sections — not every row needs the same gap
+- **Asymmetric compositions** — break the predictable centered-content pattern when it makes sense
+
+### Choose the Right Layout Tool
+
+- **Use Flexbox for 1D layouts**: Rows of items, nav bars, button groups, card contents, most component internals. Flex is simpler and more appropriate for the majority of layout tasks.
+- **Use Grid for 2D layouts**: Page-level structure, dashboards, data-dense interfaces, anything where rows AND columns need coordinated control.
+- **Don't default to Grid** when Flexbox with `flex-wrap` would be simpler and more flexible.
+- Use `repeat(auto-fit, minmax(280px, 1fr))` for responsive grids without breakpoints.
+- Use named grid areas (`grid-template-areas`) for complex page layouts — redefine at breakpoints.
+
+### Break Card Grid Monotony
+
+- Don't default to card grids for everything — spacing and alignment create visual grouping naturally
+- Use cards only when content is truly distinct and actionable — never nest cards inside cards
+- Vary card sizes, span columns, or mix cards with non-card content to break repetition
+
+### Strengthen Visual Hierarchy
+
+- Use the fewest dimensions needed for clear hierarchy. Space alone can be enough — generous whitespace around an element draws the eye. Some of the most sophisticated designs achieve rhythm with just space and weight. Add color or size contrast only when simpler means aren't sufficient.
+- Be aware of reading flow — in LTR languages, the eye naturally scans top-left to bottom-right, but primary action placement depends on context (e.g., bottom-right in dialogs, top in navigation).
+- Create clear content groupings through proximity and separation.
+
+### Manage Depth & Elevation
+
+- Create a semantic z-index scale (dropdown → sticky → modal-backdrop → modal → toast → tooltip)
+- Build a consistent shadow scale (sm → md → lg → xl) — shadows should be subtle
+- Use elevation to reinforce hierarchy, not as decoration
+
+### Optical Adjustments
+
+- If an icon looks visually off-center despite being geometrically centered, nudge it — but only if you're confident it actually looks wrong. Don't adjust speculatively.
+
+**NEVER**:
+- Use arbitrary spacing values outside your scale
+- Make all spacing equal — variety creates hierarchy
+- Wrap everything in cards — not everything needs a container
+- Nest cards inside cards — use spacing and dividers for hierarchy within
+- Use identical card grids everywhere (icon + heading + text, repeated)
+- Center everything — left-aligned with asymmetry feels more designed
+- Default to the hero metric layout (big number, small label, stats, gradient) as a template. If showing real user data, a prominent metric can work — but it should display actual data, not decorative numbers.
+- Default to CSS Grid when Flexbox would be simpler — use the simplest tool for the job
+- Use arbitrary z-index values (999, 9999) — build a semantic scale
+
+## Verify Layout Improvements
+
+- **Squint test**: Can you identify primary, secondary, and groupings with blurred vision?
+- **Rhythm**: Does the page have a satisfying beat of tight and generous spacing?
+- **Hierarchy**: Is the most important content obvious within 2 seconds?
+- **Breathing room**: Does the layout feel comfortable, not cramped or wasteful?
+- **Consistency**: Is the spacing system applied uniformly?
+- **Responsiveness**: Does the layout adapt gracefully across screen sizes?
+
+Remember: Space is the most underused design tool. A layout with the right rhythm and hierarchy can make even simple content feel polished and intentional.
\ No newline at end of file
diff --git a/.trae/skills/normalize/SKILL.md b/.trae/skills/normalize/SKILL.md
deleted file mode 100644
index cbc512296..000000000
--- a/.trae/skills/normalize/SKILL.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-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.
-user-invocable: true
-argument-hint: "[feature (page, route, component...)]"
----
-
-Analyze and redesign the feature to perfectly match our design system standards, aesthetics, and established patterns.
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach 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.
\ No newline at end of file
diff --git a/.trae/skills/onboard/SKILL.md b/.trae/skills/onboard/SKILL.md
deleted file mode 100644
index 01a1d2dd6..000000000
--- a/.trae/skills/onboard/SKILL.md
+++ /dev/null
@@ -1,245 +0,0 @@
----
-name: onboard
-description: Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
-user-invocable: true
-argument-hint: "[target]"
----
-
-## MANDATORY PREPARATION
-
-Invoke /impeccable — 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 /impeccable teach first. Additionally gather: the "aha moment" you want users to reach, and users' experience level.
-
----
-
-Create or improve onboarding experiences that help users understand, adopt, and succeed with the product quickly.
-
-## Assess Onboarding Needs
-
-Understand what users need to learn and why:
-
-1. **Identify the challenge**:
-   - What are users trying to accomplish?
-   - What's confusing or unclear about current experience?
-   - Where do users get stuck or drop off?
-   - What's the "aha moment" we want users to reach?
-
-2. **Understand the users**:
-   - What's their experience level? (Beginners, power users, mixed?)
-   - What's their motivation? (Excited and exploring? Required by work?)
-   - What's their time commitment? (5 minutes? 30 minutes?)
-   - What alternatives do they know? (Coming from competitor? New to category?)
-
-3. **Define success**:
-   - What's the minimum users need to learn to be successful?
-   - What's the key action we want them to take? (First project? First invite?)
-   - How do we know onboarding worked? (Completion rate? Time to value?)
-
-**CRITICAL**: Onboarding should get users to value as quickly as possible, not teach everything possible.
-
-## Onboarding Principles
-
-Follow these core principles:
-
-### Show, Don't Tell
-- Demonstrate with working examples, not just descriptions
-- Provide real functionality in onboarding, not separate tutorial mode
-- Use progressive disclosure - teach one thing at a time
-
-### Make It Optional (When Possible)
-- Let experienced users skip onboarding
-- Don't block access to product
-- Provide "Skip" or "I'll explore on my own" options
-
-### Time to Value
-- Get users to their "aha moment" ASAP
-- Front-load most important concepts
-- Teach 20% that delivers 80% of value
-- Save advanced features for contextual discovery
-
-### Context Over Ceremony
-- Teach features when users need them, not upfront
-- Empty states are onboarding opportunities
-- Tooltips and hints at point of use
-
-### Respect User Intelligence
-- Don't patronize or over-explain
-- Be concise and clear
-- Assume users can figure out standard patterns
-
-## Design Onboarding Experiences
-
-Create appropriate onboarding for the context:
-
-### Initial Product Onboarding
-
-**Welcome Screen**:
-- Clear value proposition (what is this product?)
-- What users will learn/accomplish
-- Time estimate (honest about commitment)
-- Option to skip (for experienced users)
-
-**Account Setup**:
-- Minimal required information (collect more later)
-- Explain why you're asking for each piece of information
-- Smart defaults where possible
-- Social login when appropriate
-
-**Core Concept Introduction**:
-- Introduce 1-3 core concepts (not everything)
-- Use simple language and examples
-- Interactive when possible (do, don't just read)
-- Progress indication (step 1 of 3)
-
-**First Success**:
-- Guide users to accomplish something real
-- Pre-populated examples or templates
-- Celebrate completion (but don't overdo it)
-- Clear next steps
-
-### Feature Discovery & Adoption
-
-**Empty States**:
-Instead of blank space, show:
-- What will appear here (description + screenshot/illustration)
-- Why it's valuable
-- Clear CTA to create first item
-- Example or template option
-
-Example:
-```
-No projects yet
-Projects help you organize your work and collaborate with your team.
-[Create your first project] or [Start from template]
-```
-
-**Contextual Tooltips**:
-- Appear at relevant moment (first time user sees feature)
-- Point directly at relevant UI element
-- Brief explanation + benefit
-- Dismissable (with "Don't show again" option)
-- Optional "Learn more" link
-
-**Feature Announcements**:
-- Highlight new features when they're released
-- Show what's new and why it matters
-- Let users try immediately
-- Dismissable
-
-**Progressive Onboarding**:
-- Teach features when users encounter them
-- Badges or indicators on new/unused features
-- Unlock complexity gradually (don't show all options immediately)
-
-### Guided Tours & Walkthroughs
-
-**When to use**:
-- Complex interfaces with many features
-- Significant changes to existing product
-- Industry-specific tools needing domain knowledge
-
-**How to design**:
-- Spotlight specific UI elements (dim rest of page)
-- Keep steps short (3-7 steps max per tour)
-- Allow users to click through tour freely
-- Include "Skip tour" option
-- Make replayable (help menu)
-
-**Best practices**:
-- Interactive > passive (let users click real buttons)
-- Focus on workflow, not features ("Create a project" not "This is the project button")
-- Provide sample data so actions work
-
-### Interactive Tutorials
-
-**When to use**:
-- Users need hands-on practice
-- Concepts are complex or unfamiliar
-- High stakes (better to practice in safe environment)
-
-**How to design**:
-- Sandbox environment with sample data
-- Clear objectives ("Create a chart showing sales by region")
-- Step-by-step guidance
-- Validation (confirm they did it right)
-- Graduation moment (you're ready!)
-
-### Documentation & Help
-
-**In-product help**:
-- Contextual help links throughout interface
-- Keyboard shortcut reference
-- Search-able help center
-- Video tutorials for complex workflows
-
-**Help patterns**:
-- `?` icon near complex features
-- "Learn more" links in tooltips
-- Keyboard shortcut hints (`⌘K` shown on search box)
-
-## Empty State Design
-
-Every empty state needs:
-
-### What Will Be Here
-"Your recent projects will appear here"
-
-### Why It Matters  
-"Projects help you organize your work and collaborate with your team"
-
-### How to Get Started
-[Create project] or [Import from template]
-
-### Visual Interest
-Illustration or icon (not just text on blank page)
-
-### Contextual Help
-"Need help getting started? [Watch 2-min tutorial]"
-
-**Empty state types**:
-- **First use**: Never used this feature (emphasize value, provide template)
-- **User cleared**: Intentionally deleted everything (light touch, easy to recreate)
-- **No results**: Search or filter returned nothing (suggest different query, clear filters)
-- **No permissions**: Can't access (explain why, how to get access)
-- **Error state**: Failed to load (explain what happened, retry option)
-
-## Implementation Patterns
-
-### Technical approaches:
-
-**Tooltip libraries**: Tippy.js, Popper.js
-**Tour libraries**: Intro.js, Shepherd.js, React Joyride
-**Modal patterns**: Focus trap, backdrop, ESC to close
-**Progress tracking**: LocalStorage for "seen" states
-**Analytics**: Track completion, drop-off points
-
-**Storage patterns**:
-```javascript
-// Track which onboarding steps user has seen
-localStorage.setItem('onboarding-completed', 'true');
-localStorage.setItem('feature-tooltip-seen-reports', 'true');
-```
-
-**IMPORTANT**: Don't show same onboarding twice (annoying). Track completion and respect dismissals.
-
-**NEVER**:
-- Force users through long onboarding before they can use product
-- Patronize users with obvious explanations
-- Show same tooltip repeatedly (respect dismissals)
-- Block all UI during tour (let users explore)
-- Create separate tutorial mode disconnected from real product
-- Overwhelm with information upfront (progressive disclosure!)
-- Hide "Skip" or make it hard to find
-- Forget about returning users (don't show initial onboarding again)
-
-## Verify Onboarding Quality
-
-Test with real users:
-
-- **Time to completion**: Can users complete onboarding quickly?
-- **Comprehension**: Do users understand after completing?
-- **Action**: Do users take desired next step?
-- **Skip rate**: Are too many users skipping? (Maybe it's too long/not valuable)
-- **Completion rate**: Are users completing? (If low, simplify)
-- **Time to value**: How long until users get first value?
-
-Remember: You're a product educator with excellent teaching instincts. Get users to their "aha moment" as quickly as possible. Teach the essential, make it contextual, respect user time and intelligence.
\ No newline at end of file
diff --git a/.trae/skills/polish/SKILL.md b/.trae/skills/polish/SKILL.md
index 1e8751a6a..b44930c4e 100644
--- a/.trae/skills/polish/SKILL.md
+++ b/.trae/skills/polish/SKILL.md
@@ -13,6 +13,16 @@ Invoke /impeccable — it contains design principles, anti-patterns, and the **C
 
 Perform a meticulous final pass to catch all the small details that separate good work from great work. The difference between shipped and polished.
 
+## Design System Discovery
+
+Before polishing, understand the system you are polishing toward:
+
+1. **Find the design system**: Search for design system documentation, component libraries, style guides, or token definitions. Study the core patterns: color tokens, spacing scale, typography styles, component API.
+2. **Note the conventions**: How are shared components imported? What spacing scale is used? Which colors come from tokens vs hard-coded values? What motion and interaction patterns are established?
+3. **Identify drift**: Where does the target feature deviate from the system? Hard-coded values that should be tokens, custom components that duplicate shared ones, spacing that doesn't match the scale.
+
+If a design system exists, polish should align the feature with it. If none exists, polish against the conventions visible in the codebase.
+
 ## Pre-Polish Assessment
 
 Understand the current state and goals:
@@ -188,6 +198,8 @@ Go through systematically:
 - Introduce bugs while polishing (test thoroughly)
 - Ignore systematic issues (if spacing is off everywhere, fix the system)
 - Perfect one thing while leaving others rough (consistent quality level)
+- Create new one-off components when design system equivalents exist
+- Hard-code values that should use design tokens
 
 ## Final Verification
 
@@ -199,4 +211,13 @@ Before marking as done:
 - **Compare to design**: Match intended design
 - **Check all states**: Don't just test happy path
 
+## Clean Up
+
+After polishing, ensure code quality:
+
+- **Replace custom implementations**: If the design system provides a component you reimplemented, switch to the shared version.
+- **Remove orphaned code**: Delete unused styles, components, or files made obsolete by polish.
+- **Consolidate tokens**: If you introduced new values, check whether they should be tokens.
+- **Verify DRYness**: Look for duplication introduced during polishing and consolidate.
+
 Remember: You have impeccable attention to detail and exquisite taste. Polish until it feels effortless, looks intentional, and works flawlessly. Sweat the details - they matter.
\ No newline at end of file
diff --git a/.trae/skills/shape/SKILL.md b/.trae/skills/shape/SKILL.md
index 330b9b02e..1d8652aa9 100644
--- a/.trae/skills/shape/SKILL.md
+++ b/.trae/skills/shape/SKILL.md
@@ -92,4 +92,4 @@ Anything unresolved that the implementer should resolve during build.
 
 ask the user directly to clarify what you cannot infer. Get explicit confirmation of the brief before finishing. If the user disagrees with any part, revisit the relevant discovery questions.
 
-Once confirmed, the brief is complete. The user can now hand it to /impeccable craft to build the feature, or use it to guide any other implementation approach.
\ No newline at end of file
+Once confirmed, the brief is complete. The user can now hand it to /impeccable, or use it to guide any other implementation approach. (If the user wants the full discovery-then-build flow in one step, they should use /impeccable craft instead, which runs this skill internally.)
\ No newline at end of file
diff --git a/.trae/skills/teach-impeccable/SKILL.md b/.trae/skills/teach-impeccable/SKILL.md
deleted file mode 100644
index 4f39eb5ae..000000000
--- a/.trae/skills/teach-impeccable/SKILL.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-name: teach-impeccable
-description: DEPRECATED: Use /impeccable teach instead. This command has been folded into the impeccable skill.
-user-invocable: true
----
-
-This command has been renamed. Run `/impeccable teach` instead.
-
-Do NOT proceed with any teach flow here. Simply inform the user:
-
-> The `/teach-impeccable` command has been renamed to `/impeccable teach`. Please use that instead.
\ No newline at end of file
diff --git a/scripts/build.js b/scripts/build.js
index 53f506101..b0610136a 100644
--- a/scripts/build.js
+++ b/scripts/build.js
@@ -622,6 +622,20 @@ async function build() {
     }
   }
 
+  // Remove deprecated skill stubs from local harness dirs. They exist
+  // in dist/ so the cleanup script can redirect users, but they should
+  // not clutter the repo's own skill directories.
+  const deprecatedLocalSkills = [
+    'frontend-design', 'teach-impeccable',
+    'arrange', 'normalize', 'onboard', 'extract',
+  ];
+  for (const { configDir } of syncConfigs) {
+    for (const name of deprecatedLocalSkills) {
+      const p = path.join(ROOT_DIR, configDir, 'skills', name);
+      if (fs.existsSync(p)) fs.rmSync(p, { recursive: true, force: true });
+    }
+  }
+
   console.log(`📋 Synced skills to: ${syncConfigs.map(p => p.configDir).join(', ')}`);