monomind 2.7.9 → 2.7.11

package/packages/@monomind/cli/.claude/skills/monodesign/reference/audit.md

@@ -1,135 +0,0 @@
-Run systematic **technical** quality checks and generate a comprehensive report. Don't fix issues; document them for other commands to address.
-
-This is a code-level audit, not a design critique. Check what's measurable and verifiable in the implementation.
-
-**Web only.** Native platforms (`ios` / `android` / `adaptive`) route to [audit.native.md](audit.native.md) instead; if the project is native, switch to it now.
-
-## Diagnostic Scan
-
-Run comprehensive checks across 5 dimensions. Score each dimension 0-4 using the criteria below.
-
-### 1. Accessibility (A11y)
-
-**Check for**:
-- **Contrast issues**: Text contrast ratios < 4.5:1 (or 7:1 for AAA)
-- **Missing ARIA**: Interactive elements without proper roles, labels, or states
-- **Keyboard navigation**: Missing focus indicators, illogical tab order, keyboard traps
-- **Semantic HTML**: Improper heading hierarchy, missing landmarks, divs instead of buttons
-- **Alt text**: Missing or poor image descriptions
-- **Form issues**: Inputs without labels, poor error messaging, missing required indicators
-
-**Score 0-4**: 0=Inaccessible (fails WCAG A), 1=Major gaps (few ARIA labels, no keyboard nav), 2=Partial (some a11y effort, significant gaps), 3=Good (WCAG AA mostly met, minor gaps), 4=Excellent (WCAG AA fully met, approaches AAA)
-
-### 2. Performance
-
-**Check for**:
-- **Layout thrashing**: Reading/writing layout properties in loops
-- **Expensive animations**: Casual layout-property animation, unbounded blur/filter/shadow effects, or effects that visibly drop frames
-- **Missing optimization**: Images without lazy loading, unoptimized assets, missing will-change
-- **Bundle size**: Unnecessary imports, unused dependencies
-- **Render performance**: Unnecessary re-renders, missing memoization
-
-**Score 0-4**: 0=Severe issues (layout thrash, unoptimized everything), 1=Major problems (no lazy loading, expensive animations), 2=Partial (some optimization, gaps remain), 3=Good (mostly optimized, minor improvements possible), 4=Excellent (fast, lean, well-optimized)
-
-### 3. Theming
-
-**Check for**:
-- **Hard-coded colors**: Colors not using design tokens
-- **Broken dark mode**: Missing dark mode variants, poor contrast in dark theme
-- **Inconsistent tokens**: Using wrong tokens, mixing token types
-- **Theme switching issues**: Values that don't update on theme change
-
-**Score 0-4**: 0=No theming (hard-coded everything), 1=Minimal tokens (mostly hard-coded), 2=Partial (tokens exist but inconsistently used), 3=Good (tokens used, minor hard-coded values), 4=Excellent (full token system, dark mode works perfectly)
-
-### 4. Responsive Design
-
-**Check for**:
-- **Fixed widths**: Hard-coded widths that break on mobile
-- **Touch targets**: Interactive elements < 44x44px
-- **Horizontal scroll**: Content overflow on narrow viewports
-- **Text scaling**: Layouts that break when text size increases
-- **Missing breakpoints**: No mobile/tablet variants
-
-**Score 0-4**: 0=Desktop-only (breaks on mobile), 1=Major issues (some breakpoints, many failures), 2=Partial (works on mobile, rough edges), 3=Good (responsive, minor touch target or overflow issues), 4=Excellent (fluid, all viewports, proper touch targets)
-
-### 5. Anti-Patterns (CRITICAL)
-
-Check against ALL the **DON'T** guidelines from the parent monodesign skill (already loaded in this context). Look for AI slop tells (AI color palette, gradient text, glassmorphism, hero metrics, card grids, generic fonts) and general design anti-patterns (gray on color, nested cards, bounce easing, redundant copy).
-
-**Score 0-4**: 0=AI slop gallery (5+ tells), 1=Heavy AI aesthetic (3-4 tells), 2=Some tells (1-2 noticeable), 3=Mostly clean (subtle issues only), 4=No AI tells (distinctive, intentional design)
-
-## Generate Report
-
-### Audit Health Score
-
-| # | Dimension | Score | Key Finding |
-|---|-----------|-------|-------------|
-| 1 | Accessibility | ? | [most critical a11y issue or "--"] |
-| 2 | Performance | ? | |
-| 3 | Responsive Design | ? | |
-| 4 | Theming | ? | |
-| 5 | Anti-Patterns | ? | |
-| **Total** | | **??/20** | **[Rating band]** |
-
-**Rating bands**: 18-20 Excellent (minor polish), 14-17 Good (address weak dimensions), 10-13 Acceptable (significant work needed), 6-9 Poor (major overhaul), 0-5 Critical (fundamental issues)
-
-### Anti-Patterns Verdict
-**Start here.** Pass/fail: Does this look AI-generated? List specific tells. Be brutally honest.
-
-### Executive Summary
-- Audit Health Score: **??/20** ([rating band])
-- Total issues found (count by severity: P0/P1/P2/P3)
-- Top 3-5 critical issues
-- Recommended next steps
-
-### Detailed Findings by Severity
-
-Tag every issue with **P0-P3 severity**:
-- **P0 Blocking**: Prevents task completion. Fix immediately
-- **P1 Major**: Significant difficulty or WCAG AA violation. Fix before release
-- **P2 Minor**: Annoyance, workaround exists. Fix in next pass
-- **P3 Polish**: Nice-to-fix, no real user impact. Fix if time permits
-
-For each issue, document:
-- **[P?] Issue name**
-- **Location**: Component, file, line
-- **Category**: Accessibility / Performance / Theming / Responsive / Anti-Pattern
-- **Impact**: How it affects users
-- **WCAG/Standard**: Which standard it violates (if applicable)
-- **Recommendation**: How to fix it
-- **Suggested command**: Which command to use (prefer: /monodesign craft, /monodesign init, /monodesign document, /monodesign extract, /monodesign live, /monodesign adapt, /monodesign animate, /monodesign audit, /monodesign bolder, /monodesign clarify, /monodesign colorize, /monodesign critique, /monodesign delight, /monodesign distill, /monodesign harden, /monodesign onboard, /monodesign layout, /monodesign optimize, /monodesign overdrive, /monodesign polish, /monodesign quieter, /monodesign shape, /monodesign typeset)
-
-### Patterns & Systemic Issues
-
-Identify recurring problems that indicate systemic gaps rather than one-off mistakes:
-- "Hard-coded colors appear in 15+ components, should use design tokens"
-- "Touch targets consistently too small (<44px) throughout mobile experience"
-
-### Positive Findings
-
-Note what's working well: good practices to maintain and replicate.
-
-## Recommended Actions
-
-List recommended commands in priority order (P0 first, then P1, then P2):
-
-1. **[P?] `/command-name`**: Brief description (specific context from audit findings)
-2. **[P?] `/command-name`**: Brief description (specific context)
-
-**Rules**: Only recommend commands from: /monodesign craft, /monodesign init, /monodesign document, /monodesign extract, /monodesign live, /monodesign adapt, /monodesign animate, /monodesign audit, /monodesign bolder, /monodesign clarify, /monodesign colorize, /monodesign critique, /monodesign delight, /monodesign distill, /monodesign harden, /monodesign onboard, /monodesign layout, /monodesign optimize, /monodesign overdrive, /monodesign polish, /monodesign quieter, /monodesign shape, /monodesign typeset. Map findings to the most appropriate command. End with `/monodesign polish` as the final step if any fixes were recommended.
-
-After presenting the summary, tell the user:
-
-> You can ask me to run these one at a time, all at once, or in any order you prefer.
->
-> Re-run `/monodesign audit` after fixes to see your score improve.
-
-**IMPORTANT**: Be thorough but actionable. Too many P3 issues creates noise. Focus on what actually matters.
-
-**NEVER**:
-- Report issues without explaining impact (why does this matter?)
-- Provide generic recommendations (be specific and actionable)
-- Skip positive findings (celebrate what works)
-- Forget to prioritize (everything can't be P0)
-- Report false positives without verification
-

package/packages/@monomind/cli/.claude/skills/monodesign/reference/audit.native.md

@@ -1,139 +0,0 @@
-Run systematic **technical** quality checks on a native app (`ios` / `android` / `adaptive`) and generate a comprehensive report. Don't fix issues; document them for other commands to address.
-
-This is a code-level audit, not a design critique. Audit from source (SwiftUI / UIKit / Compose / React Native / Flutter); no browser tooling or `detect.mjs` applies. Score against the platform reference(s): [ios.md](ios.md) / [android.md](android.md), both for `adaptive`. Read them before scoring if Setup hasn't already. The report skeleton mirrors [audit.md](audit.md); keep the two in sync when changing it.
-
-## Diagnostic Scan
-
-Run comprehensive checks across 5 dimensions. Score each dimension 0-4 using the criteria below.
-
-### 1. Accessibility (VoiceOver / TalkBack)
-
-**Check for**:
-- **Missing labels**: interactive elements without accessibility labels, traits/roles, or state announcements
-- **Reading and focus order**: illogical traversal, unreachable controls, focus lost on navigation
-- **Text scaling**: fixed point sizes defeating Dynamic Type (iOS) or px instead of sp (Android); layouts that clip or overlap at large sizes
-- **Touch targets**: below 44 pt (iOS) / 48 dp (Android), or crammed without spacing
-- **Reduce Motion ignored**: parallax and large slides with no crossfade alternative
-- **Contrast**: text failing contrast in either appearance, light or dark
-
-**Score 0-4**: 0=Screen reader unusable, 1=Major gaps (unlabeled controls, no scaling), 2=Partial (labels exist, order or scaling breaks), 3=Good (minor gaps), 4=Excellent (labeled, ordered, scales cleanly, Reduce Motion honored)
-
-### 2. Performance
-
-**Check for**:
-- **Slow startup**: heavy work on launch before first frame
-- **Unvirtualized lists**: long content without FlatList / LazyColumn / List recycling
-- **Main-thread jank**: synchronous work in scroll or gesture paths, dropped frames on 60/120 Hz
-- **Wasted rendering**: unnecessary re-renders (React Native) or recompositions (Compose); missing memoization/keys
-- **Image handling**: full-size images decoded for thumbnails, no caching
-- **App weight**: bloated JS bundle or binary, unused dependencies
-
-**Score 0-4**: 0=Janky everywhere, 1=Major problems (unvirtualized lists, slow launch), 2=Partial, 3=Good (minor improvements possible), 4=Excellent (fast launch, smooth scroll, lean)
-
-### 3. Appearance & Theming
-
-**Check for**:
-- **Hard-coded colors**: raw hex instead of semantic system colors (iOS) / Material color roles (Android) / design tokens
-- **Broken dark appearance**: missing dark variants, poor contrast in dark, quick inverts
-- **Dynamic Color** (Android 12+): no static fallback scheme, or ignored where it fits
-- **Off-platform materials**: hand-rolled blur/glassmorphism instead of system materials or tonal elevation
-
-**Score 0-4**: 0=Hard-coded everything, 1=Minimal tokens, 2=Partial (tokens exist, inconsistently used), 3=Good (minor hard-coded values), 4=Excellent (semantic throughout, both appearances first-class)
-
-### 4. Platform Conformance (CRITICAL)
-
-Score against the loaded platform reference(s), including their slop tests. **Check for**:
-- **Broken system gestures**: edge-swipe back disabled (iOS), predictive Back hijacked (Android)
-- **Inset violations**: content under the notch, Dynamic Island, home indicator, status bar, or keyboard
-- **Off-platform navigation**: custom global nav, overloaded tab bars, iOS patterns on Android or vice versa
-- **Web-shaped controls**: HTML-style buttons, custom toggles, hover-dependent affordances
-- **Icon drift**: mixed icon sets instead of SF Symbols / Material Symbols
-- **AI tells**: the shared absolute bans still apply (AI palette, gradient text, hero metrics)
-
-**Score 0-4**: 0=Web port (nothing native), 1=Heavy violations (3-4 kinds), 2=Some (1-2 noticeable), 3=Mostly conformant (subtle issues), 4=Fully native (a fluent user trusts every screen)
-
-### 5. Adaptivity
-
-**Check for**:
-- **Stretched phone layouts**: tablet/iPad rendering a scaled-up phone UI instead of using size classes / window size classes
-- **Orientation breakage**: landscape clipping, ignored, or locked without reason
-- **Keyboard/IME handling**: inputs hidden behind the keyboard, no inset adjustment
-- **Multitasking**: iPad Split View / Android multi-window breaking layout
-- **Foldables**: hinge-unaware layouts on posture change (Android)
-
-**Score 0-4**: 0=One screen size only, 1=Major breakage (landscape or tablet broken), 2=Partial, 3=Good (minor edge cases), 4=Excellent (adapts across sizes, orientations, and windowing)
-
-## Generate Report
-
-### Audit Health Score
-
-| # | Dimension | Score | Key Finding |
-|---|-----------|-------|-------------|
-| 1 | Accessibility | ? | [most critical issue or "--"] |
-| 2 | Performance | ? | |
-| 3 | Appearance & Theming | ? | |
-| 4 | Platform Conformance | ? | |
-| 5 | Adaptivity | ? | |
-| **Total** | | **??/20** | **[Rating band]** |
-
-**Rating bands**: 18-20 Excellent (minor polish), 14-17 Good (address weak dimensions), 10-13 Acceptable (significant work needed), 6-9 Poor (major overhaul), 0-5 Critical (fundamental issues)
-
-### Platform Conformance Verdict
-**Start here.** Pass/fail: does this read as a native app or a ported website? List specific violations. Be brutally honest.
-
-### Executive Summary
-- Audit Health Score: **??/20** ([rating band])
-- Total issues found (count by severity: P0/P1/P2/P3)
-- Top 3-5 critical issues
-- Recommended next steps
-
-### Detailed Findings by Severity
-
-Tag every issue with **P0-P3 severity**:
-- **P0 Blocking**: Prevents task completion. Fix immediately
-- **P1 Major**: Significant difficulty or platform-guideline violation. Fix before release
-- **P2 Minor**: Annoyance, workaround exists. Fix in next pass
-- **P3 Polish**: Nice-to-fix, no real user impact. Fix if time permits
-
-For each issue, document:
-- **[P?] Issue name**
-- **Location**: Screen, file, line
-- **Category**: Accessibility / Performance / Theming / Conformance / Adaptivity
-- **Impact**: How it affects users
-- **Guideline**: The HIG / Material rule it violates (if applicable)
-- **Recommendation**: How to fix it
-- **Suggested command**: Which command to use (prefer: /monodesign craft, /monodesign init, /monodesign document, /monodesign extract, /monodesign live, /monodesign adapt, /monodesign animate, /monodesign audit, /monodesign bolder, /monodesign clarify, /monodesign colorize, /monodesign critique, /monodesign delight, /monodesign distill, /monodesign harden, /monodesign onboard, /monodesign layout, /monodesign optimize, /monodesign overdrive, /monodesign polish, /monodesign quieter, /monodesign shape, /monodesign typeset)
-
-### Patterns & Systemic Issues
-
-Identify recurring problems that indicate systemic gaps rather than one-off mistakes:
-- "Hard-coded colors appear in 15+ screens, should use semantic colors"
-- "Touch targets consistently below 44 pt throughout the tab bar and list rows"
-
-### Positive Findings
-
-Note what's working well: good practices to maintain and replicate.
-
-## Recommended Actions
-
-List recommended commands in priority order (P0 first, then P1, then P2):
-
-1. **[P?] `/command-name`**: Brief description (specific context from audit findings)
-2. **[P?] `/command-name`**: Brief description (specific context)
-
-**Rules**: Only recommend commands from: /monodesign craft, /monodesign init, /monodesign document, /monodesign extract, /monodesign live, /monodesign adapt, /monodesign animate, /monodesign audit, /monodesign bolder, /monodesign clarify, /monodesign colorize, /monodesign critique, /monodesign delight, /monodesign distill, /monodesign harden, /monodesign onboard, /monodesign layout, /monodesign optimize, /monodesign overdrive, /monodesign polish, /monodesign quieter, /monodesign shape, /monodesign typeset. Map findings to the most appropriate command. End with `/monodesign polish` as the final step if any fixes were recommended.
-
-After presenting the summary, tell the user:
-
-> You can ask me to run these one at a time, all at once, or in any order you prefer.
->
-> Re-run `/monodesign audit` after fixes to see your score improve.
-
-**IMPORTANT**: Be thorough but actionable. Too many P3 issues creates noise. Focus on what actually matters.
-
-**NEVER**:
-- Report issues without explaining impact (why does this matter?)
-- Provide generic recommendations (be specific and actionable)
-- Skip positive findings (celebrate what works)
-- Forget to prioritize (everything can't be P0)
-- Report false positives without verification

package/packages/@monomind/cli/.claude/skills/monodesign/reference/bolder.md

@@ -1,120 +0,0 @@
-When asked for "bolder," AI defaults to the same tired tricks: cyan/purple gradients, glassmorphism, neon accents on dark backgrounds, gradient text on metrics. These are the opposite of bold. Reject them first, then increase visual impact by making the existing design language more decisive, specific, and committed.
-
----
-
-## Register
-
-Brand: "bolder" means distinctive. Express a stronger point of view through hierarchy, pacing, proportion, copy, evidence, and one committed visual idea.
-
-Product: "bolder" rarely means theatrics; those undermine trust. It means stronger hierarchy, clearer weight contrast, sharper information density, and more decisive prioritization. The amplification is in clarity, not drama.
-
----
-
-## Assess Current State
-
-Analyze what makes the design feel too safe or boring:
-
-1. **Identify weakness sources**:
-   - **Generic choices**: The page could belong to any product in the category.
-   - **Timid scale**: Everything is medium-sized with no clear lead.
-   - **Low contrast**: Important and supporting elements have similar visual weight.
-   - **Static**: The surface has no meaningful moment of emphasis.
-   - **Predictable**: The composition follows a default pattern without a point of view.
-   - **Flat hierarchy**: Nothing stands out or commands attention.
-
-2. **Understand the context**:
-   - What is the brand personality?
-   - What is the purpose of this surface?
-   - Who is the audience?
-   - What design system, tokens, components, and visual conventions already exist?
-
-If any of these are unclear from the codebase, STOP and call the AskUserQuestion tool to clarify.
-
-**CRITICAL**: "Bolder" does not mean chaotic or garish. It means distinctive, memorable, and confident. Think intentional drama, not random noise.
-
-**WARNING - AI SLOP TRAP**: Review ALL the DON'T guidelines from the parent monodesign skill (already loaded in this context) before proceeding. Bold means distinctive, not "more effects."
-
-## Design-System Lock
-
-If the project has `DESIGN.md`, tokens, theme variables, or established component styles, treat that system as the boundary. Make the existing language stronger before adding new language.
-
-Do not invent new colors, gradients, radii, shadows, fonts, decorative backgrounds, or effects just because the request says "bolder." A bolder pass should usually change emphasis, proportion, rhythm, density, contrast, copy, artifact specificity, and layout relationships while staying inside the documented system.
-
-If the existing system is genuinely too limited to express the bolder direction, stop and ask the user before expanding it. Name the exact additions, the role each would play, and why the current system cannot do the job. If the user approves expansion, update the design system or tokens alongside the implementation.
-
-## Plan Amplification
-
-Create a strategy to increase impact while maintaining coherence:
-
-- **Focal point**: Pick one thing the viewer should remember, then make the rest support it.
-- **System levers**: Identify which existing tokens, components, layout patterns, and copy structures can carry more weight.
-- **Risk budget**: Decide how far the surface can push while still feeling like the same product or brand.
-- **Hierarchy amplification**: Increase contrast between primary, secondary, and tertiary content instead of making every element louder.
-
-**IMPORTANT**: Bold design must still be usable. Impact without function is just decoration.
-
-## Amplify the Design
-
-Systematically increase impact through intention, not a menu of effects:
-
-### Typography Amplification
-- Strengthen the existing type hierarchy before changing typefaces.
-- Make important text meaningfully more dominant, and make supporting text quieter.
-- Use weight, measure, spacing, and line breaks to sharpen the point of view.
-- Add or replace fonts only after user-approved design-system expansion.
-
-### Color Amplification
-- Use the existing palette more decisively before adding colors.
-- Shift the proportion, placement, and contrast of documented colors to clarify meaning.
-- Treat any new color, gradient, or tint ramp as a design-system expansion that requires user approval.
-- Keep color tied to hierarchy, state, or brand meaning; do not use it as surface decoration.
-
-### Spatial Amplification
-- Change proportion, density, alignment, and sequencing so the composition has a stronger point of view.
-- Create clearer contrast between dense evidence and open breathing room.
-- Let layout express priority and narrative order before adding ornament.
-- Preserve responsive behavior and avoid text overflow at every breakpoint.
-
-### Surface Amplification
-- Use existing surface, border, radius, and shadow rules more deliberately.
-- Remove timid half-measures: either give an element a clear role or simplify it.
-- Add texture, depth, illustration, or decorative treatments only when already established by the system or explicitly approved.
-- Make real product artifacts, imagery, data, or copy carry attention before reaching for effects.
-
-### Motion & Animation
-- Design one meaningful moment of emphasis when motion genuinely supports the point.
-- Make interaction feedback feel more decisive without becoming distracting.
-- Keep transitions smooth and intentional.
-- **Bolder != scroll-fade-rise on every section.** That's the saturated AI default, the opposite of bold.
-
-### Composition Boldness
-- Make the dominant idea unmistakable.
-- Use layout tension, sequencing, contrast, and restraint to create a stronger read.
-- Let the page's structure communicate priority before adding decorative layers.
-- If every element is louder, the composition is not bolder; it is flatter.
-
-**NEVER**:
-- Add undocumented design-system primitives without user approval
-- Add effects randomly without purpose
-- Hide weak hierarchy behind decoration
-- Sacrifice readability for aesthetics
-- Make everything bold; contrast is the point
-- Ignore accessibility
-- Overwhelm with motion
-- Copy trendy aesthetics blindly
-
-## Verify Quality
-
-Ensure amplification maintains usability and coherence:
-
-- **System-faithful**: Did the pass make the existing design language stronger before adding anything new?
-- **No undocumented drift**: Are new colors, gradients, shadows, radii, fonts, and effects either absent or explicitly approved and documented?
-- **NOT AI slop**: Does this look like every other AI-generated "bold" design? If yes, start over.
-- **Still functional**: Can users accomplish tasks without distraction?
-- **Coherent**: Does everything feel intentional and unified?
-- **Memorable**: Will users remember this experience for the intended reason?
-- **Performant and accessible**: Does the result stay fast, readable, responsive, and WCAG-conscious?
-
-**The test**: If you showed this to someone and said "AI made this bolder," would they believe you immediately? If yes, you've failed. Bold means distinctive, not "more AI effects."
-
-When the result feels right, hand off to `/monodesign polish` for the final pass.

package/packages/@monomind/cli/.claude/skills/monodesign/reference/brand-workflow.md

@@ -1,180 +0,0 @@
-# Brand Workflow
-
-How to define, document, and operationalize brand identity for a project. Use when the task involves brand identity work, visual identity guidelines, or establishing a brand-consistent design system from scratch.
-
----
-
-## The Brand Hierarchy
-
-```
-brand-guidelines.md          ← Source of truth (human-readable)
-       ↓
-design-tokens (primitives)   ← Derived color/type values
-       ↓
-semantic tokens              ← Purpose assignments
-       ↓
-component tokens             ← Implementation
-       ↓
-all UI surfaces              ← Consistent brand expression
-```
-
-**The principle:** Every design decision in code should trace back to the brand guidelines. When the guidelines change, only the tokens change — not the components.
-
----
-
-## Step 1: Define Brand Guidelines
-
-Create `BRAND.md` (or `docs/brand-guidelines.md`) as the project's source of truth. Sections to cover:
-
-### Brand Positioning
-- The one sentence that describes what this product is and who it's for
-- Personality: 3 adjectives that describe the brand's character
-- Register: editorial, functional, playful, authoritative, intimate, aspirational?
-
-### Visual Identity
-
-**Color palette** — use OKLCH for all values per the OKLCH-Only Rule:
-```
-Primary (1 color)
-  └── The one vibrant accent (One Voice Rule — no second accent)
-
-Neutrals (3–4 values)
-  ├── Page background (warm, never pure white)
-  ├── Primary text
-  ├── Secondary text
-  └── Borders / dividers
-
-Feedback (system colors)
-  ├── Error
-  ├── Success
-  └── Warning
-```
-
-**Typography**
-```
-Display / Headline  — the editorial voice (personality font)
-Body                — the readable voice (text font)
-Mono                — code / technical content
-
-Rules:
-- line-height: 1.6 for body (non-negotiable)
-- Headings use clamp() fluid sizing
-- Body uses fixed rem
-```
-
-**Shape language**
-- Default border-radius: 0 (sharp/editorial) or N px (softer/friendly)?
-- Is this a brand-register (sharp) or product-register (rounded) surface?
-- Shadow depth: flat-by-default or consistently elevated?
-
-**Motion**
-- Default easing: `cubic-bezier(0.16, 1, 0.3, 1)` (expo-out) for all transitions
-- Duration: 150ms (micro) / 250ms (standard) / 400ms (complex)
-- Always respect `prefers-reduced-motion`
-
-### Brand Voice
-- Tone: formal / conversational / technical / warm?
-- Copy rules: short/punchy vs detailed/thorough? Active/imperative? First/second/third person?
-- What to avoid: jargon? Hedging? Superlatives?
-
----
-
-## Step 2: Derive Token Primitives from Brand
-
-Translate brand guidelines → primitive token values. See `token-architecture.md` for the full three-layer system.
-
-For the **color palette**, verify every token value with the OKLCH color space:
-1. Convert brand colors to OKLCH (tool: oklch.com)
-2. Verify the accent-to-background chroma relationship (warm backgrounds harmonize with warm-hue accents)
-3. Check WCAG contrast: text tokens must pass 4.5:1 against surface tokens
-4. Build the tonal ramp (8 steps from darkest to lightest) for the primary accent
-
-For **typography**, document:
-- Font families and their CDN/license source
-- Exact weight and size values for each type style (see design-principles.md Reference Typography System)
-
----
-
-## Step 3: Sync Brand to Code
-
-Maintain a single-direction sync flow:
-
-```
-BRAND.md  ──(manual review)──→  tokens/primitives.css
-                                 tokens/semantic.css
-                                 tokens/components.css
-```
-
-The sync is intentionally manual for the primitive and semantic layers — these changes are load-bearing and should be reviewed, not automated. Component tokens can be generated.
-
-**Validation checks after any brand update:**
-1. Run WCAG contrast check on all text/surface token pairs
-2. Check all OKLCH values still use OKLCH (not hex/hsl)
-3. Verify there is still exactly one vibrant accent (One Voice Rule)
-4. Verify page background is warm, not pure white (Paper-Not-White Rule)
-
----
-
-## Step 4: Brand Consistency Audit
-
-When auditing an existing product for brand consistency, check:
-
-### Visual consistency
-- [ ] All colors trace to the brand token system — no orphaned hex values in components
-- [ ] Typography scale and weights match the brand spec
-- [ ] Border-radius is consistent with the brand's shape language
-- [ ] The accent color appears on ≤10% of any given screen
-- [ ] No second accent color has crept in
-
-### Voice consistency
-- [ ] Copy tone matches the brand voice guidelines
-- [ ] No hedging language ("we think", "maybe", "might be useful")
-- [ ] CTAs are imperative and clear
-- [ ] Error messages are direct, not apologetic
-
-### Motion consistency
-- [ ] All transitions use the brand easing token (`--ease-out`)
-- [ ] Duration values are from the brand scale (fast/base/slow)
-- [ ] No bounce or elastic easing anywhere
-
----
-
-## Visual Identity Quick Reference
-
-### Logo Usage
-- Use the correct variant for context (primary vs. compact vs. icon-only)
-- Maintain minimum clear space around all logo variants
-- Never stretch, distort, recolor, or add effects
-- Never place on a busy background without a scrim
-
-### Color Usage Ratios (rule of thumb)
-- 60% neutral/background surfaces
-- 30% secondary/supporting tones
-- 10% accent (the one vibrant color)
-
-### Icon System
-- One icon family across the entire product
-- Consistent stroke weight and corner radius
-- Filled vs outline: pick one style per hierarchy level — don't mix
-- All icons have `aria-label` or accompanying visible text
-
-### Photography / Illustration
-- Define the lighting and mood palette (warm / cool / neutral)
-- Establish subject guidelines (people-focused? abstract? product?)
-- Consistent editing style (desaturated / vibrant / duotone?)
-
----
-
-## Brand Register Decision
-
-Before any design session, confirm the **register** of the surface you're designing:
-
-| Register | Characteristics | Shape language | Motion |
-|---|---|---|---|
-| Brand / marketing | Expressive, editorial, emotional | Sharp edges, strong hierarchy | Cinematic, scroll-driven |
-| Product / functional | Efficient, clear, reliable | Slight radius ok, systematic | Micro-interactions, functional |
-| Data / dense | Precise, neutral, information-first | Compact, tabular | Minimal, purposeful |
-
-The register determines which rules are in effect. Italic serif display type is appropriate on a brand surface; embarrassing on a product surface. Glassmorphism on a product surface is decorative noise; on a landing page it can be intentional.
-
-Cross-register failures (product surfaces with brand-surface decoration, or marketing pages with dense product UI) are among the most common and most damaging design mistakes.