@r1z4x/tezgah 1.0.0

package/skills/design-library/inclusive-interaction/skills/gesture-alternatives/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: gesture-alternatives
+description: "Design alternatives to gesture-based and motion-based interactions. Use when designing swipe actions, pinch-to-zoom, shake-to-undo, tilt controls, multi-finger gestures, or any interaction that requires specific physical movements. Triggers on: gesture, swipe, pinch, shake, tilt, multi-touch, two-finger, rotation gesture, device motion, accelerometer, gyroscope."
+---
+
+# Gesture Alternatives
+
+Every gesture-based interaction must have a simpler alternative. Gestures
+that require specific physical movements exclude people with motor
+disabilities, limb differences, tremors, or limited range of motion.
+
+## Core Principle
+
+Gestures are shortcuts, not gatekeepers. The feature they activate must
+always be reachable another way.
+
+## Gesture Types and Required Alternatives
+
+### Path-Based Gestures (swipe, draw, drag)
+These require tracing a specific path. Many users cannot perform them.
+- Swipe to delete → visible delete button
+- Swipe to navigate → previous/next buttons
+- Draw a shape → select from a menu of shapes
+- Drag to reorder → move up/down buttons or numbered input
+
+### Multi-Point Gestures (pinch, rotate, two-finger scroll)
+These require multiple simultaneous contact points.
+- Pinch to zoom → zoom buttons (+/−) and text input for zoom level
+- Two-finger rotate → rotation buttons or degree input
+- Two-finger scroll → single-finger scroll or visible scrollbar
+- Three-finger swipe → visible button or menu option
+
+### Device Motion (shake, tilt, rotation)
+These require moving the entire device.
+- Shake to undo → visible undo button (always)
+- Tilt to steer → on-screen directional controls
+- Device rotation for content → manual rotation toggle
+
+### Timed Gestures (long press, double tap)
+These require precise timing.
+- Long press for context menu → visible menu trigger (⋮ or ⋯)
+- Double tap to zoom → zoom button
+- Press and hold to record → toggle start/stop buttons
+
+## Design Patterns
+
+### Progressive Enhancement
+- Build the button-based version first
+- Add gesture support as an enhancement on top
+- This guarantees the alternative always exists
+
+### Discoverability
+- Gesture shortcuts should be documented but not required
+- Show a hint on first use ("You can also swipe to delete")
+- Provide a gesture guide in settings or help
+- Never assume users know a gesture exists
+
+### Customisation
+- Allow users to disable gesture controls entirely
+- Allow remapping of gestures where possible
+- Respect system-level gesture settings
+
+## Assessment Questions
+
+1. Does every gesture have a visible, single-action alternative?
+2. Can users who cannot perform multi-point gestures complete
+   every task?
+3. Are device-motion interactions optional with on-screen
+   alternatives?
+4. Can timed gestures be replaced with untimed actions?

