@harness-engineering/cli 1.23.1 → 1.24.0

package/dist/agents/skills/gemini-cli/design-brand-consistency/SKILL.md

@@ -0,0 +1,167 @@
+# Brand Consistency
+
+> Visual coherence across every touchpoint — mapping brand attributes to design decisions, voice-to-visual translation, consistency vs. monotony, brand flex zones, and multi-platform coherence
+
+## When to Use
+
+- Building or auditing a design system for brand alignment
+- Extending a brand from web to mobile, email, print, or embedded contexts
+- Evaluating whether a new component or page feels "on brand" without a subjective debate
+- Defining what can vary (flex zones) vs. what must remain fixed (brand invariants)
+- Translating brand voice attributes (e.g., "confident and clear") into concrete visual decisions
+- Merging design systems after an acquisition or rebrand
+- Onboarding new designers who need to internalize brand rules quickly
+- Diagnosing why a product "feels off" despite using correct colors and typography
+
+## Instructions
+
+1. **Define brand attributes as measurable design axes, not adjectives.** Brand attributes like "modern," "trustworthy," or "playful" are useless without translation to specific design parameters. Create a brand-attribute-to-design-decision map:
+
+   | Brand Attribute  | Color                                | Typography                        | Shape                    | Motion                      | Photography                 |
+   | ---------------- | ------------------------------------ | --------------------------------- | ------------------------ | --------------------------- | --------------------------- |
+   | **Confident**    | High saturation, dark values         | Bold weights, large scale         | Sharp corners, strong    | Fast, decisive easing       | Direct gaze, centered       |
+   | **Approachable** | Warm hues, medium saturation         | Medium weights, generous spacing  | Rounded corners (8px+)   | Gentle, spring-based easing | Candid, warm lighting       |
+   | **Precise**      | Cool neutrals, monochrome            | Monospace or geometric sans       | Right angles, thin lines | Linear, exact timing        | Clean backgrounds, isolated |
+   | **Playful**      | Bright, varied hues, high saturation | Rounded sans, variable weight     | Organic shapes, curves   | Bouncy, overshoot           | Colorful, dynamic angles    |
+   | **Premium**      | Black + one accent, low saturation   | Serif or thin sans, ample leading | Minimal, thin strokes    | Slow, deliberate, subtle    | Studio-lit, desaturated     |
+
+   Stripe's brand attributes map concretely: "developer-forward" = monospace code snippets in marketing, dark code editor screenshots, terminal-inspired UI elements. "Premium" = generous whitespace (120px+ section padding), thin rule separators (1px, 10% opacity), subtle gradient backgrounds. "Confident" = saturated violet primary at `#635bff`, bold sans-serif headlines at 56px+, decisive animation curves (`cubic-bezier(0.4, 0, 0.2, 1)`).
+
+2. **Establish brand invariants — the elements that never change.** Brand invariants are the minimum set of design decisions that, if all present, make anything recognizably "your brand." Everything else is negotiable. Typical invariants:
+   - **Primary brand color** — the single color that appears on every touchpoint. Spotify Green `#1DB954`. Stripe Violet `#635bff`. Coca-Cola Red `#F40009`.
+   - **Logo and its clear space rules** — minimum size, minimum padding, no color modifications.
+   - **Primary typeface** — the headline font. Apple uses SF Pro. Google uses Google Sans. Stripe uses a custom variant of Inter.
+   - **Corner radius token** — the default border-radius. Applies to buttons, cards, inputs, images. Apple: 12-16px (large, rounded). Vercel: 6-8px (subtle). Stripe: 8px (balanced).
+   - **Voice constants** — tone attributes that persist across all copy. Stripe: "concise, direct, technical." Mailchimp: "fun but not silly, confident but not cocky."
+
+   Decision procedure: if you remove an element and the design is no longer recognizable as your brand, it is an invariant. If you remove it and the brand still reads correctly, it is a flex zone element.
+
+3. **Define brand flex zones — where variation is permitted and bounded.** Flex zones prevent monotony while maintaining coherence. Without them, every page looks identical (boring) or designers improvise (inconsistent). Define bounds, not options:
+   - **Color flex zone:** The primary color is invariant. Secondary and accent colors can vary within a defined gamut. Spotify allows editorial playlist covers to use any color pair in duotone — but the Spotify Green always appears in the UI chrome around the content. The green is the invariant; the content colors are the flex zone.
+   - **Layout flex zone:** Grid column count and gutter width are invariant. Content arrangement within the grid can vary. Material Design fixes the 4/8/12 column grid across breakpoints but allows any content arrangement within it.
+   - **Typography flex zone:** The typeface is invariant. Size, weight, and leading can vary within the type scale. GitHub uses the same system font stack everywhere but varies between 6 heading levels and 3 body sizes.
+   - **Illustration flex zone:** The style (geometric, organic, isometric) is invariant. Subject matter and color within the style can vary. Shopify's Polaris illustrations are always flat, geometric, and use the brand green as an accent — but depict hundreds of different subjects.
+
+   Concrete bounds example: "Cards may use any background from the neutral palette (gray-50 through gray-200) but must use the brand primary for interactive elements (buttons, links). Card corner radius is fixed at 8px. Card shadow is one of three elevation tokens (sm, md, lg). Card padding is fixed at 24px."
+
+4. **Map brand voice to visual attributes with a translation matrix.** Voice and visual are two expressions of the same brand personality. They must align:
+
+   Mailchimp's voice is "fun but not silly." Visual translation: illustrations use bright colors and playful characters (fun) but maintain consistent 2px stroke weight and precise geometric shapes (not silly). The illustration characters have expressive poses but realistic proportions — not cartoonishly exaggerated. Typography uses a rounded sans-serif (Cooper Light) for warmth and a clean geometric sans (Graphik) for professionalism.
+
+   Stripe's voice is "concise and technical." Visual translation: UI text is short (button labels are 1-2 words, descriptions are 1 sentence). Code is visible everywhere — product screenshots show real code, not mockups. The dark-mode code editor treatment signals "this is a developer tool." Animation is fast (200-300ms) and functional — no decorative motion.
+
+   Decision procedure for voice-visual alignment: take a piece of marketing copy and a screenshot of the product. Cover the logo. Would a stranger identify them as the same brand? If not, the voice and visual are misaligned. The most common failure: playful, casual copy paired with a cold, corporate visual design, or vice versa.
+
+5. **Audit consistency across platforms without enforcing pixel-identical replication.** "Consistent" does not mean "identical." Each platform has its own conventions, and forcing identical UI across web, iOS, and Android produces an experience that feels native nowhere. Instead, define platform-specific expressions of the same brand invariants:
+
+   | Brand Element     | Web                                                       | iOS                            | Android                        |
+   | ----------------- | --------------------------------------------------------- | ------------------------------ | ------------------------------ |
+   | Navigation        | Horizontal top nav                                        | Bottom tab bar (UITabBar)      | Bottom navigation bar          |
+   | Primary button    | Brand color, 8px radius                                   | Brand color, 12px radius (iOS) | Brand color, 20px radius (MD3) |
+   | Typography        | Inter/System stack, 16px body                             | SF Pro, 17pt body              | Roboto, 14sp body              |
+   | Elevation         | Box shadow tokens                                         | None (iOS uses blur layers)    | Tonal elevation (MD3)          |
+   | Brand color usage | Invariant: same hex value across all platforms            |
+   | Logo placement    | Invariant: same mark, same clear space, same minimum size |
+   | Voice/copy        | Invariant: same tone, same terminology                    |
+
+   Airbnb's iOS app uses native iOS tab bars with platform-standard haptics, while the web app uses a custom bottom navigation on mobile. Both use the same Cereal typeface, the same Rausch coral, and the same photography art direction. The brand is unmistakably Airbnb on both platforms despite different structural patterns.
+
+6. **Measure consistency with a brand consistency score.** Subjective assessments ("this feels on-brand") are unreliable across a team. Create a measurable checklist:
+   - Does the page use only colors from the design token palette? (Yes/No)
+   - Does the page use only typefaces from the brand type stack? (Yes/No)
+   - Does the page use only corner radii from the token set? (Yes/No)
+   - Is the brand primary color present in the viewport without scrolling? (Yes/No)
+   - Does the page follow the grid system (column count, gutter width)? (Yes/No)
+   - Does the photography match the art direction guide (color temp, composition, subject)? (Yes/No)
+   - Does the copy match the voice guide (tone, terminology, sentence structure)? (Yes/No)
+   - Are interactive components using brand-standard hover/focus/active states? (Yes/No)
+
+   A page scoring 8/8 is fully on-brand. 6-7/8 has minor deviations. Below 6/8, the page needs a brand review. Automate where possible — design token linting (Stylelint with custom rules), color extraction from screenshots (compare against palette), and copy tone analysis (Grammarly Business with brand voice profile).
+
+## Details
+
+### Consistency vs. Monotony — The Variety Paradox
+
+Brand consistency does not mean every page looks the same. It means every page feels like it belongs to the same family. The distinction is between structural consistency (same grid, same tokens, same type scale) and expressive variety (different layouts, different hero treatments, different content hierarchies).
+
+Spotify demonstrates this well: the home screen, search screen, and artist page have completely different layouts — grid of cards, category bubbles, and a full-bleed hero with scrolling track list. But all three use the same dark background (`#121212`), the same green accent (`#1DB954`), the same Circular typeface, and the same card corner radius (8px). The structure is consistent; the expression varies.
+
+The danger of excessive consistency is brand fatigue — when every page is so formulaic that users cannot distinguish sections or feel no emotional progression through the experience. Fix: define 2-3 page archetypes (e.g., landing, content, dashboard) with distinct layout templates that share the same brand invariants.
+
+### Design Token Architecture as Brand Enforcement
+
+Design tokens are the mechanical enforcement layer of brand consistency. A token system that encodes brand decisions makes consistency the path of least resistance:
+
+- **Color tokens:** `--color-brand-primary: #635bff` is the Stripe invariant. All components reference the token, never the hex value. Changing the brand color means changing one token.
+- **Spacing tokens:** `--space-section: 120px` ensures consistent section padding. A designer cannot use 80px or 160px without overriding the token — which is flagged in code review.
+- **Shadow tokens:** `--shadow-card: 0 4px 6px -1px rgba(0,0,0,0.1)` ensures every card has the same elevation feel.
+- **Radius tokens:** `--radius-default: 8px` applied to buttons, cards, inputs, and images creates the rounded brand feel without manual per-component specification.
+
+The token layer turns brand consistency from a cultural practice ("we trust designers to be consistent") into an engineering constraint ("the system only allows brand-consistent values").
+
+### Anti-Patterns
+
+1. **Adjective-Only Brand Guidelines.** A brand guide that says "our brand is modern, friendly, and innovative" without mapping these adjectives to specific design values. Every designer interprets "modern" differently — one uses geometric sans-serif and sharp corners, another uses rounded humanist sans and organic shapes. Fix: translate every brand adjective to specific design parameter ranges using the attribute-to-decision map in step 1. "Modern" must resolve to concrete values: geometric sans-serif (not humanist), 4px corner radius (not 16px), cool neutrals (not warm).
+
+2. **Pixel-Perfect Cross-Platform Cloning.** Forcing the iOS app to look exactly like the web app — same 8px corner radius on buttons even though iOS Human Interface Guidelines specify larger radii, same hover states even though mobile has no hover, same navigation even though iOS uses bottom tab bars. The result feels native to no platform. Fix: define brand invariants (color, typeface, voice) that cross all platforms, and allow structural elements (navigation, input controls, elevation, radii) to follow each platform's conventions.
+
+3. **Brand Police Without Flex Zones.** A design governance process that rejects any variation from the style guide, producing a product that is technically on-brand but creatively dead. Every page has the exact same layout, the same hero treatment, the same illustration style. Users experience brand fatigue. Fix: define explicit flex zones (step 3) where variation is not just permitted but encouraged. The flex zones are bounded by the brand invariants — variation within them is on-brand by definition.
+
+4. **Voice-Visual Disconnect.** Marketing copy is playful and casual ("Hey there! Let's build something awesome") while the product UI is cold and corporate (gray backgrounds, formal labels, no personality). Users experience cognitive dissonance at the transition from marketing to product. Fix: use the voice-visual translation matrix (step 4) to ensure copy tone and visual tone are calibrated to the same brand personality. If the voice is casual, the visuals must be warm and approachable.
+
+5. **Token Bypass.** Engineers hardcoding hex values, pixel sizes, and font names instead of referencing design tokens. The product starts on-brand but drifts as hardcoded values are not updated when the brand evolves. Fix: lint for magic values in CSS/styled-components. Every color, spacing, radius, shadow, and font reference should resolve to a token. Hardcoded values are code smells.
+
+### Real-World Examples
+
+**Stripe — Consistency Through Restraint.** Stripe's brand is recognizable because of what it does NOT do: no gradients on buttons, no decorative illustrations in the product, no color variety beyond the violet/navy/white core. The restraint itself is the brand signal. Every touchpoint — docs, dashboard, marketing, Stripe Press books — uses the same navy text color (`#061b31`), the same code-block style (dark background, syntax highlighting), and the same generous whitespace. New pages feel on-brand because the design system provides so few choices that off-brand combinations are nearly impossible. Key lesson: brand consistency is easier when the palette of options is deliberately narrow.
+
+**Airbnb — Multi-Platform Coherence.** Airbnb is one of the few companies whose web, iOS, and Android apps feel like the same brand without being pixel-identical. The invariants: Cereal typeface, Rausch coral (`#FF5A5F`), warm photography art direction, rounded shapes, and casual-yet-helpful voice. The flex zones: navigation structure follows platform convention (tabs on mobile, sidebar on desktop), component styling respects platform norms, and layout adapts to screen context. An Airbnb user switching between web and mobile feels continuity without uncanny sameness. Key lesson: brand consistency is about recognizability, not replication.
+
+**Material Design — Brand as System.** Google's Material Design is a brand consistency framework for thousands of apps. It defines invariants (the type scale, the elevation system, the color role architecture) and flex zones (theme colors, shape overrides, component customization). A Material Design app themed with Stripe's colors and Google's with YouTube's colors look completely different — yet both are recognizably Material Design because they share the systematic structure. Key lesson: at scale, brand consistency must be systematic (tokens, constraints, automated checks) rather than manual (design reviews, visual QA).
+
+**GitHub — Consistency Through System Fonts.** GitHub uses system fonts rather than a custom typeface — SF Pro on Mac, Segoe UI on Windows, Roboto on Android. This means the literal font rendering varies across platforms. But the brand remains consistent because the invariants are: monospace code blocks (the developer identity signal), the Mona octocats (illustration system), Primer design tokens (color, spacing, radius), and the direct, technical voice. Key lesson: brand invariants do not have to include a custom typeface if other elements carry sufficient brand signal.
+
+### Brand Consistency Auditing Process
+
+A systematic audit prevents drift from becoming entrenched:
+
+1. **Screenshot audit (monthly).** Capture full-page screenshots of the 10 most-trafficked pages. Place them side-by-side in a Figma frame. Visually scan for: color outliers, typography inconsistencies, spacing anomalies, and photography style breaks. Any page that does not "belong" to the group at a glance needs investigation.
+2. **Token coverage audit (per sprint).** Run a CSS analysis tool (Stylelint with design-token rules, or Project Wallace) to measure what percentage of color, spacing, and typography values reference tokens vs. hardcoded values. Target: 95%+ token coverage. Below 90% indicates active drift.
+3. **Copy tone audit (quarterly).** Sample 20 strings from different product areas (onboarding, error messages, settings, marketing). Score each against the voice guide's tone attributes. If more than 3/20 are off-tone, the voice guide needs reinforcement.
+4. **Cross-platform parity audit (quarterly).** Place equivalent screens from web, iOS, and Android side-by-side. Verify brand invariants (color, typeface, voice) are consistent. Document platform-specific flex zone differences to confirm they are intentional, not accidental.
+
+### Rebrand and Migration Strategy
+
+When brand elements change (new colors, new typeface, new illustration style), the migration must be systematic:
+
+- **Token-first migration:** Update design tokens at the source. All components referencing tokens update automatically. This is why token architecture matters — a rebrand that changes `--color-brand-primary` from `#635bff` to `#4F46E5` propagates to every button, link, and accent in one change.
+- **Progressive rollout:** Change the marketing site first (highest visibility, lowest interaction complexity), then the product chrome (navigation, headers), then the product content area. This gives users a graduated transition rather than a jarring overnight change.
+- **Deprecation markers:** Mark old brand values as deprecated in the token system. Linting rules flag deprecated token usage. Set a sunset date after which deprecated tokens are removed.
+- **Brand versioning:** Maintain a `brand-v2` token layer alongside `brand-v1` during transition. Components can opt into the new brand by switching their import. This prevents half-migrated states where some components use old values and others use new.
+
+Slack's 2019 rebrand migrated from the hashtag logo and 11-color palette to the aubergine-focused 4-color palette using a token-first approach. The design system's color tokens were updated, and every component that referenced them adopted the new palette automatically. Custom-themed elements that used hardcoded values required manual migration — reinforcing why token coverage matters.
+
+## Source
+
+- Airbnb Design Language System Documentation
+- Stripe Brand Guidelines (inferred from public assets)
+- Material Design 3 — Theming and Customization
+- Mailchimp Content Style Guide
+- Nathan Curtis — "Design Tokens and Brand Consistency" (Medium, 2023)
+- Slack — "Rebrand Migration Case Study" (2019)
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/gemini-cli/design-brand-consistency/skill.yaml

