visual-design-principles/skills/color-theory-application/SKILL.md
This skill should be used when the user is selecting colors, building color palettes, defining color systems, implementing dark mode, choosing brand colors, creating shade scales, applying the 60-30-10 rule, selecting data visualization colors, or checking color contrast. Covers HSL color model, harmony schemes (complementary, analogous, triadic), systematic shade scale generation, WCAG contrast requirements, semantic color systems, and dark mode design.
npx skillsauth add oborchers/fractional-cto color-theory-applicationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Color decisions made by intuition drift over time. Color decisions made by system scale indefinitely. Pick hues with harmony theory, generate shades with lightness math, enforce contrast with WCAG, and assign meaning with semantic tokens.
Use HSL (Hue, Saturation, Lightness) for all color work. RGB and hex are machine formats — HSL maps to how humans perceive color.
| Task | HSL | RGB/Hex | |------|-----|---------| | Make a color lighter | Increase L | Guess and check all 3 channels | | Create a complementary color | Rotate H by 180 degrees | No intuitive relationship | | Generate a shade scale | Fix H and S, vary L in steps | Manual trial and error |
For perceptual uniformity in production, consider OKLCH (oklch(L C H)) — it corrects HSL's lightness distortion across hues.
| Tier | Percentage | Role | Typical Choice | |------|-----------|------|----------------| | Dominant | 60% | Backgrounds, surfaces | Neutral (white, light gray, dark gray) | | Secondary | 30% | Cards, sidebars, borders | Tinted neutral or subdued brand | | Accent | 10% | CTAs, highlights, active states | Saturated brand color |
Limit to 3-6 distinct hue families. Most successful SaaS products use a single brand hue plus neutrals and semantic colors.
Generate 9 steps (50-900) by fixing hue, varying lightness, and reducing saturation 5-15% at extremes.
| Step | Lightness | Use Case | Step | Lightness | Use Case | |------|-----------|----------|------|-----------|----------| | 50 | 95-97% | Subtle backgrounds | 500 | 45-50% | Base color | | 100 | 90-92% | Light backgrounds | 600 | 38-42% | Hover states | | 200 | 82-85% | Borders, dividers | 700 | 28-32% | Active/pressed | | 300 | 70-75% | Disabled states | 800 | 20-23% | Dark text | | 400 | 58-62% | Placeholder text | 900 | 12-15% | Headings |
Apply WCAG AA contrast ratios (see accessibility-inclusive-design skill for the full requirements). In practice: text on the 500 shade rarely passes against white. Use 600-900 for text, 50-200 for backgrounds. Always verify with a contrast checker.
Never use #000000. Pure black creates 21:1 contrast against white, causing eye fatigue. Use brand-tinted dark grays instead: hsl(220, 15%, 12%) for text, hsl(220, 15%, 10%) for dark backgrounds.
Assign fixed meaning: success = green, warning = amber, error = red, info = blue. Never repurpose these hues. Always pair color with redundant encoding (see accessibility-inclusive-design skill for color independence rules).
Dark mode is not an inversion:
hsl(H, 10-15%, 10-12%) for backgrounds| Scheme | Hue Relationship | Best For | |--------|-----------------|----------| | Complementary | 180 degrees apart | CTAs, alerts | | Analogous | 30 degrees apart | Backgrounds, gradients | | Triadic | 120 degrees apart | Data visualization | | Split-complementary | 150 + 210 degrees | Versatile; safer than complementary |
| Anti-Pattern | Fix |
|-------------|-----|
| More than 6 hue families | Limit to 3-6 hues maximum |
| No contrast verification | Test every text/background pair (see accessibility-inclusive-design for ratios) |
| Pure black (#000) | Use brand-tinted dark grays |
| Color as the sole indicator | Apply color independence rule (see accessibility-inclusive-design skill) |
| Inverting colors for dark mode | Reduce saturation 10-20%; use dark grays |
Working implementations in examples/:
examples/color-system-and-dark-mode.md — Complete HSL-based color system with shade scale generation, semantic tokens, and dark mode in CSS, Tailwind, and ReactWhen reviewing or building color systems:
accessibility-inclusive-design skill)accessibility-inclusive-design skill)tools
This skill should be used when the user invokes any /plan-* command from the planning-tools plugin (/plan-context, /plan-master, /plan-open-questions, /plan-verify, /plan-tick, /plan-progress, /plan-delete), asks how Claude Code's plan files work, asks where plans are stored, asks to author or audit a multi-phase master planning document, asks how to walk through a plan's Open Questions interactively, asks how to write progress entries, or mentions ~/.claude/plans/ or .claude/planning-tools.local.md. Provides the index of planning-tools commands, the master-plan workflow lifecycle, the v0.3.0+ list-shape mandate (phases and questions as headings + bulleted scope items, never tables), the v0.3.2+ plain-bullet shape (no `- [ ]` checkboxes — heading emoji is the sole tick signal), the progress-entry methodology, and the mechanics of Claude Code's plan-mode file storage.
testing
This skill should be used by the plan-verifier agent and the /plan-verify command to audit a drafted master plan against a fixed checklist. Covers universal-core completeness, the v0.3.0+ no-tables-for-phases-or-questions rule, trigger-based section-coverage gaps, phase actionability (heading + per-phase TL;DR + bulleted scope + exit criteria), the v0.3.1+ per-phase TL;DR requirement, the v0.3.2+ plain-bullet scope shape (legacy `- [ ]`/`- [x]` accepted silently), the v0.3.3+ context-block shape (plan-level `**TL;DR:**` + bulleted metadata, legacy `>` blockquote accepted silently), integer phase numbering enforcement, dependency traceability, citation resolution, callout/evidence convention compliance, Open Questions placement, and the one-PR-per-master-plan rule. Single-owner of the audit checklist.
tools
This skill should be used when authoring, reviewing, or modifying a multi-phase master planning document via the planning-tools plugin (especially the /plan-master and /plan-verify commands). Codifies the universal core sections, trigger-based optional sections, integer-only phase numbering, Open Questions placement, one-PR-per-plan rule, status conventions, evidence attribution, callouts, cross-reference formats, the v0.3.0 list-shape mandate (phases and questions are heading + bulleted list, never markdown tables), the v0.3.1 per-phase TL;DR requirement (1–3 sentence what/why summary under each phase heading for glance-ability), the v0.3.2 plain-bullet scope shape (`- <action>` items, no `- [ ]` checkboxes — the phase status emoji is the sole tick signal), and the v0.3.3 context-block shape (a plan-level `**TL;DR:**` + a bulleted metadata list instead of a `>` blockquote; legacy blockquote blocks accepted silently). Project-agnostic — no ticket-prefix or plan-type taxonomy.
testing
This skill should be used when the user is adjusting spacing, padding, margins, content density, section gaps, vertical rhythm, or separation between elements. Also applies when reviewing whether a design feels cramped or too sparse, choosing between borders and whitespace for separation, or defining a spacing system. Covers the 4px/8px spacing system, macro vs micro whitespace, content density spectrum, separation techniques (whitespace > background shifts > borders), and vertical rhythm.