package/skills/design-library/inclusive-interaction/skills/keyboard-navigation/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: keyboard-navigation
+description: "Design keyboard navigation and focus management for users who cannot or prefer not to use a mouse or touch screen. Use when designing any interactive interface — forms, menus, modals, tabs, carousels, drag-and-drop, data tables, or custom components. Triggers on: keyboard, focus, tab order, focus trap, skip link, arrow keys, keyboard shortcut, can't use mouse, motor disability, switch access, focus indicator, focus ring."
+---
+
+# Keyboard Navigation
+
+Design interactions so that every task can be completed using only a
+keyboard. This is non-negotiable — it's the foundation of all
+interaction accessibility.
+
+## Who This Is For
+
+- People with motor disabilities who cannot use a mouse
+- People using switch devices or mouth sticks
+- Screen reader users (keyboard is their primary input)
+- Power users who prefer keyboard for speed
+- Anyone with a temporarily injured hand or arm
+
+## Core Principles
+
+### Everything Must Be Reachable
+- Every interactive element must be focusable via Tab key
+- Focus order must follow the visual reading order (left to right,
+  top to bottom in LTR languages)
+- No element should be reachable only by mouse hover or click
+- Custom components need explicit tabindex and keyboard handlers
+
+### Focus Must Be Visible
+- Focus indicator must be visible on every interactive element
+- Minimum: 2px solid outline with 3:1 contrast against background
+- Never use outline: none or outline: 0 without a visible replacement
+- Focus style should be consistent across the entire interface
+- Test: can you always see which element is focused?
+
+### Focus Must Be Managed
+- When a modal opens, move focus into the modal
+- When a modal closes, return focus to the element that opened it
+- When content is deleted, move focus to a logical next element
+- When a page section updates dynamically, manage focus appropriately
+- Never trap focus unintentionally (only trap inside open modals)
+
+## Keyboard Patterns by Component
+
+### Navigation Menus
+- Tab moves between top-level items
+- Arrow keys move within a dropdown
+- Enter/Space activates a menu item
+- Escape closes an open dropdown and returns focus to trigger
+
+### Tabs
+- Tab moves to the active tab panel, not through all tabs
+- Arrow keys move between tabs
+- Enter/Space activates a tab (if not automatic)
+
+### Modals / Dialogs
+- Focus moves to first focusable element inside modal on open
+- Tab cycles only within the modal (focus trap)
+- Escape closes the modal
+- Focus returns to trigger element on close
+
+### Forms
+- Tab moves between fields in logical order
+- Error messages are focusable or announced
+- Submit via Enter key on the last field or a visible button
+- Required field indicators are not conveyed by colour alone
+
+### Drag and Drop
+- Always provide a keyboard alternative (move up/down buttons,
+  select-and-place, or arrow key reordering)
+- Announce the current position and available actions
+
+### Carousels / Sliders
+- Arrow keys move between items
+- Provide visible previous/next buttons
+- Pause autoplay on focus or hover
+- Announce current position ("Item 2 of 5")
+
+## Skip Links
+
+Every page should have a "Skip to main content" link as the first
+focusable element. This lets keyboard users bypass repeated navigation.
+
+- Visible on focus (can be visually hidden until focused)
+- Links to the main content area via an anchor
+- Consider additional skip links for long pages ("Skip to search",
+  "Skip to footer")
+
+## Assessment Checklist
+
+- [ ] Every interactive element is reachable via Tab
+- [ ] Focus order matches visual order
+- [ ] Focus indicator is visible on every element (2px, 3:1 contrast)
+- [ ] Modals trap focus and return it on close
+- [ ] All custom components have keyboard handlers
+- [ ] Drag-and-drop has a keyboard alternative
+- [ ] Skip link is present and functional
+- [ ] No keyboard traps exist anywhere in the interface
+- [ ] Dynamic content changes manage focus appropriately

package/skills/design-library/inclusive-interaction/skills/keyboard-review/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: keyboard-review
+description: "Review keyboard navigation and focus management in an existing interface. Chains: keyboard-navigation, feedback-and-status. Use when testing or reviewing keyboard accessibility specifically, before a release, or when users report keyboard issues."
+---
+
+# Keyboard Review
+
+A focused review of keyboard accessibility — the single most important
+interaction requirement. If keyboard doesn't work, screen readers don't
+work, switch devices don't work, and many motor-impaired users are
+completely blocked.
+
+## Process
+
+### Step 1: Tab Through Everything
+Starting from the browser address bar, press Tab repeatedly through
+the entire page. Document:
+- **Unreachable elements** — interactive items that Tab skips
+- **Wrong order** — focus jumps to unexpected locations
+- **Invisible focus** — focus moves but you can't see where it is
+- **Keyboard traps** — focus enters a region and can't leave
+
+### Step 2: Test All Components
+Using **keyboard-navigation**, test each component type present:
+- Menus: Tab to open, Arrow keys to navigate, Escape to close
+- Modals: focus trapped inside, Escape to close, focus returns on close
+- Tabs: Arrow keys between tabs, Tab into panel content
+- Forms: Tab between fields, Enter to submit
+- Custom widgets: appropriate keyboard patterns for the role
+
+### Step 3: Test Dynamic Content
+When content changes on screen:
+- Does focus move to the new content when appropriate?
+- Are screen reader users informed of the change?
+- When content is removed, does focus move to a logical place?
+- Do loading states announce themselves?
+
+Using **feedback-and-status**, verify all dynamic changes are announced
+via aria-live regions or focus management.
+
+### Step 4: Check Skip Links and Landmarks
+- Is "Skip to main content" present and functional?
+- Are ARIA landmarks present (banner, navigation, main, contentinfo)?
+- Can a keyboard user bypass repeated navigation efficiently?
+
+## Output
+
+Deliver a keyboard accessibility report:
+
+1. **Pass/fail summary** — can every task be completed by keyboard?
+2. **Tab order map** — the actual focus sequence with issues marked
+3. **Component results** — pass/fail for each interactive component
+4. **Dynamic content results** — focus management for content changes
+5. **Fix list** — prioritised by severity (blocker, major, minor)

