TBKLabs
Pilot Decision Brief
Pilot 03 of 23 · Impeccable Integration

Colorize

Maps to your existing color-strategy skill (★★★★☆). Same enhance-vs-replace question as typeset. The brief proposes Enhance, with significant additions that go past Impeccable's source.

My Recommendation

Enhance — not Replace

Same pattern as typeset. Your existing color-strategy has structure Impeccable's source doesn't (5-phase audit, 12-role color taxonomy, kit integration). Impeccable has substance you don't (tinted neutrals, OKLCH chroma reduction at extreme lightness, dark-mode-as-different-mode, anti-reflex hue selection). Net-new TBK additions on top: state-color matrix, brand-vs-semantic collision handling, color-in-data-viz vs UI distinction, focus-ring contrast, text-on-image overlay handling. Result is a v2 that goes well past either source.

Your color-strategy skill is what Claude consults whenever it's about to make color choices in a design — picking a brand accent, building out the semantic palette (success/warning/error/info), assigning text and background colors, building dark mode, checking contrast against accessibility standards.

It's already a strong skill at ★★★★☆ (8/10). Where it falls short is on a few specific areas Impeccable handles well: tinted neutrals (pure gray feels lifeless next to a colored brand — add 0.005–0.015 chroma toward the brand hue), OKLCH at extreme lightness (reduce chroma as you approach white or black), dark mode as fundamentally different (depth comes from surface lightness, not shadow; reduce body text font-weight for light-on-dark), and anti-reflex hue selection (don't reach for blue 250 or warm orange 60 just because they're the AI defaults).

Beyond Impeccable, there are real gaps in BOTH sources that I'll fill on the way through: state color matrix (hover/active/focus/disabled), brand-vs-semantic collision handling (what to do when brand color IS red), focus ring contrast specifics, text-on-image overlay handling, separate palettes for data viz vs UI, and color drift detection (catching devs who use raw hex values instead of tokens).

Now · v1.0

Your color-strategy today

  • 5-phase audit structure (audit existing → establish system → OKLCH → accent application → WCAG)
  • 12-role color taxonomy (background, surface, border, text-primary/secondary/muted, brand, semantic ×4, info)
  • 60/30/10 rule with explicit pixel-area framing
  • Concrete OKLCH code examples (brand scale + semantic colors)
  • Where accent goes / doesn't go (yes/no list)
  • WCAG contrast tables (3:1 / 4.5:1 / 7:1)
  • Banned: purple-blue gradients, gray-on-colored, semantic overloading, opacity for variants
  • CHAIN: integration with kit
  • No tinted neutrals — your dark-mode tokens use chroma=0 (pure gray)
  • No OKLCH chroma reduction at extreme lightness (high chroma + extreme lightness = garish)
  • No anti-reflex hue selection — Claude defaults to blue 250 / warm orange 60
  • No "dark mode is not inverted light mode" reframe + depth-via-lightness rule
  • No font-weight reduction for light-on-dark (350 instead of 400)
  • No token hierarchy split (primitive layer vs semantic layer)
  • No "alpha is a design smell" principle + when alpha IS appropriate
  • No state color matrix (hover/active/focus/disabled colors)
  • No brand-vs-semantic collision handling (when brand color IS red/green)
  • No data-viz palette guidance (sequential/diverging/categorical, distinct from UI)
  • No focus ring contrast specifics (3:1 minimum, often missed)
  • No text-on-image overlay rules (gradient + blur + dark scrim)
  • No color drift detection / token enforcement pattern
Proposed · v2.0