@@ -0,0 +1,35 @@
+name: design-brand-consistency
+version: "1.0.0"
+description: Visual coherence — brand attributes to design decisions, voice to visual mapping, consistency vs monotony, brand flex zones, multi-platform coherence
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - design-color-psychology
+  - design-font-pairing
+  - design-design-governance
+stack_signals: []
+keywords:
+  - brand
+  - consistency
+  - coherence
+  - voice
+  - visual-mapping
+  - flex-zones
+  - multi-platform
+  - brand-attributes
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/design-color-accessibility/SKILL.md

@@ -0,0 +1,161 @@
+# Color Accessibility
+
+> Color independence — conveying information without relying on color alone, building colorblind-safe palettes, and ensuring perceptual uniformity across all vision types
+
+## When to Use
+
+- Designing status indicators, badges, or alerts that use color to communicate state
+- Building data visualizations (charts, graphs, maps) with color-coded series
+- Choosing a palette that must work for colorblind users (8% of males, 0.5% of females)
+- Auditing an existing design for WCAG 2.1 SC 1.4.1 (Use of Color) compliance
+- Selecting safe color pairs for UI elements that need to be distinguishable
+- Creating form validation states that are perceivable by all users
+- Designing interactive states (hover, focus, active, selected) that do not rely solely on color change
+- Building accessible data tables, calendars, or scheduling interfaces with color-coded categories
+
+## Instructions
+
+1. **Understand the types and prevalence of color vision deficiency (CVD).** Do not design for "colorblindness" as a monolith — there are distinct types with different impact:
+
+   | Type                           | Affected Cones  | Prevalence (Male/Female) | Colors Confused                     | Safe Alternatives          |
+   | ------------------------------ | --------------- | ------------------------ | ----------------------------------- | -------------------------- |
+   | **Deuteranopia** (green-blind) | M-cones (green) | 6% / 0.4%                | Red-green, brown-green, teal-gray   | Blue-orange, blue-yellow   |
+   | **Protanopia** (red-blind)     | L-cones (red)   | 1% / 0.01%               | Red-green, red-brown, purple-blue   | Blue-orange, blue-yellow   |
+   | **Tritanopia** (blue-blind)    | S-cones (blue)  | 0.003% / 0.003%          | Blue-yellow, purple-red, green-cyan | Red-blue, red-green        |
+   | **Achromatopsia** (total)      | All cones       | 0.003% / 0.003%          | All hues — sees only lightness      | Lightness differences only |
+
+   Key insight: red-green confusion affects approximately 8% of males. This means in a room of 25 people, 1-2 will not be able to distinguish your red error state from your green success state by color alone. This is not an edge case — it is a significant portion of your user base.
+
+2. **Never use color as the sole means of conveying information.** This is WCAG 2.1 SC 1.4.1 — a Level A requirement (the most basic tier). Every piece of information conveyed by color must also be conveyed by at least one additional channel:
+
+   | Color-Only (Fails)                         | Color + Redundant Encoding (Passes)                          |
+   | ------------------------------------------ | ------------------------------------------------------------ |
+   | Red/green dot for online/offline           | Dot + "Online"/"Offline" text label                          |
+   | Colored bar chart series                   | Color + pattern (stripes, dots, crosshatch) + legend         |
+   | Red border on invalid input                | Red border + error icon + error message text                 |
+   | Green/red text for pass/fail               | Color + checkmark/X icon + "Pass"/"Fail" label               |
+   | Calendar events coded by color             | Color + category letter/icon + tooltip                       |
+   | Link text distinguished only by blue color | Blue color + underline (or 3:1 contrast vs surrounding text) |
+
+3. **Choose colorblind-safe color pairs.** When two elements must be distinguishable by color (in addition to a redundant encoding), select pairs that survive all common CVD types:
+
+   **Safe universal pairs (distinguishable under deuteranopia, protanopia, and tritanopia):**
+   - Blue (`#2563EB`) and orange (`#EA580C`) — the most reliable safe pair
+   - Blue (`#2563EB`) and red (`#DC2626`) — safe for red-green CVD (the most common)
+   - Dark blue (`#1E3A5F`) and yellow (`#EAB308`) — high lightness contrast as backup
+   - Purple (`#7C3AED`) and yellow-green (`#A3E635`) — different lightness + different hue region
+
+   **Unsafe pairs (fail for common CVD types):**
+   - Red (`#DC2626`) and green (`#16A34A`) — indistinguishable for deutan/protan (8% of males)
+   - Green (`#16A34A`) and brown (`#92400E`) — merge for deutan
+   - Red (`#DC2626`) and brown (`#92400E`) — merge for protan
+   - Blue (`#2563EB`) and purple (`#7C3AED`) — merge for tritan
+   - Pink (`#EC4899`) and gray (`#6B7280`) — insufficient lightness contrast for achromatopsia
+
+4. **Design data visualizations for color independence.** Charts are the most common color accessibility failure. A line chart with 5 color-coded series is useless for colorblind users if color is the only differentiator.
+
+   **Visualization accessibility checklist:**
+   - Use distinct line patterns (solid, dashed, dotted, dash-dot) in addition to color
+   - Add shape markers at data points (circle, square, triangle, diamond, star)
+   - Provide direct labels on or adjacent to data series rather than relying on a color-keyed legend
+   - If using area fills, combine color with pattern fills (diagonal stripes, dots, crosshatch)
+   - Limit color-only categorical series to 3-4 maximum — beyond that, pattern and shape differentiation breaks down regardless of color choices
+
+   **IBM's accessible palette for data visualization** provides 8 distinct colors all designed to remain distinguishable under deuteranopia and protanopia: `#6929C4`, `#1192E8`, `#005D5D`, `#9F1853`, `#FA4D56`, `#570408`, `#198038`, `#002D9C`. These were specifically tested under CVD simulation.
+
+5. **Use perceptually uniform color spaces for palette generation.** Standard RGB and HSL spaces are not perceptually uniform — equal numeric steps do not produce equal visual differences. This matters for accessibility because colorblind users may rely on lightness differences when hue is indistinguishable.
+
+   **OKLCH** is the recommended perceptually uniform space:
+   - **L** (Lightness): 0-1, perceptually linear
+   - **C** (Chroma): 0-0.4, perceptually uniform colorfulness
+   - **H** (Hue): 0-360 degrees
+
+   When generating accessible palettes, ensure that each color in the palette has a distinct OKLCH Lightness value. If two colors must be distinguishable, they should differ by at least 0.15 in OKLCH Lightness (or ~15 units in CIELAB L\*). This guarantees that even under total color blindness (achromatopsia), the values remain separable.
+
+6. **Test with CVD simulation tools.** Do not assume your palette is accessible — verify it:
+   - **Chrome DevTools:** Rendering panel > Emulate vision deficiencies > Protanopia / Deuteranopia / Tritanopia / Achromatopsia
+   - **Figma:** Stark plugin or built-in Vision Simulator
+   - **Command line:** `colorblind-check` npm package for automated CI testing
+   - **Manual verification:** Convert your palette to grayscale (desaturate to 0%). If two elements that carry different meaning become indistinguishable in grayscale, they need a non-color differentiator.
+
+## Details
+
+### WCAG 1.4.1 in Practice
+
+WCAG SC 1.4.1 states: "Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element." This is Level A — the absolute baseline. Failing this criterion means failing the most fundamental accessibility standard.
+
+Common violations that pass unnoticed in design review:
+
+- **Required field indicators:** A red asterisk (\*) uses color + shape, which passes. But a field label that turns red with no other change fails.
+- **Link differentiation:** Links within body text that are only distinguishable by their blue color fail unless they have at least 3:1 contrast against the surrounding text AND a non-color indicator on hover/focus (typically underline).
+- **Progress indicators:** A progress bar that shifts from red to yellow to green fails. Adding percentage text or milestone markers fixes it.
+- **Toggle/switch states:** A toggle that is red when off and green when on fails unless the toggle also changes shape, position, or includes on/off text.
+
+### Building a Colorblind-Safe Semantic System
+
+The standard semantic colors (red=error, yellow=warning, green=success, blue=info) are problematic because red and green are the most commonly confused pair. Solutions:
+
+1. **Always pair with icons:** Error = red + X icon, Success = green + checkmark, Warning = amber + triangle icon, Info = blue + (i) icon. The icon alone must be sufficient to communicate the state.
+
+2. **Ensure lightness differentiation:** Even if hue is lost, the lightness should differ. Error red at L:45%, warning amber at L:65%, success green at L:55%, info blue at L:50%. Under achromatopsia, these become four distinct grays.
+
+3. **Use distinct shapes for status badges:** Error = circle, Warning = triangle, Success = shield/checkmark, Info = square. Material Design uses shape as a primary differentiator for chip states — selected chips change both color AND shape (adding a checkmark).
+
+### Perceptual Uniformity and the OKLCH Advantage
+
+Traditional HSL is perceptually non-uniform: `hsl(60, 100%, 50%)` (yellow) appears far brighter than `hsl(240, 100%, 50%)` (blue) despite identical L values. This means a palette with "equal" HSL steps will have wildly different perceived lightness, causing colorblind users (who rely on lightness) to lose information.
+
+OKLCH fixes this. In OKLCH, L:0.7 looks equally bright regardless of hue. A palette generated with equal OKLCH Lightness spacing guarantees that even under complete color blindness, the lightness progression is perceivable. Modern CSS supports OKLCH natively: `color: oklch(0.7 0.15 250)`.
+
+### Anti-Patterns
+
+1. **Traffic Light Reliance.** Using red/yellow/green as the primary semantic system without any redundant encoding. This is the single most common color accessibility failure. Approximately 1 in 12 males cannot reliably distinguish your red from your green. Fix: add icons (X, triangle, checkmark), add text labels, and ensure the three colors have distinct lightness values (not all at L:50%).
+
+2. **Hue-Only Chart Differentiation.** A pie chart with 5 slices distinguished only by hue. Under deuteranopia, 2-3 slices may become indistinguishable. Fix: add patterns, direct labels, or interactive tooltips. Limit to 3-4 color-only slices maximum, and ensure they span safe pairs (blue, orange, purple, yellow — not red, green, brown, olive).
+
+3. **Red-Green as Primary Semantic Pair.** Using red and green as the two most important status colors without alternatives. Even when icons are added, if the icon is small and the color fill is dominant, colorblind users may struggle with rapid scanning. Fix: consider blue (safe) for the positive state and red (universal danger) for the negative state — blue and red are distinguishable under all common CVD types.
+
+4. **Decorative Color Dependency.** Calendar apps that use color-coded categories without any text or icon label. When 8 calendar categories are distinguished only by color, a colorblind user sees perhaps 4 distinguishable groups. Fix: add category initials, icons, or pattern fills in addition to color.
+
+5. **Ignoring Achromatopsia.** Designing for red-green colorblindness but forgetting total color blindness. If two elements differ in hue but have identical lightness, an achromatopsic user sees them as identical. Fix: ensure every meaningful color distinction also has a lightness distinction of at least 15 OKLCH L units (or ~20 CIELAB L\* units).
+
+### Real-World Examples
+
+**Material Design — Shape + Color for States.** Material Design 3 chips use both color and shape to indicate selection state. An unselected chip has an outlined border with transparent fill. A selected chip gains a tinted fill AND a leading checkmark icon. The checkmark alone communicates "selected" without any color perception. This dual-encoding approach is applied consistently across the entire component library: radio buttons (filled circle), checkboxes (checkmark), toggles (position + fill), and tabs (underline + fill).
+
+**Stripe — Triple Encoding for Error States.** Stripe's form validation uses three simultaneous channels: (1) the input border turns red (`#DF1B41`), (2) an error icon appears to the left of the error message, (3) descriptive error text appears below the input. A colorblind user who cannot perceive the red border still receives the error through the icon and text. This triple-encoding is not defensive — it is better design for all users because it provides faster error recognition through multiple cognitive channels.
+
+**IBM Carbon — Accessible Data Visualization.** IBM's Carbon design system includes an 8-color categorical palette specifically tested under all CVD types. Each color was selected to maintain distinctness under deuteranopia, protanopia, and tritanopia simulation. Additionally, Carbon's chart components default to pattern fills for area charts and shape markers for line charts — making color truly supplementary rather than primary.
+
+## Source
+
+- WCAG 2.1 Success Criterion 1.4.1 — Use of Color — https://www.w3.org/WAI/WCAG21/Understanding/use-of-color
+- Colour Blind Awareness — Prevalence statistics — https://www.colourblindawareness.org/
+- Machado, Oliveira & Fernandes (2009) — "A Physiologically-based Model for Simulation of Color Vision Deficiency" — IEEE TVCG
+- OKLCH Color Space — https://oklch.com/
+- IBM Carbon Accessible Palette — https://carbondesignsystem.com/data-visualization/color-palettes/
+
+## Process
+
+1. Audit all color-dependent information in the design. For each instance where color conveys meaning, identify the redundant encoding (icon, text, shape, pattern) that makes the information perceivable without color.
+2. Select colorblind-safe color pairs for elements that must be distinguishable. Test pairs under deuteranopia and protanopia simulation (covers 7%+ of male users).
+3. Verify perceptual uniformity: ensure all meaningful color distinctions have a lightness difference of at least 15 OKLCH L units. Run the grayscale test.
+4. Test the complete UI under CVD simulation in Chrome DevTools or Figma. Fix any failures before finalizing.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+- **Pairs with:** design-contrast-ratio (contrast is necessary but not sufficient — a design can pass all contrast checks and still fail color independence), design-palette-construction (palette colors must be chosen with CVD in mind), a11y-color-contrast (implementation-level patterns for color and contrast in code).
+- **Sequencing:** Apply after design-palette-construction has defined the color system. Color accessibility is a verification and augmentation step — it may require adding redundant encodings to existing designs.
+
+## Success Criteria
+
+- No information is conveyed by color alone — every color-based meaning has a redundant non-color encoding (icon, text, shape, pattern).
+- All color pairs used for meaningful distinction are safe under deuteranopia and protanopia simulation.
+- Semantic status colors (error, warning, success, info) are paired with distinct icons and text labels.
+- Data visualizations use pattern fills, shape markers, or direct labels in addition to color.
+- The grayscale test passes — all meaningful distinctions are visible when the design is fully desaturated.
+- OKLCH Lightness differences between meaningful color pairs exceed 0.15 (or 15 CIELAB L\* units).
+- The design has been tested under CVD simulation in browser DevTools or Figma for all four types.
+- Form validation uses triple encoding: color change + icon + text message.