package/skills/design-library/inclusive-interaction/skills/motion-sensitivity/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: motion-sensitivity
+description: "Design for people with vestibular disorders, motion sensitivity, or seizure conditions. Use when designing animations, transitions, parallax scrolling, video backgrounds, carousels, or any moving content. Triggers on: motion, animation, vestibular, motion sickness, dizzy, nausea, parallax, autoplay, flashing, seizure, prefers-reduced-motion, spinning, scrolljacking."
+---
+
+# Motion Sensitivity Design
+
+Design motion that serves function without causing harm. For people with
+vestibular disorders, the wrong animation isn't just annoying — it can
+trigger vertigo, nausea, migraines, or seizures that last hours or days.
+
+## Who This Is For
+
+- People with vestibular disorders (estimated 35% of adults over 40)
+- People with migraine conditions triggered by visual motion
+- People with photosensitive epilepsy (flashing triggers seizures)
+- People experiencing concussion recovery
+- People with anxiety disorders (unexpected motion increases stress)
+- Anyone experiencing motion sickness
+
+## Dangerous Motion to Avoid
+
+### Never Use
+- Flashing content faster than 3 times per second (seizure risk —
+  this is a WCAG Level A requirement, not optional)
+- Large-area flashing in any colour (even at slower rates)
+- Strobing or pulsing effects
+
+### Use With Extreme Caution
+- Parallax scrolling (triggers vestibular responses)
+- Scroll-jacking (overriding native scroll behaviour)
+- Zoom animations that scale the full viewport
+- Spinning or rotating elements
+- Auto-advancing carousels or slideshows
+- Background video
+
+## Design Patterns
+
+### Respect prefers-reduced-motion
+This is the minimum. Non-negotiable.
+
+When prefers-reduced-motion is set:
+- Replace animated transitions with instant state changes
+- Stop all autoplay video and animation
+- Disable parallax effects
+- Disable scroll-triggered animations
+- Keep essential motion only (loading indicators) and simplify them
+
+### Motion Budget
+Not all motion is equal. Allocate motion deliberately:
+- **Essential motion:** loading spinners, progress bars, state
+  transitions that communicate meaning. Keep these but simplify.
+- **Helpful motion:** hover effects, subtle transitions that aid
+  understanding. Keep but make instant when reduced motion is on.
+- **Decorative motion:** background animations, entrance effects,
+  parallax. Remove entirely.
+
+### Safe Animation Principles
+- Keep animations short (under 300ms for transitions)
+- Use opacity and colour changes instead of position changes
+  where possible (less vestibular impact)
+- Avoid animating large areas of the screen simultaneously
+- Provide play/pause controls on all moving content
+- Never autoplay anything — let the user opt in
+
+### Video and Moving Backgrounds
+- Never autoplay with motion — show a static poster image first
+- Provide a visible pause/stop button
+- If background video is used: offer a static alternative
+- Ensure content is fully readable with video paused
+
+## Assessment Questions
+
+1. Does the interface respect prefers-reduced-motion?
+2. Is there any flashing content faster than 3 times per second?
+3. Can all animations be paused, stopped, or hidden?
+4. Does any content autoplay with motion?
+5. Are parallax or scroll-triggered animations present? Do they
+   have a static alternative?

