Skills, workflows and prompts for design work

A skill is a markdown file an agent loads when a task matches it. Here is what goes in one, how to install and invoke it, and what separates a skill that changes behaviour from one that gets ignored.

Most skills read like a values statement and get ignored. The ones that work narrow the agent's choices, carry the reason behind every rule, and are tested by running them. A method, with checklists.

One file that carries your tokens as data and your taste as prose, checked into the repo next to the code. What goes in it, what stays out, how to keep it true, and the other DESIGN.md it should not be confused with.

Walks every rendered text node on a page, reads the real background from a canvas, and reports WCAG failures per theme. The full skill and its script are below, ready to copy.

A review pass that strips the tells of generated UI — indigo gradients, emoji icons, three equal cards — and puts a point of view back in. The skill and a grep for the tells are below, ready to copy.

Implement or edit UI using only the project's tokens for colour, spacing, radius and type. Reads the theme, maps every value, and stops to ask when nothing matches. Lives inside the tokens guide.

Turns a screen brief into a state inventory before anything is generated, then drives generation one state at a time and reports coverage. Lives inside the unhappy-paths guide.

Runs the five verification checks after a UI change: console probe, tells grep, screenshots at two widths and two themes, contrast sweep, motion frames. Reads the results and reports them. Lives inside the harness guide.

Runs the mechanical checks on a UI change, fixes what has one right answer, and hands the rest to a reviewer as questions with evidence. Never answers its own judgement calls. Lives inside the design QA guide.

The vocabulary: hosts, clients, servers, resources, tools and prompts, why structured context beats a screenshot, and how prompts, skills and tools are three different layers.

What the server actually does, the fixed read order, slicing big frames, why Code Connect is the lever, the design-to-code loop, and an operating model with checklists and a scorecard.

How we decide on a component or transition: three real variants behind a picker, one decision written down, the harness deleted.

A fixed order for checking interfaces a model built: foundations, then polish, then accessibility, then a headless screenshot pass.

Turns a vague 'this looks off' into a ranked table of concrete edits with the reason for each.

Replaces 'match the design' with a set of allowed moves: read the token file first, no literals, paired inks, and a report of every value that had no token.

Makes the agent list every state a screen can be in before building, wait for confirmation, then build each state as its own step with real content and a way to reach it.

Stops a model from producing three tints of the same idea by making it declare how each variant differs before it builds.