Your color-strategy enhanced

  • Everything above — kept verbatim
  • + Tinted neutrals — add 0.005–0.015 chroma to all neutrals, hued toward THIS project's brand
  • + Anti-reflex hue selection — explicit ban on reaching for blue 250 / warm orange 60
  • + OKLCH chroma reduction at extreme lightness (light blue at 85% wants 0.08 chroma, not 0.15)
  • + Dark mode as fundamentally different mode (depth from lightness, not shadow)
  • + Dark mode 3-step surface scale at 15%/20%/25% lightness
  • + Body text font-weight reduction in dark mode (350 instead of 400)
  • + Token hierarchy: primitive tokens (--blue-500) + semantic tokens (--color-primary)
  • + "Alpha is a design smell" + when transparency IS appropriate (focus rings, interactive states)
  • + Dangerous color combinations list (red/green colorblindness, yellow on white, blue on red vibration)
  • + State color matrix (hover/active/focus/disabled with explicit lightness/chroma shifts)
  • + Brand-vs-semantic collision handling (when brand IS red/green)
  • + Color in data viz — sequential/diverging/categorical palettes (separate from UI accents)
  • + Focus ring contrast specifics (3:1 minimum, must show on every interactive)
  • + Text-on-image overlay handling (gradient scrim + blur + tinted overlay)
  • + Non-color information signals (icon + color, never color alone for status)
  • + Color drift detection — catch raw hex values bypassing tokens
  • + Apache 2.0 attribution to Bakaus / Impeccable / Anthropic frontend-design
  • + Frontmatter version: 2.0; v1 archives to _archive/color-strategy-v1/
Net effect: v2 is significantly deeper than either source. Methodology stays yours. Impeccable's content fills the perception/dark-mode/tinted-neutrals gap. TBK additions cover state colors, brand-vs-semantic collision, data viz, focus rings, text-on-images, color drift — areas neither source addresses.
01

Tinted neutrals IMP

Add 0.005–0.015 chroma to every neutral, hued toward the project's brand color. Pure gray feels lifeless next to a colored brand.

What it means for you: the difference between a UI that feels designed and one that feels assembled. Subconscious cohesion.
02

Anti-reflex hue selection IMP

Don't reach for blue (hue 250) or warm orange (hue 60) by reflex — those are the dominant AI-design defaults.

What it means for you: same anti-monoculture pressure that the typeset reflex-reject list applies to fonts, applied here to color choice.
03

OKLCH chroma at extreme lightness IMP

Reduce chroma as you approach white or black. A light blue at 85% lightness wants ~0.08 chroma, not the 0.15 of your base color.

What it means for you: high-chroma + extreme-lightness colors look garish. This is why naive scales feel off — and the fix is mathematical.
04

Dark mode as fundamentally different IMP

Not "invert the colors." Depth comes from surface lightness, not shadow. Build a 3-step surface scale at 15%/20%/25% lightness.

What it means for you: shifts dark mode from "afterthought" to "first-class design pass." The reason most dark modes feel wrong.
05

Body font-weight in dark mode IMP

Reduce body text weight slightly (350 instead of 400) because light text on dark reads as heavier than dark text on light.

What it means for you: a non-obvious tip. Dark-mode pages stop feeling cramped, even if you can't articulate why.
06

Token hierarchy: primitive + semantic IMP

Two layers. Primitive tokens (--blue-500) are the raw colors. Semantic tokens (--color-primary) reference primitives. Dark mode only redefines the semantic layer.

What it means for you: when you change the brand color, you change one variable. When you swap dark mode, you redefine semantic only. Less drift, faster updates.
07

"Alpha is a design smell" IMP

Heavy use of transparency usually means an incomplete palette. Define explicit overlay colors instead. Exception: focus rings and interactive states.

What it means for you: elevates a vague principle (your existing skill bans opacity for variants) into an overarching rule with explicit exceptions.
08

Dangerous color combinations IMP

Explicit list: red on green (8% colorblindness), yellow on white (always fails), blue on red (vibrates), thin light text on images (unpredictable).

What it means for you: specific combos to watch for, not just "test contrast generically."
09

State color matrix TBK

Explicit lightness/chroma shifts for hover, active, focus, disabled, danger states. Hover = -3% lightness. Active = -8% lightness. Disabled = 50% chroma reduction.

What it means for you: stops Claude from improvising state colors per component. Every interactive uses the same delta from base.
10

Brand-vs-semantic collision TBK

What to do when brand color IS red (Coca-Cola, Target, Netflix) or green (Whole Foods, Spotify). Brand stays brand; semantic error/success uses a different hue or pattern + color.