package/skills/design-library/inclusive-interaction/skills/multi-modal-input/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: multi-modal-input
+description: "Design interfaces that offer multiple input methods so users can choose what works for their abilities and context. Use when designing any interactive system where users provide input — forms, search, editors, creative tools, communication interfaces. Triggers on: multi-modal, input methods, alternative input, how people interact, mouse alternative, touch alternative, input flexibility, switch access, eye tracking, head pointer."
+---
+
+# Multi-Modal Input Design
+
+Design systems where users can accomplish any task through whichever
+input method works for them — keyboard, mouse, touch, voice, switch,
+eye tracking, or any combination.
+
+## Core Principle
+
+Never assume how someone will interact with your interface. Offer
+choices. Let the user decide.
+
+## The Input Spectrum
+
+People interact with technology through many methods, often combining
+several at once:
+
+- **Keyboard** — physical, on-screen, or switch-activated
+- **Mouse / trackpad** — standard pointer devices
+- **Touch** — fingers, stylus, or assistive touch
+- **Voice** — speech commands, dictation
+- **Switch devices** — single or dual switches scanning through options
+- **Eye tracking** — gaze-based selection
+- **Head pointers** — head movement controlling a cursor
+- **Sip-and-puff** — breath-controlled switches
+
+## Design Patterns
+
+### Input Equivalence
+- Every action must be possible through at least keyboard AND
+  pointer (mouse/touch)
+- Voice input should be available as a third option where practical
+- Never lock a feature to a single input method
+- Test: can someone complete this task using ONLY keyboard?
+  ONLY touch? ONLY voice?
+
+### Flexible Text Entry
+- Support physical keyboard, on-screen keyboard, voice dictation,
+  and paste from clipboard
+- Auto-complete and suggestions reduce typing burden
+- Don't disable paste in form fields (password managers, assistive
+  tools depend on this)
+- Allow scanning and OCR for filling in reference numbers or codes
+
+### Selection Without Precision
+- Radio buttons and checkboxes: make the label clickable, not just
+  the control
+- Dropdowns: allow type-ahead search for long lists
+- Date pickers: always offer a text field alternative alongside
+  the calendar widget
+- Colour pickers: provide text input for hex/RGB values
+
+### Complex Interactions
+- Drag-and-drop: always provide button-based reordering
+- Drawing/annotation: offer text description as alternative
+- Map interactions: provide address search alongside map selection
+- Gestures (swipe, pinch): always provide button equivalents
+
+## Assessment Questions
+
+1. Can every task be completed through keyboard alone?
+2. Can every task be completed through pointer alone?
+3. Are there complex interactions (drag, gesture, drawing) that
+   lack simpler alternatives?
+4. Is paste enabled in all text fields?
+5. Do all form controls have clickable labels?

package/skills/design-library/inclusive-interaction/skills/touch-target-design/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: touch-target-design
+description: "Design touch targets and pointer interactions that work for people with motor difficulties, tremors, limited dexterity, or who use assistive pointing devices. Use when designing buttons, links, form controls, mobile interfaces, or any clickable/tappable elements. Triggers on: touch target, tap target, button size, too small to tap, fat finger, motor disability, dexterity, tremor, pointer, click area, hit area, mobile buttons."
+---
+
+# Touch Target Design
+
+Design interactive elements that are large enough, spaced enough, and
+forgiving enough for people with limited precision — whether from
+disability, age, environment, or device.
+
+## Minimum Sizes
+
+### Touch (mobile, tablet)
+- Minimum: 24×24 CSS pixels (WCAG 2.2 SC 2.5.8, Level AA)
+- Enhanced: 44×44 CSS pixels (WCAG 2.2 SC 2.5.5, Level AAA; also the common platform guideline)
+- Recommended: 48×48 CSS pixels (Google Material guidelines)
+- For high-stakes or frequent-use targets: 56×56 or larger
+
+### Pointer (desktop)
+- Minimum: 24×24 CSS pixels (WCAG 2.2 Level AA)
+- Recommended: 32×32 for common actions
+- For destructive or irreversible actions: larger targets reduce errors
+
+### Spacing Between Targets
+- Minimum: 8px gap between adjacent interactive elements
+- Recommended: 12–16px for frequently used elements side by side
+- Never place destructive actions (delete) adjacent to common actions
+  (save) without spacing or visual separation
+
+## Design Patterns
+
+### Generous Hit Areas
+- The tappable area can be larger than the visible element
+- Use padding, not just the visual size of the icon or text
+- Entire row should be tappable in list items, not just the text
+- Link text should be descriptive enough to form a reasonable
+  tap target ("Read the full report" not "here")
+
+### Forgiving Interactions
+- Don't trigger actions on touch-down — trigger on touch-up
+  (this lets users slide away to cancel)
+- For destructive actions: require a deliberate second tap or
+  confirmation, not a single tap
+- Avoid double-tap requirements — they're unreliable for users
+  with tremors
+- Avoid long-press as the only way to access functionality
+
+### Spacing for Safety
+- Separate "confirm" and "cancel" actions with distance or visual weight
+- Place destructive actions away from common actions
+- Group related actions together, separate unrelated actions
+- On mobile: keep primary actions in the thumb zone (bottom half
+  of screen)
+
+### Alternatives to Precision
+- Provide zoom capability for complex interfaces
+- Allow pinch-to-zoom on mobile (never disable it)
+- For precise tasks (colour pickers, sliders): provide a text
+  input alternative
+- Dropdown menus with many items: add search/filter
+
+## Assessment Questions
+
+1. Are all interactive elements at least 44×44px on touch devices?
+2. Is there adequate spacing between adjacent targets?
+3. Are destructive actions separated from common actions?
+4. Can every interaction be completed without precision timing
+   or precise pointing?
+5. Is there always an alternative to precision-dependent interactions
+   like sliders or drag-and-drop?

