Dembrandt Skills

What job it is for, and why this one

Use it when a product has two or three brand colours and everything else was picked ad hoc: grey borders that came from a default, a red that does not belong to the same family as the blue, a hover state someone chose by looking at it. The answer this palette skill gives is that the missing colours should be derived rather than chosen, and it gives an explicit method for each family.

The method is concrete enough to check. Interactive states come from lightness steps applied to the base hue; neutrals are the brand hue at low saturation so greys stop looking foreign; semantic colours keep the saturation and lightness of the brand so error, warning and success carry the same visual weight. Each of those is a rule you can verify against a rendered palette, which is what separates this from advice to use a nice colour scale.

It also takes a position on two things most colour advice skips: that pure black on pure white is a comfort problem rather than a contrast win, and that disabled states should be neutral rather than a faded brand colour, so a disabled control never looks merely un-clicked. Both are opinionated, both are stated as rules, and both are worth agreeing with deliberately.

When it is the wrong tool

It is the wrong fit where colour is brand expression rather than a system: an identity refresh, a campaign, anything where the palette has to be felt before it is derived. The method optimises for coherence and accessibility, and a coherent palette is not automatically a distinctive one.

If you already have a maintained token set with hover and focus steps, this adds nothing except a second opinion, and it may rename things. Adopting a derivation method mid-project means either migrating your tokens or running two naming systems at once.

Two of the skills in this project are not self-contained: reading real design tokens off a live website needs a separate engine from the same author. If you want the pack for pure design knowledge, that is fine, because most of the skills are described as knowledge only, but do not plan around the extraction skills unless you are willing to run that engine.

What it needs, and what comes back

The minimum input is one or two brand colours with their values. The example inside the palette skill takes a single brand blue and produces a full token set: several states for each brand colour, a seven-step neutral scale derived from the brand hue, semantic colours for error, warning, success and information including their subtle backgrounds, and functional tokens for focus, selection, overlay, skeleton and shadow.

What comes back is tokens written as custom properties, plus the reasoning for the steps and a labelled review checklist. That checklist is the more useful half: it asks whether hover and active were derived rather than chosen, whether saturation falls as the greys get lighter, whether disabled states are neutral, and whether a focus token exists at all.

Prerequisites are minimal: no build step, no dependency and no service for the palette skill itself. The one thing you should bring is the colour you are deriving from, as an actual value rather than a description, and a decision about which output format your codebase uses, because the examples are written for custom properties and will need adapting to anything else.

Tool support, permissions and dependencies

The project documents its own compatibility in general terms, and its install path goes through a package runner that reads the pack. The published record labels the source check of the project as verified. The entry file read for this guide carries retrieval metadata that tells an agent when the skill applies, which is the mechanism the pack relies on rather than an explicit command.

Most of the skills are instruction text with no execution footprint, and the palette skill is one of those: it needs to read your colours and write token values. The wider permission question belongs to the extraction path, which is the part that talks to a live website and therefore to the network, and which the project documents as needing its own engine connected through the tool configuration of an agent.

One dependency detail is worth planning for: the documented requirement for the extraction skills is a minimum version of that engine, and the connection is configured at the agent level rather than inside your project. If you enable it, the boundary you are opening is your agent reaching arbitrary sites you name, so decide deliberately whether that is acceptable before wiring it up.

Compared with picking colours by eye

For a small personal project, choosing six colours carefully will be faster and may look better than a derived set, because derivation optimises for relationships and you may want a colour that deliberately breaks them. The skill is worth its overhead when the palette has to survive other people adding to it, which is exactly when the argument that it looked fine when I picked it stops working.

Against a built-in palette generator in a design tool, the difference is the reasoning rather than the output. A generator gives you a scale; this gives you a scale plus an explicit statement of what each step is for, which is what lets a second person extend the palette without guessing. If nobody else will ever touch the colours, that is a real cost with no return.

Against adopting a well-known public design system, the trade-off is inverted: you inherit decisions somebody else thought through, but not your brand. This method is the option in between, keeping your brand colour as the seed and deriving the rest.

How to check the result yourself

A derived palette can look convincing in a swatch strip and fail the moment it is used. Check it in place.

• Measure contrast on the real pairs, not the intended ones: body text on the page background, text on each semantic subtle background, the focus ring against every surface it appears over, and disabled text against its own background.
• Render the same screen in light and dark and check nothing became invisible. A palette derived from one hue often produces a subtle background that disappears in the other mode.
• Switch every control to disabled and to focus with the keyboard, and check both are still distinguishable from rest. These two states are the ones that get dropped when a palette is copied by hand.
• Check that the semantic colours are still distinguishable from each other for someone who does not separate red and green. Weight and position have to carry meaning when hue cannot.
• Look at the palette in the interface rather than in a swatch list, at the smallest and largest sizes it will be used at. A border colour that reads as a line at one pixel may read as a block at a larger radius.
• Compare the result against the review checklist the skill ships and check you can answer each line with a yes. The checklist is the standard of the project itself, and it is the cheapest way to find the steps that were skipped.

Source, version and what was actually read

The judgements above were made against the commit shown on this page. If the published record moves to a different commit, this guide stops rendering rather than describing a version nobody re-read.

What was read: the repository overview of the project, which carries the full skill list and the install and engine instructions, and one skill in full — the algorithmic colour palette skill at that commit. The other skills were seen only as one-line descriptions in the overview, so nothing above is a judgement about them. Nothing was installed, no engine was run, no website was read and no palette was generated or contrast-tested. The statements about what the method produces come from the documented output of the skill; the checks recommended above are proposed by this guide, not measurements by the project.