hue: a Claude Code and Codex skill that turns a brand into a design system

The problem hue addresses: brand drift across assistant sessions

An AI coding assistant has no memory of your brand between sessions. You ask for a pricing page on Monday, a settings screen on Tuesday, and you get two different type scales, two different greys, and two different button radii. The usual fix is pasting a style guide into the prompt each time, which is tedious and still leaves the model free to invent tokens.

hue takes a different route. It is a skill, not an application. The repository ships a SKILL.md plus scripts and references, and it installs into the skills directory that Claude Code or Codex reads. Once installed, the assistant recognizes trigger phrases such as "make a design skill from cursor.com" and walks through an analysis of the target brand. The output is a generated skill folder containing color tokens, typography, spacing, components, light and dark mode, hero stage recipes, and icon kit selection.

The audience is narrow and specific: people who build UI through an AI assistant and care that the result looks like one product rather than a collage. The README claims the generated skill is "opinionated enough that two different sessions using the generated skill produce visually consistent output." That is the whole value proposition. It is not a design system you hand to a design team; it is a constraint layer for a model.

How hue generates a design language from a URL or screenshot

There is no build step and no server. The mechanism is a skill folder that the assistant loads as context. The top level of the repository contains SKILL.md, a docs directory, references, scripts, and an examples directory with seventeen brand folders. Each example folder holds a design-model.yaml and a landing-page.html; ridge and stint also ship an app-screen.html, and halcyon ships a full component-library.html.

The design-model.yaml is the intermediate representation. It carries the tokens and the component definitions that the generated skill will reference. The HTML files are renderings of that model, which is why the README suggests opening them in a browser to see the system applied. That structure matters for evaluation: you can read a YAML file and judge whether the token set is coherent before you ever point hue at a real brand.

The validation layer is the part worth paying attention to. Every generated skill is meant to pass through scripts/validate.mjs before it ships. According to the README, the script checks YAML syntax, orphan CSS selectors, undefined var(--token) usages, leftover placeholders, em-dashes, the SKILL.md frontmatter contract, WCAG contrast on core text and background pairs, and AI-default display fonts. It exits with code 1 on any error.

That list tells you what the author has seen go wrong. Undefined token references and orphan selectors are the classic failure of generated CSS. Contrast checks on text and background pairs catch the accessibility problem that a model will happily create when it picks a light grey on white. The frontmatter check is the contract that makes the folder a valid skill rather than a pile of files.

Installing hue into Claude Code or Codex

Installation is a git clone into the skills directory. For Claude Code, the README gives this command, which places the repository at ~/.claude/skills/hue:

git clone https://github.com/dominikmartn/hue ~/.claude/skills/hue

For Codex, the path differs. The README gives two options. The first targets ~/.agents/skills/hue:

git clone https://github.com/dominikmartn/hue ~/.agents/skills/hue

The alternative is described as CLI installer compatible and respects CODEX_HOME, falling back to ~/.codex:

git clone https://github.com/dominikmartn/hue "${CODEX_HOME:-$HOME/.codex}/skills/hue"

After cloning, you do not run a binary. You open a session and use a trigger phrase. The README lists three examples: "make a design skill from cursor.com", "create a design language inspired by raycast", and "generate a hue skill from this screenshot". The assistant picks up the trigger and walks through the analysis, producing a new skill folder.

Before trusting that output, run the validator against the generated folder. The README documents the invocation as node scripts/validate.mjs with the path to the generated skill folder as the argument:

node scripts/validate.mjs <path-to-generated-skill-folder>

A clean run exits zero. Any error exits 1, and you should treat that as a signal to fix the generated folder rather than ship it. If you want to see what a passing folder looks like first, run the validator against one of the directories under examples/.

What the seventeen examples in examples/ actually demonstrate

The examples directory is the most useful part of the repository for a skeptical reader, because it shows the range of output rather than a single polished case. Sixteen of the seventeen brands are fictional one-shots. Only meadow is described as real, mapped to the mymind-design skill. That ratio is worth stating plainly: this is a demonstration set, not a gallery of production deployments.

The characters vary widely. atlas is described as ivory engineering with classical maritime charts. oxide is brutalist mono compute protocol. fizz is y2k pop photo-sharing with candy chrome. ledger is newsprint editorial in the style of a financial broadsheet. relay is swiss transit with departure board precision. Reading a few of these side by side tells you whether hue can hold a strong aesthetic direction or whether it converges on the same safe output every time.