package/skills/design-library/inclusive-interaction/skills/voice-interaction/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: voice-interaction
+description: "Design voice interactions and speech interfaces that work for people with diverse speech patterns, accents, and communication styles. Use when designing voice commands, voice search, dictation, voice assistants, or any interface that accepts speech input. Triggers on: voice, speech, dictation, voice command, voice search, speech recognition, accent, stutter, speech disability, non-verbal, AAC, voice assistant, talk to type."
+---
+
+# Voice Interaction Design
+
+Design voice interfaces that work for the full range of human speech —
+including accents, speech disabilities, non-native speakers, and people
+in noisy or quiet environments.
+
+## Who This Is For
+
+- People with motor disabilities who use voice as primary input
+- People who stutter, have dysarthria, or other speech differences
+- Non-native speakers with varied accents
+- People in environments where typing is impractical
+- Anyone who prefers voice to typing for certain tasks
+
+## Core Principles
+
+### Voice Should Never Be the Only Option
+- Every voice interaction must have a text/touch/keyboard alternative
+- Voice is an accelerator, not a gatekeeper
+- Don't require voice for identity verification or critical actions
+  unless an alternative exists
+
+### Design for Speech Variation
+- Support varied pacing — don't cut off slow speakers
+- Allow generous silence before timing out
+- Don't penalise repetition, filler words, or self-correction
+- Support multiple phrasings for the same intent
+  ("go back", "previous page", "take me back", "undo")
+
+### Feedback Must Be Clear
+- Confirm what the system heard (visual transcript)
+- Make it easy to correct misrecognition
+- Show when the system is listening vs. processing vs. waiting
+- Never execute a destructive action on voice alone without
+  confirmation
+
+## Design Patterns
+
+### Flexible Recognition
+- Accept multiple ways to say the same command
+- Don't require exact phrasing — intent matters more than syntax
+- Support "did you mean?" clarification for ambiguous input
+- Allow users to spell out words the system doesn't recognise
+
+### Graceful Failure
+- When recognition fails: show what was heard and offer correction
+- Never respond with just "I didn't understand" — offer alternatives
+- Provide a "type instead" option at every failure point
+- After repeated failures: proactively suggest switching to text input
+
+### Privacy and Control
+- Clear visual/audio indicator when microphone is active
+- Easy one-action mute/stop listening
+- Don't record or transmit audio without explicit consent
+- Allow users to review and delete voice data
+
+## Assessment Questions
+
+1. Can every voice-activated feature also be completed without voice?
+2. Does the system handle varied speech patterns without frustration?
+3. Is there clear feedback showing what the system heard?
+4. Can users easily correct misrecognition?
+5. Is it obvious when the system is listening?

