@harness-engineering/cli 1.23.2 → 1.24.1

package/dist/agents/skills/cursor/design-apple-hig/skill.yaml

@@ -0,0 +1,38 @@
+name: design-apple-hig
+version: '1.0.0'
+description: Apple Human Interface Guidelines covering clarity/deference/depth, vibrancy and materials, SF Symbols, semantic colors, safe areas, and platform-specific navigation
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - design-elevation-shadow
+  - design-navigation-ux
+  - design-typography-fundamentals
+stack_signals: []
+keywords:
+  - apple
+  - HIG
+  - human-interface-guidelines
+  - iOS
+  - macOS
+  - SF-Symbols
+  - vibrancy
+  - materials
+  - safe-areas
+  - semantic-colors
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/design-atomic-design/SKILL.md

@@ -0,0 +1,172 @@
+# Atomic Design
+
+> Composition methodology for building design systems using five distinct levels of abstraction: atoms, molecules, organisms, templates, and pages.
+
+## When to Use
+
+- Starting a new design system from scratch and need a structural taxonomy for components
+- Refactoring an existing component library that has inconsistent granularity
+- Deciding whether a UI element should be a standalone component or part of a larger one
+- Onboarding developers or designers who need a shared vocabulary for component hierarchy
+- Evaluating whether your system is over-atomized (too many tiny pieces) or under-decomposed (too many monoliths)
+
+## Instructions
+
+Apply Brad Frost's atomic design methodology as a mental model for component decomposition, not as a rigid folder structure. The five levels describe a spectrum of complexity and composition. Every component in your system should map to exactly one level, and that mapping should be defensible.
+
+**The decision procedure for level assignment:**
+
+1. Does this element wrap zero child components and render a single HTML concept? It is an **atom**.
+2. Does this element compose 2-4 atoms into a single functional unit with one responsibility? It is a **molecule**.
+3. Does this element compose molecules and/or atoms into a distinct section of interface with its own domain logic? It is an **organism**.
+4. Does this element define the layout and content placement for a full view without real data? It is a **template**.
+5. Does this element hydrate a template with real data, forming the final user-facing screen? It is a **page**.
+
+If you cannot cleanly assign a component to one level, the component likely has mixed responsibilities and should be split.
+
+## Details
+
+### The Five Levels in Depth
+
+**Atoms** are the foundational building blocks. They cannot be broken down further without ceasing to be functional. An atom is self-describing: it has a single visual and semantic purpose.
+
+- A `Button` atom: renders `<button>` with `variant` (primary, secondary, ghost), `size` (sm, md, lg), `disabled`, and `loading` props. It contains no knowledge of where it appears.
+- A `TextInput` atom: renders `<input>` with `label`, `placeholder`, `error`, `helperText`. It does not know it lives in a search bar or a login form.
+- An `Avatar` atom: renders a circular image with `src`, `size` (24px, 32px, 40px, 48px), `fallback` (initials). It does not know it is part of a user card.
+
+Stripe's design system treats `Badge`, `Button`, `Icon`, `Spinner`, and `Text` as atoms. Each has zero child component dependencies.
+
+**Molecules** combine atoms into functional groups. The litmus test: does removing any atom from the molecule break its purpose?
+
+- A `SearchInput` molecule: composes `TextInput` + `Icon` (search) + `Button` (clear). Remove the input and it is not a search bar. Remove the icon and it loses affordance.
+- A `FormField` molecule: composes `Label` + `TextInput` + `HelperText` + `ErrorMessage`. The field is the unit of validation feedback.
+- GitHub Primer's `TextInputWithTokens` is a molecule: `TextInput` + multiple `Token` atoms, composed to handle multi-value input.
+
+**Organisms** are complex, self-contained interface sections. They often have internal state or connect to domain logic.
+
+- A `NavigationHeader` organism: composes `Logo` (atom) + `NavLinks` (molecule) + `SearchInput` (molecule) + `UserMenu` (molecule). It manages responsive collapse behavior internally.
+- Shopify Polaris's `ResourceList` is an organism: it composes `ResourceItem` molecules, handles selection state, sorting, filtering, and bulk actions.
+- Salesforce Lightning's `DataTable` is an organism: it composes `Column`, `Row`, `Cell` atoms/molecules and manages sort, resize, and infinite scroll.
+
+**Templates** define the structural layout of a complete view using placeholder content. They answer "where does each organism go?" without answering "what data fills it?"
+
+- A `DashboardTemplate` places `NavigationHeader` at top, `Sidebar` at left (240px), `MainContent` in a 12-column grid, `Footer` at bottom. All content slots accept children.
+- Material Design's responsive layout grid (12 columns, 8px baseline grid, breakpoints at 600/905/1240/1440px) is a template-level concern.
+
+**Pages** are templates hydrated with real or representative data. They are the final artifact for testing, review, and QA.
+
+- A `DashboardPage` fills `DashboardTemplate` with fetched analytics data, user profile, notification count. This is what Storybook shows under the "Pages" section.
+
+### The Abstraction Decision Framework
+
+The hardest design system decision is choosing the right level of abstraction. Use this framework:
+
+**Reuse frequency test.** Count how many places a component appears in your application. If a molecule appears in only one organism, question whether it needs to be extracted. Premature extraction creates inventory bloat.
+
+| Occurrences | Recommendation                                     |
+| ----------- | -------------------------------------------------- |
+| 1           | Keep inline unless it has independent test value   |
+| 2-3         | Extract if the instances are identical in behavior |
+| 4+          | Extract unconditionally                            |
+
+**Independence test.** Can the component be understood without its parent context? A `PriceTag` molecule (icon + formatted currency + label) is independently meaningful. A `DashboardHeaderLeftSection` is not -- it is a layout fragment, not a reusable concept.
+
+**Stability test.** How often does the component's interface change? Atoms should be extremely stable (change less than once per quarter). Organisms may change monthly. If an atom's props churn frequently, it is probably a molecule or organism in disguise.
+
+### Mapping to File Structure
+
+Atomic design is a mental model, not a mandatory folder layout. Two viable approaches:
+
+**Flat by level** (recommended for systems under 100 components):
+
+```
+components/
+  atoms/       Button, Icon, Text, Avatar, Badge
+  molecules/   SearchInput, FormField, NavLink
+  organisms/   Header, DataTable, Modal
+  templates/   DashboardLayout, SettingsLayout
+  pages/       DashboardPage, SettingsPage
+```
+
+**Grouped by domain** (recommended for systems over 100 components):
+
+```
+components/
+  navigation/  NavLink (molecule), Header (organism), Sidebar (organism)
+  forms/       TextInput (atom), FormField (molecule), LoginForm (organism)
+  data/        Badge (atom), DataTable (organism), Chart (organism)
+```
+
+IBM Carbon uses domain grouping: `DataTable`, `DatePicker`, `Notification` each in their own directory, with sub-components (atoms/molecules) co-located.
+
+### Anti-Patterns
+
+**Over-atomization.** Extracting every `<span>`, `<div>`, or styled wrapper into a component. If your atoms directory has `Wrapper`, `Spacer`, `Divider`, `Container`, and `Box` that are each under 10 lines, you have decomposed past the point of utility. A `Spacer` component with a single `margin` prop is not an atom -- it is a CSS utility masquerading as a component. Tailwind's utility classes or a spacing token solve this better.
+
+**Level-skipping composition.** An organism that directly uses raw HTML elements instead of atoms. If your `Header` organism renders `<button className="...">` instead of using `<Button>`, you have bypassed the system. Every visual element in an organism should trace back to a system atom. Stripe enforces this by making raw HTML elements a linting violation inside organism-level components.
+
+**Template-organism conflation.** Building organisms that assume a specific layout position. A `Sidebar` organism that hardcodes `position: fixed; left: 0; width: 240px` is not reusable -- it has absorbed template-level layout concerns. The sidebar's position should be controlled by the template; the organism should only define its internal layout.
+
+**Premature page extraction.** Creating page-level components before the template layer is stable. Pages are the most volatile level and should be built last. If you start with pages and extract downward, you get organisms shaped to one specific page rather than reusable across templates.
+
+**Molecule bloat.** A molecule that composes 6+ atoms is likely an organism. If your `UserCard` has avatar, name, title, department, email, phone, and action buttons, it has grown past molecule complexity. The test: can you identify two sub-groups within it that are independently meaningful? If yes, those sub-groups are molecules and the whole thing is an organism.
+
+### Cross-Level Dependency Rules
+
+The atomic hierarchy implies strict dependency direction: higher levels depend on lower levels, never the reverse.
+
+**Allowed dependencies:**
+
+```
+Pages -> Templates -> Organisms -> Molecules -> Atoms
+```
+
+**Forbidden dependencies:**
+
+- An atom importing a molecule (e.g., `Button` importing `SearchInput`)
+- A molecule importing an organism (e.g., `FormField` importing `Header`)
+- A template importing a page (templates are data-agnostic)
+
+**Same-level dependencies** are allowed but should be minimized. A molecule can use another molecule (a `DateRangePicker` molecule composes two `DatePicker` molecules), but excessive same-level coupling suggests a missing intermediate abstraction.
+
+**Dependency audit procedure:** For each component, list its imports. If any import is from the same level or higher, flag it for review. GitHub Primer automates this with an ESLint rule that enforces import direction based on directory structure.
+
+### Handling Edge Cases
+
+**Components that span levels.** A `Popover` seems like an atom (it is a single visual element) but it composes internal atoms (arrow, backdrop, content container) and manages complex state (positioning, focus trap). It is a molecule. The test is not visual simplicity but compositional complexity.
+
+**Utility components.** `Portal`, `VisuallyHidden`, `FocusTrap`, and `AnimatePresence` do not fit cleanly into atomic levels because they produce no visible output. Treat them as infrastructure -- they live outside the atomic hierarchy in a `utilities/` directory and can be imported by any level.
+
+**Design tokens as sub-atomic.** Tokens (colors, spacing, typography values) exist below the atomic level. They are the properties that atoms consume, not components themselves. Brad Frost calls them "the protons and neutrons" that make up atoms.
+
+### Real-World Examples
+
+**Shopify Polaris** organizes components into four tiers (Actions, Layout, Navigation, Overlays) but the internal structure follows atomic principles. Their `Button` (atom) is composed into `ButtonGroup` (molecule), which appears inside `Card` headers (organism). The `Page` component is explicitly a template: it defines title area, primary/secondary actions, and a content slot. Their Storybook organizes stories by atomic level, making the hierarchy browsable.
+
+**Atlassian Design System** serves multiple products (Jira, Confluence, Bitbucket) from a shared atomic foundation. Their `@atlaskit/button` atom has 12 appearances (default, primary, subtle, link, etc.) and is composed into toolbar molecules across all products. They found that organisms are the level where product-specific divergence starts -- so atoms and molecules are shared, but organisms may be product-scoped. Their package structure reflects this: `@atlaskit/button` (atom, 1.2M weekly downloads) vs `@atlaskit/jira-issue-view` (organism, Jira-only).
+
+**Material Design 3** defines atoms as "building blocks" (FAB, IconButton, Chip), molecules as "communication" components (Snackbar, Dialog), and organisms as "containment" patterns (Card, NavigationDrawer). Their component spec sheets explicitly list which lower-level components each higher-level component uses, creating a traceable dependency graph. Every M3 component page includes a "Components used" section showing its atomic dependencies.
+
+**Apple Human Interface Guidelines** do not use atomic terminology but follow the same decomposition. SF Symbols are atoms. A `Toggle` with label is a molecule. A `Settings` pane with grouped toggles, navigation, and search is an organism. Apple's platform-specific templates (NavigationSplitView on macOS, TabView on iOS) define the layout skeleton that organisms fill. Their SwiftUI component library enforces composition through view modifiers -- atoms accept modifiers but never compose other named components internally.
+
+**GitHub Primer** maps their React component library to atomic levels in their architecture documentation. `Button`, `Label`, `Avatar`, and `CounterLabel` are atoms. `ButtonGroup`, `AvatarPair`, and `BranchName` are molecules. `ActionMenu`, `Dialog`, and `SelectPanel` are organisms. Their compound component pattern (e.g., `ActionMenu.Button` + `ActionMenu.Overlay`) demonstrates how organisms compose molecules through React context rather than prop drilling.
+
+## Source
+
+Brad Frost, _Atomic Design_ (2016). Chapter 2: "Atomic Design Methodology." The five levels were first proposed as a blog post in 2013 and refined through application across hundreds of design systems. Dan Mall's "Design System in 90 Days" extends the methodology with adoption-focused heuristics.
+
+## 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/cursor/design-atomic-design/skill.yaml

@@ -0,0 +1,36 @@
+name: design-atomic-design
+version: '1.0.0'
+description: Composition methodology for building design systems using atoms, molecules, organisms, templates, and pages
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - design-component-anatomy
+  - design-design-governance
+stack_signals: []
+keywords:
+  - atomic-design
+  - atoms
+  - molecules
+  - organisms
+  - templates
+  - pages
+  - Brad-Frost
+  - composition
+  - abstraction
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/cursor/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/cursor/design-brand-consistency/skill.yaml

@@ -0,0 +1,36 @@
+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
+stability: static
+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/cursor/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.