Design

One skill for the whole of a product's look: the rules, which outside skill to use when, and how to judge the result. Before it, the method lived in one file, the choice of skills in another, the screen rules in the test docs and the review in a skill of its own, and a product that read only some of them repeated mistakes the others had already written down.

What binds, in order

The owner's words. Taste, and any change to a written rule, is the owner's call. Put each visual question to them as specimens built in the product's real tokens, side by side, never described in words. references/review.md says how to sort a fix from an owner's call.
The method (references/method.md). Every kit and every screen satisfies it. A product departs from a rule only by the owner's decision, recorded in its kit README with the reason.
The product's kit, three files wherever the product keeps them (often a design/ folder): tokens.css, every raw value (colour, type, space, radius, duration); kit.css, the primitives, built from tokens only; and the kit README, the product's own design document: its direction, palette, type, layout and button roles, each with its reason, and every departure from the method. Screens compose the kit; a screen never invents a style.
The collections advise (references/collections.md). A suggestion reaches code only as a token or a primitive in the kit, recorded in the kit README. Where a collection disagrees with the method, the method wins.

A product carries this skill in its own repository, at .claude/skills/design/, copied, never pointed at. A rule that lives only in another repository doesn't get read. A monitoring product's kit README pointed at the method in another repository instead of copying it. It then shipped borderless Cancels in five places, which the method already forbade (2026-10-22).

A builder that isn't Claude Code reads these as plain files. Codex never sees a Claude Code plugin or a skill trigger. So a product's agent instructions name this folder by path, and so does every stage brief that builds screens. Whatever a collection taught that the next screen needs goes into the kit README, not just the session that used it.

Before any screen: the jobs map

Before a screen is drawn, a builder's included, work out what people come to do: one row per job, the job in the user's words → the screen it happens on → the one question that screen answers → its primary action. The map goes in the proposal's prototype and in every stage brief that adds screens. A screen with no job is cut; a job with no screen is a gap.