The file coverage is uneven, and the README is explicit about it. Every brand folder has a design-model.yaml and a landing-page.html. Only ridge and stint add an app-screen.html. Only halcyon ships a full component-library.html. So if you want to judge how hue handles a dense component surface, halcyon is the folder to open, and if you want to judge an application screen rather than a marketing page, ridge or stint is the one to look at. There is an examples/index.html at the top of the directory, which is presumably the entry point for browsing them in a browser.

Where hue breaks down or is the wrong tool

The dependency on a specific assistant is the first constraint. The README names Claude Code and Codex. If your team builds UI in a different editor or a different agent, the skill folder has no consumer, and you are left with a set of YAML and HTML files that nothing reads automatically.

The second constraint is what a skill can and cannot enforce. A generated skill is context. It shapes what the model produces, but the model can still deviate, and the validator only runs when someone runs it. The README describes validation as a gate that happens "before it ships", which implies a manual step in the workflow. Nothing in the repository describes a hook that blocks a bad generation automatically, and the README does not document rollback if a generated skill turns out to be wrong. You would delete the folder and regenerate.

There is also a scope limit. The output is a design language for code: tokens, components, typography, spacing, light and dark mode. If your organization needs a source of truth that designers edit in a visual tool, or a system with versioned releases that downstream teams pin to, hue does not provide that. It provides a folder that an assistant reads. Treating it as a design system of record would be a category error.

Finally, the WCAG contrast check in the validator covers, in the README's wording, "the core text/background pairs". That is a narrower guarantee than full accessibility auditing. Passing the validator does not mean every generated component meets contrast requirements.

How hue differs from pointing an assistant at a style guide

The obvious alternative is to keep a design system document in your repository and reference it from the prompt, or to paste tokens into the conversation. The difference is where the constraint lives. A pasted style guide is per-session state: it exists in the context window and disappears when the session ends, and the model can paraphrase or drop parts of it. hue moves the constraint into an installed skill folder that the assistant loads by convention, and it ships a validator that inspects the generated artifacts as files.

That distinction has a practical consequence. With a pasted guide, there is nothing to check. With hue, there is a design-model.yaml you can diff between regenerations and a script that fails on undefined tokens and orphan selectors. The trade-off is setup cost and coupling: you install a directory into a tool-specific path, and you accept that the system only functions inside the assistants the README names.

A second alternative is to write the design system by hand and skip the generation step entirely. That gives you full control and no dependence on a model's interpretation of a brand. It also means doing the token work yourself for every new brand, which is exactly the labor hue is trying to remove. If you generate design systems rarely, hand-authoring is simpler. If you do it repeatedly, the generation plus validation loop is the point.

Licence, maintenance and the cost of keeping hue current

hue is MIT licensed. The README states it directly: "MIT. fork it, remix it, build your own." For an internal tool this is about as permissive as it gets. You can modify the skill, vendor it into a private repository, or ship generated design systems without a copyleft obligation. The MIT terms do not grant trademark rights, and the README does not address attribution requirements beyond the licence text itself, so read LICENSE rather than relying on the README summary. This is not legal advice.

On maintenance, the repository is not archived. The last push was on 2026-06-11. There are no releases retrieved, so there is no versioned artifact to pin to; you are tracking the main branch. That matters for upgrade cost. Because installation is a git clone into a skills directory, updating means pulling in that directory, and any local edits you made to SKILL.md or the scripts will conflict. If you customize the skill, keep your changes in a separate branch or a fork so a pull stays clean.

The generated skills have their own lifecycle. They are folders you own, not dependencies, so they do not drift on their own. The cost is regeneration: when hue changes its output format, existing generated folders will not automatically pick up the new structure, and the validator is the tool that tells you whether an old folder still conforms to the current frontmatter contract. Running node scripts/validate.mjs across your generated folders after a pull is the cheapest way to find out.

Editorial conclusion

Adopt hue if your UI work already happens inside Claude Code or Codex and you keep re-explaining the same brand to the assistant in every session. Skip it if you need a human-editable design system, a Figma library, or anything your designers will open outside a code editor. Before you rely on it, clone the repository to the skill path for your assistant, run node scripts/validate.mjs against one of the folders in examples/ to confirm the validator executes in your Node environment, and read SKILL.md to see the frontmatter contract the generated skills must satisfy.

Frequently asked questions

Official sources

1. dominikmartn/hue on GitHub
2. Issues
3. License: MIT
4. Project website
5. README