package/skills/design-library/visual-critique/skills/critique-affordance/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: critique-affordance
+description: Critique a rendered screen's affordances — what looks clickable, state visibility, CTA clarity, and action discoverability. Use when reviewing an existing screen. For sizing and positioning targets in new work, use `fitts-law` (interaction-design).
+---
+# Critique Affordance
+You are an expert in interaction design and the visual communication of interactivity.
+## What You Do
+You analyse a screen to identify whether interactive elements are visually distinguishable, whether states are communicated clearly, and whether the primary action is obvious. You flag affordance failures and propose specific fixes.
+## Critique Dimensions
+### Clickability Signals
+Evaluate whether interactive elements look interactive.
+- Do buttons, links, and controls look distinct from static content through colour, shape, underline, or elevation?
+- Are there elements that look interactive but are not (false affordances)?
+- Are there elements that are interactive but look static (missing affordances)?
+- Is the interactive area large enough — touch targets should be at least 44×44px on mobile.
+### State Visibility
+Evaluate whether element states are visually communicated.
+- Are default, hover, active, focus, disabled, and selected states visually distinct?
+- Is the focus state visible and high-contrast (not just the browser default ring on a coloured background)?
+- Are loading and skeleton states present where async content is expected?
+- Are disabled states clearly communicated without relying on colour alone?
+### CTA Clarity
+Evaluate whether the primary action on screen is immediately obvious.
+- Is there a single dominant CTA per view, or are multiple actions competing at the same visual weight?
+- Does the primary CTA use filled/solid style while secondary actions use ghost or text variants?
+- Is the CTA label specific and action-oriented ("Save changes", not "OK")?
+- Is the CTA positioned where users expect it — bottom-right on forms, inline after content blocks?
+### Action Discoverability
+Evaluate whether all available actions can be found without instruction.
+- Are actions hidden behind hover states or tooltips that mobile users can't access?
+- Are contextual actions (edit, delete, share) visible or indicated — not completely hidden until hover?
+- Are empty states actionable — do they tell the user what to do next?
+- Are destructive actions (delete, remove) visually distinguished from constructive ones?
+## Output Format
+For each dimension — Clickability Signals, State Visibility, CTA Clarity, Action Discoverability — provide:
+1. **Observation** — what you see (neutral, factual)
+2. **Problem** — what is broken and why it matters
+3. **Fix** — a specific, actionable change
+Rate each dimension: `pass` / `minor issue` / `major issue`.
+## Common Failure Patterns
+- Ghost buttons in low-contrast contexts where the border becomes invisible
+- Focus rings suppressed with `outline: none` and no replacement state
+- Multiple filled CTAs on one screen, leaving users unsure which to press
+- Edit and delete actions hidden behind hover — inaccessible on touch and invisible until discovered by accident
+- Empty states that explain nothing and offer no path forward

package/skills/design-library/visual-critique/skills/critique-brand-consistency/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: critique-brand-consistency
+description: Critique a rendered screen against mood.md, voice.md, and tokens.md. Use when those brand files exist and you are checking compliance. For defining the visual language itself, use `illustration-style` (ui-design).
+---
+# Critique Brand Consistency
+You are an expert in brand expression and design system compliance.
+## What You Do
+You check whether a screen faithfully expresses the brand by comparing it against three project reference files: `mood.md` (personality and aesthetic direction), `voice.md` (tone and language guidelines), and `tokens.md` (design token definitions). Flag every divergence and suggest the correct value or approach.
+## Reference Files
+Before critiquing, locate and read these files from the project root (or wherever the designer specifies):
+- **mood.md** — Brand personality, aesthetic keywords, visual references, do/don't examples
+- **voice.md** — Tone of voice, language style, copy do/don't rules, vocabulary
+- **tokens.md** — Canonical colour, spacing, radius, shadow, and typography token values
+If a file is missing, note this and skip that dimension — do not invent brand rules.
+## Critique Dimensions
+### Mood Alignment
+Compare the screen's aesthetic to the mood direction.
+- Does the visual language (imagery style, illustration, iconography, colour feel) match the brand personality keywords?
+- Are any elements tonally off — e.g., a playful brand using cold, corporate styling?
+- Does the overall emotional register of the screen match what the mood file prescribes?
+### Voice Alignment
+Compare all visible copy to the voice guidelines.
+- Does the tone match (e.g., direct vs. conversational, formal vs. friendly)?
+- Are any prescribed vocabulary rules broken — forbidden words, required patterns?
+- Are CTAs, labels, error messages, and microcopy consistent with the voice?
+### Token Compliance
+Compare every design value on screen to the token definitions.
+- Are hardcoded hex values used where a colour token should apply?
+- Are spacing, radius, or shadow values that deviate from tokens present?
+- Are typography tokens applied correctly, or are raw font-size/weight values used?
+- List every non-compliant value with its token equivalent.
+## Output Format
+For each dimension — Mood, Voice, Token Compliance — provide:
+1. **Observation** — what you see (neutral, factual)
+2. **Divergence** — what conflicts with the reference file and why it matters
+3. **Fix** — the exact correction (preferred wording, correct token name, etc.)
+Rate each dimension: `pass` / `minor issue` / `major issue`.
+## Common Failure Patterns
+- Hardcoded values drifting from tokens over time
+- Copy written without consulting voice guidelines, defaulting to generic UI language
+- Imagery or illustration sourced outside the brand mood reference
+- Inconsistent radius or shadow values across components on the same screen

package/skills/design-library/visual-critique/skills/critique-color/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: critique-color
+description: Critique a rendered screen's colour — contrast ratios, palette coherence, and semantic meaning. Use when reviewing one screen. For a product-wide WCAG audit use `accessibility-audit` (design-systems); for building the palette use `color-system` (ui-design).
+---
+# Critique Color
+You are an expert in colour theory, accessible design, and design systems.
+## What You Do
+You audit all colour decisions on a screen: contrast ratios, palette coherence, semantic colour meaning, and accessibility. You flag every deviation and recommend specific corrections.
+## Critique Dimensions
+### Contrast
+Evaluate text/background and UI element contrast for readability and compliance.
+- Does body text meet WCAG AA (4.5:1)? Does large text (18px+ regular, 14px+ bold) meet 3:1?
+- Do interactive components (buttons, inputs, focus rings) meet 3:1 against adjacent surfaces?
+- Flag every failing pair with its actual measured ratio and the minimum required.
+- Are placeholder text and disabled states failing contrast in ways that impede use?
+### Palette Coherence
+Evaluate whether colour use is purposeful and internally consistent.
+- Is the palette limited to defined token values, or do arbitrary colours appear?
+- Are neutrals, primaries, and accents applied according to their intended roles?
+- Do colours on adjacent or overlapping elements create unintended visual noise or vibration?
+- Is the overall palette warm, cool, or neutral — and is that register appropriate for the context?
+### Semantic Use
+Evaluate whether colour communicates meaning reliably.
+- Is colour used as the sole indicator of state (error, success, warning)? If so, flag it — colour must be paired with an icon, label, or pattern to be accessible.
+- Are status colours (red = error, green = success, amber = warning) applied consistently across the screen?
+- Does interactive colour (links, button fills) distinguish clearly from non-interactive colour?
+- Are decorative colour uses being mistaken for actionable elements?
+### Accessibility
+Evaluate broader colour accessibility beyond contrast ratios.
+- Do foreground/background combinations cause problems for common colour vision deficiencies (deuteranopia, protanopia)?
+- Does the interface hold up in Windows High Contrast mode or forced-colour environments?
+- Are any decorative colour uses interfering with content legibility?
+## Output Format
+For each dimension — Contrast, Palette Coherence, Semantic Use, Accessibility — provide:
+1. **Observation** — what you see (neutral, factual)
+2. **Problem** — what is broken and why it matters
+3. **Fix** — a specific, actionable change (include ratio, token name, or pairing where applicable)
+Rate each dimension: `pass` / `minor issue` / `major issue`.
+## Common Failure Patterns
+- Link colour that fails 4.5:1 against white when underline is removed
+- Error states communicated in red only, with no supporting icon or label
+- Placeholder text at 40% opacity that fails contrast on light surfaces
+- One-off hex values outside the token system introduced by individual contributors
+- Interactive and non-interactive elements sharing the same colour treatment