Claude Code Skills for Brand Colors: Stop Re-Explaining Your Palette to Your Agent

What is a ColorwayKit skill?

A skill is an instruction file your coding agent reads by itself — no copy-pasting context into every conversation. In Claude Code it lives in the repo as Markdown the agent loads alongside your code; Cursor and Codex read the equivalent rules files. The content is what matters: a DESIGN.md contract that lists 23 named color roles for light and dark mode, the hex value for each, and the rule that no text/background pair ships unmeasured.

That last part is the difference between a style guide nobody opens and a system the agent actually follows. "Use our brand orange for primary" is a suggestion; "primary is #EA580C, and anything you put on top of the page background must pass the ratio you can check with check_pair" is a contract with a number attached.

What comes in the template pack?

The colorwaykit-for-agents repository on GitHub is free and holds the current set: a DESIGN.md template with the full token contract and the WCAG 2.1 / APCA measurement rules, lighter variants for smaller repos that only need the essentials, and a worked example generated from a real brand hex so you can see a filled-in file before you commit one. Everything is plain Markdown — no build step, no lock-in, diff-friendly.

Copy the template closest to your setup, adapt the paths, and it is live for every agent that reads your repo. When your brand evolves, you regenerate the values on the site and commit the diff like any other file.

How do I set it up in Claude Code or Cursor?

Three steps, about five minutes:

• Copy a template from the GitHub repo into your project — as a Claude Code skill in .claude/skills, as .cursorrules for Cursor, or as the repo-level AGENTS.md both tools read.
• Generate your theme: paste the brand hex from your logo or guidelines into the Brand Theme Engine, tune the light and dark variants, export the DESIGN.md.
• Reload and ask your agent "what is our primary color?" — the right answer is the role name, the hex and its measured ratio, not a guess.

Skills or MCP — which one do I need?

They are two halves of one system, and they compose:

• Skills (file): the contract is versioned with your code, works offline, and applies to every teammate and every CI run — best as the default source of truth.
• MCP (live): the agent pulls the current engine output mid-task, validates a color pair it just invented, and reads cloud projects you tuned in the browser — best for checking work as it happens.
• Recommended setup: keep the skill as the contract, connect the MCP server as the measurement tool. The file tells the agent what to do; MCP lets it prove the result.

What actually changes once the skill is loaded

The measurable difference shows up in review. Without a contract, an agent asked for "a muted label on a cream panel" picks #A89890 on #FFF7F3 — which measures 2.63:1 against the 4.5:1 body-text threshold, APCA Lc 49.7. Both fail, and nothing in a prompt-only workflow ever catches it.

With the skill loaded and MCP connected, the agent checks the pair before it lands: check_pair returns the failing numbers plus #7d6e67, a fix that keeps the hue and just clears 4.5:1. The label ships accessible on the first pass instead of the second review.

Keeping the skill in sync with your brand

A skill is only as good as the values in it. When the brand evolves, regenerate the theme in the Brand Theme Engine, export a fresh DESIGN.md, and commit the diff — the change is reviewable line by line. The MCP server always reads the latest engine output, so the live checks never lag behind the rebrand even before you update the file.

References

• Model Context Protocol — specification
• WCAG 2.1 — W3C Recommendation
• APCA — Accessible Perceptual Contrast Algorithm

FAQ