package/dist/agents/skills/gemini-cli/design-color-accessibility/skill.yaml

@@ -0,0 +1,34 @@
+name: design-color-accessibility
+version: "1.0.0"
+description: Color independence — conveying information without color alone, colorblind-safe palettes, perceptual uniformity
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - design-contrast-ratio
+  - design-palette-construction
+  - a11y-color-contrast
+stack_signals: []
+keywords:
+  - colorblind
+  - color independence
+  - deuteranopia
+  - protanopia
+  - tritanopia
+  - perceptual uniformity
+  - accessible palette
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/gemini-cli/design-color-harmony/SKILL.md

@@ -0,0 +1,152 @@
+# Color Harmony
+
+> Color wheel relationships — complementary, analogous, triadic, split-complementary, tetradic schemes with usage guidance for building cohesive palettes
+
+## When to Use
+
+- Selecting a color scheme for a new product, brand, or marketing page
+- Evaluating whether an existing palette has structural coherence or is arbitrary
+- Adding accent or secondary colors to an established brand palette
+- Diagnosing why a color combination feels discordant or chaotic
+- Building theme variations (seasonal campaigns, sub-brands) from a base hue
+- Designing data visualizations that need multiple distinguishable series colors
+- Creating dark mode or alternate theme palettes that maintain the same harmony relationships
+- Reviewing a teammate's color choices for structural coherence
+
+## Instructions
+
+1. **Identify the dominant hue.** Every harmonious scheme starts from one anchor. Place it on a 360-degree HSL/HSB wheel. Stripe anchors on purple at approximately 262 degrees (`#533afd`, HSL 253/98%/61%). Vercel anchors on neutral black (achromatic), which means any chromatic accent automatically becomes the dominant hue.
+
+2. **Select a harmony type based on communication goals.**
+
+   | Scheme                   | Wheel Geometry                               | Tension                | Best For                                           |
+   | ------------------------ | -------------------------------------------- | ---------------------- | -------------------------------------------------- |
+   | **Complementary**        | 180 degrees apart                            | High contrast, vibrant | CTAs against backgrounds, hero sections            |
+   | **Analogous**            | Within 30-60 degrees                         | Low tension, cohesive  | Editorial, dashboards, reading-heavy UI            |
+   | **Triadic**              | 120 degrees apart                            | Balanced energy        | Playful brands, children's products, illustrations |
+   | **Split-Complementary**  | Base + two colors adjacent to its complement | Moderate tension       | Most versatile for UI — contrast without clashing  |
+   | **Tetradic (Rectangle)** | Two complementary pairs                      | Maximum variety        | Complex data visualization, multi-brand systems    |
+
+3. **Coordinate value and saturation, not just hue.** Two colors can be harmonious on the wheel but clash violently if one is fully saturated (S:100%, L:50%) and the other is a muted pastel (S:30%, L:85%). Rule: keep saturation within a 20% range across scheme members, or deliberately use one saturated focal point with all others desaturated.
+
+4. **Apply the 60-30-10 distribution.** Assign your scheme colors by visual weight:
+   - **60%** — Dominant (backgrounds, large surfaces). Typically the least saturated.
+   - **30%** — Secondary (cards, sections, supporting elements).
+   - **10%** — Accent (buttons, links, badges, interactive highlights).
+
+   Stripe applies this: ~60% white/light gray backgrounds, ~30% deep navy (`#061b31`) for text and headings, ~10% purple (`#533afd`) for CTAs and interactive elements.
+
+5. **Test harmony under real conditions.** Place scheme colors in actual UI patterns (nav bar, card, button, form) before committing. A scheme that looks balanced as swatches can fail when one color dominates surface area.
+
+6. **Use temperature to reinforce hierarchy.** Warm colors (red, orange, yellow — 0-60 degrees and 300-360 degrees) advance visually. Cool colors (blue, green, violet — 120-270 degrees) recede. Place warm accents on cool backgrounds for natural visual pop. Material Design 3 uses this: warm error reds on cool gray surfaces create immediate attention without competing for spatial dominance.
+
+7. **Validate with a grayscale test.** Convert your palette to grayscale (desaturate completely). If your design still communicates hierarchy — if you can tell primary from secondary from background — your value structure is sound and the harmony will hold. If the grayscale version is an undifferentiated blob, your scheme relies on hue alone and will fail for colorblind users and in low-saturation contexts.
+
+8. **Limit chromatic colors ruthlessly.** Most successful digital products use 1-2 chromatic hues plus a neutral scale plus semantic colors (success, warning, error). Stripe: 1 chromatic (purple) + neutrals. Vercel: 1 chromatic (blue) + neutrals. Linear: 1 chromatic (blue-violet) + neutrals. The pattern is clear — restraint is the hallmark of professional design.
+
+## Details
+
+### The Five Harmony Types in Practice
+
+**Complementary (180 degrees).** The highest-contrast chromatic pairing. Spotify uses a near-complementary scheme: green (`#1DB954`, hue 141) against dark near-blacks with occasional warm coral accents. The green pops because it sits isolated against the achromatic background — a simplified complementary relationship where black serves as the "opposite pole." When using true complements (e.g., blue 220 degrees and orange 40 degrees), desaturate one side or the vibration at the boundary becomes physically uncomfortable (simultaneous contrast).
+
+**Analogous (30-60 degrees).** The safest, most naturally cohesive scheme. Vercel's design system operates in an analogous-to-monochromatic range: pure white, cool grays (hue ~220, S:5-15%), and blue-tinted accents (`#0070F3`, hue 214). The entire system lives within a 30-degree arc of blue. This creates effortless harmony but requires careful contrast management — analogous schemes can become muddy if values are too similar.
+
+**Triadic (120 degrees).** Three equidistant hues produce balanced but energetic schemes. Google's original brand identity uses a near-triadic base: blue (`#4285F4`, hue 217), red (`#EA4335`, hue 5), and yellow (`#FBBC04`, hue 45) — roughly 120 degrees apart with green (`#34A853`, hue 142) as a fourth accent. This works for Google because the brand identity is deliberately playful and multi-dimensional. For most product UIs, triadic schemes are too energetic for sustained use — reserve them for illustrations, empty states, or marketing.
+
+**Split-Complementary.** Take your base hue, find its complement, then use the two hues 30 degrees on either side of that complement. This delivers contrast similar to complementary but with less visual tension. If your primary is blue (220 degrees), the complement is orange (40 degrees), and the split takes yellow-orange (25 degrees) and red-orange (55 degrees). Airbnb uses a split-complementary-adjacent approach: coral-pink primary (`#FF5A5F`, hue 358), with teal (`#00A699`, hue 174) and dark charcoal as supporting colors — the teal sits near the complement of coral.
+
+**Tetradic / Rectangle.** Two complementary pairs forming a rectangle on the wheel. Material Design 3's dynamic color system generates tetradic-like palettes from a single seed: primary, secondary (analogous shift), tertiary (complementary region), and error (fixed red). This is the most complex scheme and requires strict hierarchy — one pair must dominate, the other must be subordinate, or the result is visual chaos.
+
+**Monochromatic (single hue, varied value/saturation).** Technically the simplest harmony — one hue explored through its full tint/shade range. Linear uses this: their blue-violet primary generates all UI states through lightness variation alone (dark for text, medium for icons, light for backgrounds, saturated for buttons). Monochromatic schemes are failsafe for harmony but require strong contrast discipline to maintain hierarchy — since hue provides no differentiation, value must do all the work.
+
+### Simultaneous Contrast and Vibration
+
+When two saturated complements share a boundary at similar lightness, the edge appears to vibrate — a neurological artifact called simultaneous contrast. This is physically fatiguing and makes text unreadable. Solutions:
+
+- **Insert a neutral separator.** A 1-2px white, black, or gray border between complements eliminates vibration. Stripe never places `#533afd` purple directly against a warm hue — there is always a white or dark neutral buffer.
+- **Desaturate one side.** If blue is S:90%, make its orange complement S:40% or lower. The asymmetry removes the vibration while preserving the chromatic tension.
+- **Shift lightness apart.** Complements at L:50% and L:50% vibrate. Shift one to L:30% and the other to L:70% — the lightness difference overrides the hue clash.
+
+### Choosing a Scheme: Decision Procedure
+
+Use this procedure when you are unsure which harmony type to apply:
+
+1. **Count the distinct functional roles** needing color (primary action, secondary action, navigation, status, decorative). If 1-2, use analogous. If 3, use split-complementary. If 4+, use tetradic with strict hierarchy.
+2. **Assess the brand personality.** Conservative/professional brands (finance, healthcare, legal) use analogous or monochromatic. Energetic/playful brands (gaming, social, children's) use triadic or complementary. Technology/premium brands use complementary with heavy neutral dominance.
+3. **Evaluate the content density.** High-density interfaces (dashboards, data tables, IDEs) need analogous schemes — multiple chromatic hues create noise. Low-density interfaces (landing pages, portfolios) can support split-complementary or triadic schemes because there is white space to absorb the energy.
+
+### Temperature and Perceived Weight
+
+Warm colors feel heavier, closer, and more urgent. Cool colors feel lighter, more distant, and calmer. This is physiological — warm wavelengths cause slightly higher arousal. Use temperature strategically:
+
+- **Navigation and structure:** Cool tones (recede, feel stable)
+- **Actions and alerts:** Warm tones (advance, demand attention)
+- **Stripe's approach:** Cool navy (`#061b31`) for structural text, warm purple (`#533afd`) for actions — the temperature shift reinforces the hierarchy without needing extreme lightness contrast.
+- **Apple's approach:** Apple uses a near-achromatic interface (cool grays, white) so that any product photography or UI color becomes the thermal focal point. Their system blue (`#007AFF`) is cool but highly saturated — it acts as a warm-relative accent against the cooler, desaturated surroundings.
+
+### Anti-Patterns
+
+1. **Rainbow Effect.** Using 5+ unrelated hues with no wheel relationship. Symptoms: the interface looks like a carnival. Fix: reduce to a single harmony type with 2-3 chromatic colors maximum, plus neutrals. Every chromatic color must justify its presence through a wheel relationship.
+
+2. **False Harmony.** Colors that are technically related on the wheel (e.g., triadic) but clash because saturation and lightness are uncoordinated. Example: pairing `hsl(0, 100%, 50%)` (pure red) with `hsl(120, 40%, 80%)` (pale sage green) — triadic on paper, discordant in practice. Fix: equalize saturation within 15-20% and align lightness to a shared range.
+
+3. **Ignoring Value Structure.** Selecting hues from the wheel without considering lightness. Two hues at identical lightness (e.g., both at L:50%) create ambiguity — neither dominates, and the eye bounces between them. Fix: establish a clear light-dark hierarchy first, then map hues onto that value structure. Primary actions should be the darkest or most saturated element; backgrounds should be the lightest or most neutral.
+
+4. **Accent Overload.** Using the accent color (10% allocation) across 30%+ of the interface. When everything is highlighted, nothing is. Stripe uses purple on fewer than 10% of pixels — buttons, links, active states. The restraint is what makes those elements stand out.
+
+5. **Harmony Without Function.** Selecting colors purely for aesthetic harmony without assigning functional roles. Every color in a production palette must answer: "What does this color _mean_ in the interface?" If a color exists only because it completes the triadic scheme but has no UI role, remove it — unused scheme members add visual noise when they inevitably leak into edge cases.
+
+### Real-World Examples
+
+**Material Design 3 — Seed-Based Harmony.** MD3 generates an entire palette from a single seed color using the HCT (Hue, Chroma, Tone) color space. A seed of blue (hue 282) produces: Primary (T40 for light, T80 for dark), Secondary (hue shifted +15 degrees, reduced chroma), Tertiary (hue shifted +60 degrees), and Neutral (same hue, near-zero chroma). This is algorithmic analogous harmony — every color shares a perceptual relationship through the seed.
+
+**Stripe — Controlled Complementary.** Stripe's palette is structurally a warm-cool complementary scheme compressed into near-achromatic territory: deep navy (`#061b31`, blue-hue 213 at very low lightness) as the "cool" anchor, and violet-purple (`#533afd`, hue 253) as the "warm-leaning" accent. The decorative palette extends with ruby (`#ea2261`) and magenta (`#f96bee`) — these warm hues complement the cool structural colors but appear only in illustrations and gradients, never in UI chrome.
+
+**Vercel — Monochromatic Discipline.** Vercel's Geist design system operates almost entirely within achromatic space: pure white (`#FFFFFF`), a carefully stepped gray scale, and pure black (`#000000`). The sole chromatic accent is Vercel Blue (`#0070F3`), which carries all interactive and highlight duties. This extreme monochromatic restraint means the single blue accent has enormous visual authority — it does not compete with any other chromatic hue. The lesson: when your harmony type is monochromatic, your single accent color becomes maximally powerful because it owns the entire chromatic channel.
+
+**Spotify — Complementary Isolation.** Spotify Green (`#1DB954`) sits at hue 141 — a mid-green. Against the near-black backgrounds (`#121212`, `#191414`), the green functions as a complementary accent against the implicit warm associations of the dark surface (dark surfaces with slight warm tinting feel cozy). Spotify reinforces this by using warm album art photography as background imagery, creating a natural complementary tension between the cool green UI chrome and the warm content. The green is used sparingly — play button, progress bar, "Follow" CTAs — at well under 10% of surface area.
+
+### Harmony in Multi-Brand Systems
+
+When a product supports multiple tenants or sub-brands (white-label SaaS, marketplace platforms), each brand needs its own palette that still feels at home in the shared chrome. The solution is to fix the harmony type and neutral scale, then allow only the primary hue to change per brand. Shopify's admin uses this: the structural UI is fixed neutral gray, and each merchant's brand color slots into the accent role. The harmony type (monochromatic with single accent) stays constant — only the hue rotates.
+
+For data-heavy multi-brand dashboards, assign each brand a hue from an evenly-spaced tetradic or higher-order scheme, then reduce all to the same saturation (S:60-70%) and lightness (L:45-55%) to ensure equal visual weight. No brand should appear louder than another due to an accidentally more saturated hue.
+
+## Source
+
+- Itten, J. — _The Art of Color_ (1961), foundational color wheel theory
+- Munsell Color System — value/chroma/hue separation framework
+- Material Design 3 Color System — https://m3.material.io/styles/color
+- Tailwind CSS Color Palette — perceptually uniform scale methodology
+- Albers, J. — _Interaction of Color_ (1963), simultaneous contrast and relative color perception
+
+## Process
+
+1. Read the instructions and harmony type reference in this document. Pay particular attention to the decision procedure in the Details section.
+2. Identify your dominant hue, run the decision procedure (functional role count, brand personality, content density) to select a harmony type, and apply the 60-30-10 distribution rule.
+3. Verify your palette passes the grayscale test, the simultaneous contrast check, and does not exhibit any of the five listed anti-patterns.
+4. Test the scheme in actual UI components (not just swatch grids) before committing to implementation.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+- **Pairs with:** design-palette-construction (for building production-ready scales from harmony choices), design-color-psychology (for emotional resonance of chosen hues), design-contrast-ratio (for ensuring harmony choices meet accessibility thresholds).
+- **Sequencing:** Use this skill first to establish the harmonic structure, then design-palette-construction to generate tint/shade scales, then design-contrast-ratio to verify accessibility, then design-color-accessibility to add redundant encoding.
+- **Decision input:** The harmony type selected here determines how many chromatic hues the palette can support, which directly constrains design-palette-construction choices.
+
+## Success Criteria
+
+- The color scheme uses an identifiable harmony type (complementary, analogous, triadic, split-complementary, or tetradic) — not arbitrary hue selection.
+- You can name the harmony type when asked — if you cannot, the scheme is likely arbitrary.
+- Saturation and lightness are coordinated across scheme members (within 20% saturation range unless deliberately focal).
+- The 60-30-10 distribution rule is applied, with accent color usage below 15% of total surface area.
+- No more than 3 chromatic hues are used in the UI palette (plus neutrals and semantic colors).
+- The grayscale test passes — hierarchy is visible even without color.
+- Every chromatic color has an assigned functional role (action, navigation, status, brand). No orphan colors.
+- The scheme passes visual testing in actual UI layouts, not just swatch grids.
+- No simultaneous contrast vibration occurs at color boundaries — verified by visual inspection at 100% zoom.
+- Temperature relationships reinforce hierarchy — warm for actions/alerts, cool for structure/navigation.
+- The palette works in both light and dark contexts (harmony relationships hold across themes).
+- Each harmony choice is documented with the specific wheel geometry (e.g., "split-complementary from base hue 253").

package/dist/agents/skills/gemini-cli/design-color-harmony/skill.yaml

@@ -0,0 +1,35 @@
+name: design-color-harmony
+version: "1.0.0"
+description: Color wheel relationships — complementary, analogous, triadic, split-complementary, tetradic schemes
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - design-color-psychology
+  - design-palette-construction
+  - design-contrast-ratio
+stack_signals: []
+keywords:
+  - color wheel
+  - complementary
+  - analogous
+  - triadic
+  - split-complementary
+  - tetradic
+  - color scheme
+  - hue relationships
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []