@friedbotstudio/create-baseline 0.1.0

package/obj/template/.claude/skills/impeccable/reference/typography.md

@@ -0,0 +1,159 @@
+# Typography
+
+## Classic Typography Principles
+
+### Vertical Rhythm
+
+Your line-height should be the base unit for ALL vertical spacing. If body text has `line-height: 1.5` on `16px` type (= 24px), spacing values should be multiples of 24px. This creates subconscious harmony—text and space share a mathematical foundation.
+
+### Modular Scale & Hierarchy
+
+The common mistake: too many font sizes that are too close together (14px, 15px, 16px, 18px...). This creates muddy hierarchy.
+
+**Use fewer sizes with more contrast.** A 5-size system covers most needs:
+
+| Role | Typical Ratio | Use Case |
+|------|---------------|----------|
+| xs | 0.75rem | Captions, legal |
+| sm | 0.875rem | Secondary UI, metadata |
+| base | 1rem | Body text |
+| lg | 1.25-1.5rem | Subheadings, lead text |
+| xl+ | 2-4rem | Headlines, hero text |
+
+Popular ratios: 1.25 (major third), 1.333 (perfect fourth), 1.5 (perfect fifth). Pick one and commit.
+
+### Readability & Measure
+
+Use `ch` units for character-based measure (`max-width: 65ch`). Line-height scales inversely with line length—narrow columns need tighter leading, wide columns need more.
+
+**Non-obvious**: Light text on dark backgrounds needs compensation on three axes, not just one. Bump line-height by 0.05–0.1, add a touch of letter-spacing (0.01–0.02em), and optionally step the body weight up one notch (regular → medium). The perceived weight drops across all three; fix all three.
+
+**Paragraph rhythm**: Pick either space between paragraphs OR first-line indentation. Never both. Digital usually wants space; editorial/long-form can justify indent-only.
+
+## Font Selection & Pairing
+
+The tactical selection procedure and the reflex-reject list live in [reference/brand.md](brand.md) under **Font selection procedure** and **Reflex-reject list** (loaded for brand-register tasks). The rest of this section covers the adjacent knowledge: anti-reflex corrections, system font use, and pairing rules.
+
+### Anti-reflexes worth defending against
+
+- A technical/utilitarian brief does NOT need a serif "for warmth." Most tech tools should look like tech tools.
+- An editorial/premium brief does NOT need the same expressive serif everyone is using right now. Premium can be Swiss-modern, can be neo-grotesque, can be a literal monospace, can be a quiet humanist sans.
+- A children's product does NOT need a rounded display font. Kids' books use real type.
+- A "modern" brief does NOT need a geometric sans. The most modern thing you can do is not use the font everyone else is using.
+
+**System fonts are underrated**: `-apple-system, BlinkMacSystemFont, "Segoe UI", system-ui` looks native, loads instantly, and is highly readable. Consider this for apps where performance > personality.
+
+### Pairing Principles
+
+**The non-obvious truth**: You often don't need a second font. One well-chosen font family in multiple weights creates cleaner hierarchy than two competing typefaces. Only add a second font when you need genuine contrast (e.g., display headlines + body serif).
+
+When pairing, contrast on multiple axes:
+- Serif + Sans (structure contrast)
+- Geometric + Humanist (personality contrast)
+- Condensed display + Wide body (proportion contrast)
+
+**Never pair fonts that are similar but not identical** (e.g., two geometric sans-serifs). They create visual tension without clear hierarchy.
+
+### Web Font Loading
+
+The layout shift problem: fonts load late, text reflows, and users see content jump. Here's the fix:
+
+```css
+/* 1. Use font-display: swap for visibility */
+@font-face {
+  font-family: 'CustomFont';
+  src: url('font.woff2') format('woff2');
+  font-display: swap;
+}
+
+/* 2. Match fallback metrics to minimize shift */
+@font-face {
+  font-family: 'CustomFont-Fallback';
+  src: local('Arial');
+  size-adjust: 105%;        /* Scale to match x-height */
+  ascent-override: 90%;     /* Match ascender height */
+  descent-override: 20%;    /* Match descender depth */
+  line-gap-override: 10%;   /* Match line spacing */
+}
+
+body {
+  font-family: 'CustomFont', 'CustomFont-Fallback', sans-serif;
+}
+```
+
+Tools like [Fontaine](https://github.com/unjs/fontaine) calculate these overrides automatically.
+
+**`swap` vs `optional`**: `swap` shows fallback text immediately and FOUT-swaps when the web font arrives. `optional` uses the fallback if the web font misses a small load budget (~100ms) and avoids the shift entirely. Pick `optional` when zero layout shift matters more than seeing the branded font on slow networks.
+
+**Preload the critical weight only**: typically the regular-weight body font used above the fold. Preloading every weight costs more bandwidth than it saves.
+
+**Variable fonts for 3+ weights or styles**: a single variable font file is usually smaller than three static weight files, gives fractional weight control, and pairs well with `font-optical-sizing: auto`. For 1–2 weights, static is fine.
+
+## Modern Web Typography
+
+### Fluid Type
+
+Fluid typography via `clamp(min, preferred, max)` scales text smoothly with the viewport. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens.
+
+**Use fluid type for**: Headings and display text on marketing/content pages where text dominates the layout and needs to breathe across viewport sizes.
+
+**Use fixed `rem` scales for**: App UIs, dashboards, and data-dense interfaces. No major app design system (Material, Polaris, Primer, Carbon) uses fluid type in product UI — fixed scales with optional breakpoint adjustments give the spatial predictability that container-based layouts need. Body text should also be fixed even on marketing pages, since the size difference across viewports is too small to warrant it.
+
+**Bound your clamp()**: keep `max-size ≤ ~2.5 × min-size`. Wider ratios break the browser's zoom and reflow behaviour and make large viewports feel like the page is shouting.
+
+**Scale container width and font-size together** so effective character measure stays in the 45–75ch band at every viewport. A heading that widens faster than its container drifts out of the comfortable measure at the top end.
+
+### OpenType Features
+
+Most developers don't know these exist. Use them for polish:
+
+```css
+/* Tabular numbers for data alignment */
+.data-table { font-variant-numeric: tabular-nums; }
+
+/* Proper fractions */
+.recipe-amount { font-variant-numeric: diagonal-fractions; }
+
+/* Small caps for abbreviations */
+abbr { font-variant-caps: all-small-caps; }
+
+/* Disable ligatures in code */
+code { font-variant-ligatures: none; }
+
+/* Enable kerning (usually on by default, but be explicit) */
+body { font-kerning: normal; }
+```
+
+Check what features your font supports at [Wakamai Fondue](https://wakamaifondue.com/).
+
+### Rendering polish
+
+```css
+/* Even out heading line lengths (browser picks better break points) */
+h1, h2, h3 { text-wrap: balance; }
+
+/* Reduce orphans and ragged endings in long prose */
+article p { text-wrap: pretty; }
+
+/* Variable fonts: pick the right optical-size master automatically */
+body { font-optical-sizing: auto; }
+```
+
+**ALL-CAPS tracking**: capitals sit too close at default spacing. Add 5–12% letter-spacing (`letter-spacing: 0.05em` to `0.12em`) to short all-caps labels, eyebrows, and small headings. Real small caps (via `font-variant-caps`) need the same treatment, slightly gentler.
+
+## Typography System Architecture
+
+Name tokens semantically (`--text-body`, `--text-heading`), not by value (`--font-size-16`). Include font stacks, size scale, weights, line-heights, and letter-spacing in your token system.
+
+## Accessibility Considerations
+
+Beyond contrast ratios (which are well-documented), consider:
+
+- **Never disable zoom**: `user-scalable=no` breaks accessibility. If your layout breaks at 200% zoom, fix the layout.
+- **Use rem/em for font sizes**: This respects user browser settings. Never `px` for body text.
+- **Minimum 16px body text**: Smaller than this strains eyes and fails WCAG on mobile.
+- **Adequate touch targets**: Text links need padding or line-height that creates 44px+ tap targets.
+
+---
+
+**Avoid**: More than 2-3 font families per project. Skipping fallback font definitions. Ignoring font loading performance (FOUT/FOIT). Using decorative fonts for body text.

package/obj/template/.claude/skills/impeccable/reference/ux-writing.md

@@ -0,0 +1,107 @@
+# UX Writing
+
+## The Button Label Problem
+
+**Never use "OK", "Submit", or "Yes/No".** These are lazy and ambiguous. Use specific verb + object patterns:
+
+| Bad | Good | Why |
+|-----|------|-----|
+| OK | Save changes | Says what will happen |
+| Submit | Create account | Outcome-focused |
+| Yes | Delete message | Confirms the action |
+| Cancel | Keep editing | Clarifies what "cancel" means |
+| Click here | Download PDF | Describes the destination |
+
+**For destructive actions**, name the destruction:
+- "Delete" not "Remove" (delete is permanent, remove implies recoverable)
+- "Delete 5 items" not "Delete selected" (show the count)
+
+## Error Messages: The Formula
+
+Every error message should answer: (1) What happened? (2) Why? (3) How to fix it? Example: "Email address isn't valid. Please include an @ symbol." not "Invalid input".
+
+### Error Message Templates
+
+| Situation | Template |
+|-----------|----------|
+| **Format error** | "[Field] needs to be [format]. Example: [example]" |
+| **Missing required** | "Please enter [what's missing]" |
+| **Permission denied** | "You don't have access to [thing]. [What to do instead]" |
+| **Network error** | "We couldn't reach [thing]. Check your connection and [action]." |
+| **Server error** | "Something went wrong on our end. We're looking into it. [Alternative action]" |
+
+### Don't Blame the User
+
+Reframe errors: "Please enter a date in MM/DD/YYYY format" not "You entered an invalid date".
+
+## Empty States Are Opportunities
+
+Empty states are onboarding moments: (1) Acknowledge briefly, (2) Explain the value of filling it, (3) Provide a clear action. "No projects yet. Create your first one to get started." not just "No items".
+
+## Voice vs Tone
+
+**Voice** is your brand's personality—consistent everywhere.
+**Tone** adapts to the moment.
+
+| Moment | Tone Shift |
+|--------|------------|
+| Success | Celebratory, brief: "Done! Your changes are live." |
+| Error | Empathetic, helpful: "That didn't work. Here's what to try..." |
+| Loading | Reassuring: "Saving your work..." |
+| Destructive confirm | Serious, clear: "Delete this project? This can't be undone." |
+
+**Never use humor for errors.** Users are already frustrated. Be helpful, not cute.
+
+## Writing for Accessibility
+
+**Link text** must have standalone meaning—"View pricing plans" not "Click here". **Alt text** describes information, not the image—"Revenue increased 40% in Q4" not "Chart". Use `alt=""` for decorative images. **Icon buttons** need `aria-label` for screen reader context.
+
+## Writing for Translation
+
+### Plan for Expansion
+
+German text is ~30% longer than English. Allocate space:
+
+| Language | Expansion |
+|----------|-----------|
+| German | +30% |
+| French | +20% |
+| Finnish | +30-40% |
+| Chinese | -30% (fewer chars, but same width) |
+
+### Translation-Friendly Patterns
+
+Keep numbers separate ("New messages: 3" not "You have 3 new messages"). Use full sentences as single strings (word order varies by language). Avoid abbreviations ("5 minutes ago" not "5 mins ago"). Give translators context about where strings appear.
+
+## Consistency: The Terminology Problem
+
+Pick one term and stick with it:
+
+| Inconsistent | Consistent |
+|--------------|------------|
+| Delete / Remove / Trash | Delete |
+| Settings / Preferences / Options | Settings |
+| Sign in / Log in / Enter | Sign in |
+| Create / Add / New | Create |
+
+Build a terminology glossary and enforce it. Variety creates confusion.
+
+## Avoid Redundant Copy
+
+If the heading explains it, the intro is redundant. If the button is clear, don't explain it again. Say it once, say it well.
+
+## Loading States
+
+Be specific: "Saving your draft..." not "Loading...". For long waits, set expectations ("This usually takes 30 seconds") or show progress.
+
+## Confirmation Dialogs: Use Sparingly
+
+Most confirmation dialogs are design failures—consider undo instead. When you must confirm: name the action, explain consequences, use specific button labels ("Delete project" / "Keep project", not "Yes" / "No").
+
+## Form Instructions
+
+Show format with placeholders, not instructions. For non-obvious fields, explain why you're asking.
+
+---
+
+**Avoid**: Jargon without explanation. Blaming users ("You made an error" → "This field is required"). Vague errors ("Something went wrong"). Varying terminology for variety. Humor for errors.

package/obj/template/.claude/skills/impeccable/scripts/cleanup-deprecated.mjs

@@ -0,0 +1,284 @@
+#!/usr/bin/env node
+/**
+ * Cleans up deprecated Impeccable skill files, symlinks, and
+ * skills-lock.json entries left over from previous versions.
+ *
+ * Safe to run repeatedly -- it is a no-op when nothing needs cleaning.
+ *
+ * Usage (from the project root):
+ *   node {{scripts_path}}/cleanup-deprecated.mjs
+ *
+ * What it does:
+ *   1. Finds every harness-specific skills directory (.claude/skills,
+ *      .cursor/skills, .agents/skills, etc.).
+ *   2. For each deprecated skill name (with and without i- prefix),
+ *      checks if the directory exists and its SKILL.md mentions
+ *      "impeccable" (to avoid deleting unrelated user skills).
+ *   3. Deletes confirmed matches (files, directories, or symlinks).
+ *   4. Removes the corresponding entries from skills-lock.json.
+ */
+
+import { existsSync, readFileSync, writeFileSync, rmSync, readdirSync, statSync, lstatSync, unlinkSync } from 'node:fs';
+import { join, resolve } from 'node:path';
+
+// Skills that were renamed, merged, or folded in v2.0, v2.1, and v3.0.
+const DEPRECATED_NAMES = [
+  // v2.0 renames
+  'frontend-design',    // renamed to impeccable
+  'teach-impeccable',   // folded into /impeccable teach
+  // v2.1 merges
+  'arrange',            // renamed to layout
+  'normalize',          // merged into polish
+  'onboard',            // merged into harden
+  'extract',            // merged into /impeccable extract
+  // v3.0 consolidation: all standalone skills -> /impeccable sub-commands
+  'adapt',
+  'animate',
+  'audit',
+  'bolder',
+  'clarify',
+  'colorize',
+  'critique',
+  'delight',
+  'distill',
+  'harden',
+  'layout',
+  'optimize',
+  'overdrive',
+  'polish',
+  'quieter',
+  'shape',
+  'typeset',
+];
+
+// All known harness directories that may contain a skills/ subfolder.
+const HARNESS_DIRS = [
+  '.claude', '.cursor', '.gemini', '.codex', '.agents',
+  '.trae', '.trae-cn', '.pi', '.opencode', '.kiro', '.rovodev',
+];
+
+// Per-skill fingerprints for SKILL.md bodies that never mentioned
+// "impeccable" in their v2.x source. Used as a last-resort match
+// when no skills-lock.json exists and the word heuristic fails.
+// The strings are lifted verbatim from the v2.x frontmatter
+// descriptions, so collisions with hand-written user skills are
+// vanishingly unlikely.
+const SKILL_FINGERPRINTS = {
+  harden: 'Make interfaces production-ready: error handling, empty states',
+  optimize: 'Diagnoses and fixes UI performance across loading speed',
+};
+
+/**
+ * Walk up from startDir until we find a directory that looks like a
+ * project root (has package.json, .git, or skills-lock.json).
+ */
+export function findProjectRoot(startDir = process.cwd()) {
+  let dir = resolve(startDir);
+  const { root } = { root: '/' };
+  while (dir !== root) {
+    if (
+      existsSync(join(dir, 'package.json')) ||
+      existsSync(join(dir, '.git')) ||
+      existsSync(join(dir, 'skills-lock.json'))
+    ) {
+      return dir;
+    }
+    const parent = resolve(dir, '..');
+    if (parent === dir) break;
+    dir = parent;
+  }
+  return resolve(startDir);
+}
+
+/**
+ * Load skills-lock.json from the project root, or null if missing/unreadable.
+ */
+export function loadLock(projectRoot) {
+  const lockPath = join(projectRoot, 'skills-lock.json');
+  if (!existsSync(lockPath)) return null;
+  try {
+    return JSON.parse(readFileSync(lockPath, 'utf-8'));
+  } catch {
+    return null;
+  }
+}
+
+/**
+ * Check whether a skill directory belongs to Impeccable. Three layered
+ * signals, in order of reliability:
+ *   1. Lock source equals "pbakaus/impeccable" (authoritative).
+ *   2. SKILL.md body contains the word "impeccable".
+ *   3. SKILL.md body contains a per-skill fingerprint (for harden and
+ *      optimize, whose v2.x SKILL.md never mentioned the pack name).
+ */
+export function isImpeccableSkill(skillDir, { skillName, lock } = {}) {
+  // 1. Authoritative: the lock file claims this skill is ours.
+  if (skillName && lock?.skills?.[skillName]?.source === 'pbakaus/impeccable') {
+    return true;
+  }
+  const skillMd = join(skillDir, 'SKILL.md');
+  if (!existsSync(skillMd)) return false;
+  let content;
+  try {
+    content = readFileSync(skillMd, 'utf-8');
+  } catch {
+    return false;
+  }
+  // 2. Word-level content heuristic.
+  if (/impeccable/i.test(content)) return true;
+  // 3. Per-skill fingerprint for old skills that never mentioned the pack.
+  //    Strip the i- prefix so both `harden` and `i-harden` resolve to the
+  //    same fingerprint entry.
+  const unprefixed = skillName?.startsWith('i-') ? skillName.slice(2) : skillName;
+  const fingerprint = unprefixed && SKILL_FINGERPRINTS[unprefixed];
+  if (fingerprint && content.includes(fingerprint)) return true;
+  return false;
+}
+
+/**
+ * Build the full list of names to check: each deprecated name, plus
+ * its i-prefixed variant.
+ */
+export function buildTargetNames() {
+  const names = [];
+  for (const name of DEPRECATED_NAMES) {
+    names.push(name);
+    names.push(`i-${name}`);
+  }
+  return names;
+}
+
+/**
+ * Find every skills directory across all harness dirs in the project.
+ * Returns absolute paths that exist on disk.
+ */
+export function findSkillsDirs(projectRoot) {
+  const dirs = [];
+  for (const harness of HARNESS_DIRS) {
+    const candidate = join(projectRoot, harness, 'skills');
+    if (existsSync(candidate)) {
+      dirs.push(candidate);
+    }
+  }
+  return dirs;
+}
+
+/**
+ * Remove deprecated skill directories/symlinks from all harness dirs.
+ * Reads skills-lock.json so the authoritative "source" field can
+ * drive deletion even when SKILL.md never mentions impeccable.
+ * Returns an array of paths that were deleted.
+ */
+export function removeDeprecatedSkills(projectRoot, lock) {
+  if (lock === undefined) lock = loadLock(projectRoot);
+  const targets = buildTargetNames();
+  const skillsDirs = findSkillsDirs(projectRoot);
+  const deleted = [];
+
+  for (const skillsDir of skillsDirs) {
+    for (const name of targets) {
+      const skillPath = join(skillsDir, name);
+
+      // Use lstat to detect symlinks (existsSync follows symlinks and
+      // returns false for dangling ones).
+      let stat;
+      try {
+        stat = lstatSync(skillPath);
+      } catch {
+        continue; // does not exist at all
+      }
+
+      if (stat.isSymbolicLink()) {
+        // Symlink: check the target if it's alive, otherwise treat
+        // dangling symlinks to deprecated names as safe to remove.
+        const targetAlive = existsSync(skillPath);
+        const isMatch = targetAlive
+          ? isImpeccableSkill(skillPath, { skillName: name, lock })
+          : true;
+        if (isMatch) {
+          unlinkSync(skillPath);
+          deleted.push(skillPath);
+        }
+        continue;
+      }
+
+      // Regular directory -- verify it belongs to impeccable
+      if (isImpeccableSkill(skillPath, { skillName: name, lock })) {
+        rmSync(skillPath, { recursive: true, force: true });
+        deleted.push(skillPath);
+      }
+    }
+  }
+
+  return deleted;
+}
+
+/**
+ * Remove deprecated entries from skills-lock.json.
+ * Only removes entries whose source is "pbakaus/impeccable".
+ * Returns the list of removed skill names.
+ */
+export function cleanSkillsLock(projectRoot) {
+  const lockPath = join(projectRoot, 'skills-lock.json');
+  if (!existsSync(lockPath)) return [];
+
+  let lock;
+  try {
+    lock = JSON.parse(readFileSync(lockPath, 'utf-8'));
+  } catch {
+    return [];
+  }
+
+  if (!lock.skills || typeof lock.skills !== 'object') return [];
+
+  const targets = buildTargetNames();
+  const removed = [];
+
+  for (const name of targets) {
+    const entry = lock.skills[name];
+    if (!entry) continue;
+    // Only remove if it belongs to impeccable
+    if (entry.source === 'pbakaus/impeccable') {
+      delete lock.skills[name];
+      removed.push(name);
+    }
+  }
+
+  if (removed.length > 0) {
+    writeFileSync(lockPath, JSON.stringify(lock, null, 2) + '\n', 'utf-8');
+  }
+
+  return removed;
+}
+
+/**
+ * Run the full cleanup. Returns a summary object.
+ *
+ * Order matters: read the lock and delete directories first, then
+ * strip lock entries. Otherwise the authoritative signal is gone by
+ * the time directory deletion runs.
+ */
+export function cleanup(projectRoot) {
+  const root = projectRoot || findProjectRoot();
+  const lock = loadLock(root);
+  const deletedPaths = removeDeprecatedSkills(root, lock);
+  const removedLockEntries = cleanSkillsLock(root);
+  return { deletedPaths, removedLockEntries, projectRoot: root };
+}
+
+// CLI entry point
+if (process.argv[1] && resolve(process.argv[1]) === resolve(new URL(import.meta.url).pathname)) {
+  const result = cleanup();
+  if (result.deletedPaths.length === 0 && result.removedLockEntries.length === 0) {
+    console.log('No deprecated Impeccable skills found. Nothing to clean up.');
+  } else {
+    if (result.deletedPaths.length > 0) {
+      console.log(`Removed ${result.deletedPaths.length} deprecated skill(s):`);
+      for (const p of result.deletedPaths) console.log(`  - ${p}`);
+    }
+    if (result.removedLockEntries.length > 0) {
+      console.log(`Cleaned ${result.removedLockEntries.length} entry/entries from skills-lock.json:`);
+      for (const name of result.removedLockEntries) console.log(`  - ${name}`);
+    }
+  }
+}

package/obj/template/.claude/skills/impeccable/scripts/command-metadata.json

@@ -0,0 +1,94 @@
+{
+  "craft": {
+    "description": "Full shape-then-build flow with visual iteration. Plans the UX with /impeccable shape, loads the right reference files, then builds and iterates visually until the result is delightful. Use when building a new feature end-to-end.",
+    "argumentHint": "[feature description]"
+  },
+  "teach": {
+    "description": "Gathers design context for a project. Runs a short discovery interview and writes PRODUCT.md (strategic: users, brand, principles) and, when code exists to analyze, DESIGN.md (visual: colors, typography, components). Every other command reads these files before doing work. Use once per project.",
+    "argumentHint": ""
+  },
+  "document": {
+    "description": "Generate a DESIGN.md file that captures the current visual design system. Auto-extracts colors, typography, spacing, radii, and component patterns from the codebase, then asks the user to confirm descriptive language for atmosphere and color character. Follows the Google Stitch DESIGN.md format so the file is tool-compatible. Use when you need a visual design spec an AI agent can follow to stay on-brand.",
+    "argumentHint": ""
+  },
+  "extract": {
+    "description": "Pull reusable patterns, components, and design tokens into the design system. Identifies repeated patterns and consolidates them. Use when you have drift across the codebase and want to bring things back to a consistent system.",
+    "argumentHint": "[target]"
+  },
+  "live": {
+    "description": "Interactive live variant mode. Select elements in the browser, pick a design action, and get AI-generated HTML+CSS variants hot-swapped via HMR. Requires a running dev server. Use when you want to visually experiment with design alternatives in real time.",
+    "argumentHint": ""
+  },
+  "adapt": {
+    "description": "Adapt designs to work across different screen sizes, devices, contexts, or platforms. Implements breakpoints, fluid layouts, and touch targets. Use when the user mentions responsive design, mobile layouts, breakpoints, viewport adaptation, or cross-device compatibility.",
+    "argumentHint": "[target] [context (mobile, tablet, print...)]"
+  },
+  "animate": {
+    "description": "Review a feature and enhance it with purposeful animations, micro-interactions, and motion effects that improve usability and delight. Use when the user mentions adding animation, transitions, micro-interactions, motion design, hover effects, or making the UI feel more alive.",
+    "argumentHint": "[target]"
+  },
+  "audit": {
+    "description": "Run technical quality checks across accessibility, performance, theming, responsive design, and anti-patterns. Generates a scored report with P0-P3 severity ratings and actionable plan. Use when the user wants an accessibility check, performance audit, or technical quality review.",
+    "argumentHint": "[area (feature, page, component...)]"
+  },
+  "bolder": {
+    "description": "Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability. Use when the user says the design looks bland, generic, too safe, lacks personality, or wants more visual impact and character.",
+    "argumentHint": "[target]"
+  },
+  "clarify": {
+    "description": "Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.",
+    "argumentHint": "[target]"
+  },
+  "colorize": {
+    "description": "Add strategic color to features that are too monochromatic or lack visual interest, making interfaces more engaging and expressive. Use when the user mentions the design looking gray, dull, lacking warmth, needing more color, or wanting a more vibrant or expressive palette.",
+    "argumentHint": "[target]"
+  },
+  "critique": {
+    "description": "Evaluate design from a UX perspective, assessing visual hierarchy, information architecture, emotional resonance, cognitive load, and overall quality with quantitative scoring, persona-based testing, automated anti-pattern detection, and actionable feedback. Use when the user asks to review, critique, evaluate, or give feedback on a design or component.",
+    "argumentHint": "[area (feature, page, component...)]"
+  },
+  "delight": {
+    "description": "Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful. Use when the user asks to add polish, personality, animations, micro-interactions, delight, or make an interface feel fun or memorable.",
+    "argumentHint": "[target]"
+  },
+  "distill": {
+    "description": "Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean. Use when the user asks to simplify, declutter, reduce noise, remove elements, or make a UI cleaner and more focused.",
+    "argumentHint": "[target]"
+  },
+  "harden": {
+    "description": "Make interfaces production-ready: error handling, i18n, text overflow, edge case management, and resilience under real-world data. Use when the user asks to harden, make production-ready, handle edge cases, add error states, or fix overflow and i18n issues.",
+    "argumentHint": "[target]"
+  },
+  "onboard": {
+    "description": "Design onboarding flows, first-run experiences, and empty states that guide new users to value. Covers welcome screens, account setup, progressive disclosure, contextual tooltips, feature announcements, and activation moments. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, new user flows, or the aha moment.",
+    "argumentHint": "[target]"
+  },
+  "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.",
+    "argumentHint": "[target]"
+  },
+  "optimize": {
+    "description": "Diagnoses and fixes UI performance across loading speed, rendering, animations, images, and bundle size. Use when the user mentions slow, laggy, janky, performance, bundle size, load time, or wants a faster, smoother experience.",
+    "argumentHint": "[target]"
+  },
+  "overdrive": {
+    "description": "Pushes interfaces past conventional limits with technically ambitious implementations — shaders, spring physics, scroll-driven reveals, 60fps animations. Use when the user wants to wow, impress, go all-out, or make something that feels extraordinary.",
+    "argumentHint": "[target]"
+  },
+  "polish": {
+    "description": "Performs a final quality pass fixing alignment, spacing, consistency, and micro-detail issues before shipping. Use when the user mentions polish, finishing touches, pre-launch review, something looks off, or wants to go from good to great.",
+    "argumentHint": "[target]"
+  },
+  "quieter": {
+    "description": "Tones down visually aggressive or overstimulating designs, reducing intensity while preserving quality. Use when the user mentions too bold, too loud, overwhelming, aggressive, garish, or wants a calmer, more refined aesthetic.",
+    "argumentHint": "[target]"
+  },
+  "shape": {
+    "description": "Plan the UX and UI for a feature before writing code. Runs a structured discovery interview, then produces a design brief that guides implementation. Use during the planning phase to establish design direction, constraints, and strategy before any code is written.",
+    "argumentHint": "[feature to shape]"
+  },
+  "typeset": {
+    "description": "Improves typography by fixing font choices, hierarchy, sizing, weight, and readability so text feels intentional. Use when the user mentions fonts, type, readability, text hierarchy, sizing looks off, or wants more polished, intentional typography.",
+    "argumentHint": "[target]"
+  }
+}