What it means for you: a real design problem nobody else writes about. Without this rule, brand red and error red collapse into each other.
11

Color in data viz vs UI TBK

Different palettes. Sequential (single-hue gradient for ordered data), diverging (two-hue for centered data), categorical (max 8 distinguishable hues). Never reuse UI accent colors as chart colors.

What it means for you: stops the "every chart is in brand colors" pattern that makes data unreadable when there are more than 3 categories.
12

Focus ring contrast TBK

3:1 minimum against the background, must be visible on every interactive element. Never rely on browser default — it fails in design systems with custom backgrounds.

What it means for you: a11y failure most commonly missed in custom designs. WCAG SC 2.4.7 requires it; most "designed" UIs fail.
13

Text-on-image overlays TBK

Gradient scrim (linear-gradient from transparent to dark) + optional blur backdrop + tinted overlay. Don't pray contrast works on the image — guarantee it.

What it means for you: hero sections with text over photos stop being a contrast lottery.
14

Non-color information signals TBK

Status communicated by icon + color, never color alone. "Red dot" + warning icon. "Green check" + success icon. WCAG SC 1.4.1 requires it; pure-color status fails for colorblind users.

What it means for you: baked-in accessibility for status indicators. The pattern that makes a UI work for the 8% of male users with red-green colorblindness.
15

Color drift detection TBK

Grep the codebase for raw hex values (#xxxxxx) that should be tokens. Surface every drift instance. CI check pattern that fails the build on new raw hex.

What it means for you: tokens drift the moment a developer pastes a one-off hex. This catches it.
16

Skip secondary/tertiary unless needed IMP

Most apps work fine with one accent. Adding more creates decision fatigue and visual noise.

What it means for you: directly counter to your existing 12-role taxonomy that includes "Brand Secondary." This rule says skip it unless real need.
17

60-30-10 as visual weight IMP

Reframe: not pixel count. About visual weight. Accents work BECAUSE they're rare. Overuse kills their power.

What it means for you: sharper framing of a rule you already have. Pixel count is the easy-to-measure version; visual weight is what actually matters.
18

Dark mode never pure white text TBK

Light text on dark backgrounds maxes at ~96% lightness, not pure white. Pure white on dark glares — same reason pure black on light vibrates.

What it means for you: the canonical "dark mode looks harsh" fix. Most AI-generated dark modes use pure white text.

Existing location: design/color-strategy/. Same Gnesis violations as typeset (no design domain in v1.0; "color-strategy" is a noun-noun without a proper suffix). Same grandfathering rule applies — existing folders migrate in batches, not retroactively.

Path B

Rename, same domain

Rename to noun + suffix per Rule 3, keep in design/.

design/color-rules/
PRO
Rule 3 conformant (noun + suffix). Plural for collection of rules.
CON
CHAIN: color-strategy references in other skills break.
CON
Inconsistent with typeset decision (we kept its legacy name).
Path C

Full migration

Move to product/, rename to noun + suffix.

product/color-rules/
PRO
Fully Gnesis v1.0 conformant.
CON
Sits alone in product/ while every other design skill stays in design/.
CON
All CHAIN: references break.
Why Path A: consistent with the typeset decision. Migrating color-strategy alone while motion-design / responsive-design / etc. all stay put creates exactly the inconsistency the batched-migration rule prevents. Same logic that won the day for typeset.
Skill or command?
Skill. Multiple phases, CHAIN integration, auto-discovers when color decisions are imminent.
Version bump?
Frontmatter version: 2.0. v1 moves to _archive/color-strategy-v1/ per Rule 9.
Rating change?
★★★★☆ (8/10) → ★★★★★ (10/10). Same logic as typeset — v2 scope justifies the bump.
Attribution?
Apache 2.0. Frontmatter line + body section crediting Bakaus / Impeccable / Anthropic frontend-design + named TBK additions. Structured for lift into _attribution.md.
Quality bar?
Aiming 9-10/10 on each axis. Target ~600 lines (v1 is 230). Significant push past Impeccable's source, same as microcopy-rules.
Your decisions · check what applies

Tell me yes or no on these four