AI Guides › Step-by-step guides
By Nigel Guy · 8 min read
You ask Claude to make a page look premium, modern or clean, and you get something competent and generic. So you ask again with more adjectives, and get a different generic page. The mistake is treating taste as something you can describe in a sentence. Adjectives leave every real decision open, so Claude fills each gap with the most average choice available.
The rule: replace adjectives with values. A design rules file lists the exact colours, type sizes, spacing steps and component patterns, plus a short list of things never to do, and Claude reads it before it builds anything.
You need:
One honest caveat: nobody can promise that a longer brief always beats a short one. What you are doing is removing guesses, which is a sound reason on its own. Treat the file as something to test against your own pages, not a guarantee.
You are not inventing a design system from nothing. Collect what exists.
Aim for the smallest set that still decides things: one background, one text colour, one accent, one muted tone; two fonts at most; a spacing scale of five or six steps; a corner radius; and what a button, card and form field look like.
There is an open format for this, so you do not have to invent a structure. Google Labs publishes a DESIGN.md specification on GitHub (google-labs-code/design.md). It pairs machine-readable tokens in YAML front matter (colors, typography, rounded, spacing, components) with plain-English sections in a set order: Overview, Colors, Typography, Layout, Elevation & Depth, Shapes, Components, Do's and Don'ts. At time of writing the spec is marked alpha, so expect it to change.
A minimal version:
---
name: Studio Brand
colors:
background: "#FAF8F5"
text: "#1A1C1E"
accent: "#B4492F"
typography:
body: { fontFamily: "Inter", fontSize: 16px, lineHeight: 1.6 }
spacing:
sm: 8px
md: 16px
lg: 32px
rounded:
card: 12px
---
## Overview
Calm, editorial, lots of white space. Trustworthy rather than flashy.
## Do's and Don'ts
- Do use the accent colour once per screen, for the main action only.
- Don't use more than two font weights.
- Don't add gradients, shadows or emoji.
The Do's and Don'ts section does most of the work. "Don't" lines stop Claude drifting back to its defaults. Make each rule checkable: "one accent colour per screen" can be verified, "keep it elegant" cannot.
Pick one of three homes.
| Home | How | Best for |
|---|---|---|
| Project file | Save as DESIGN.md in the project root and mention it in CLAUDE.md ("Follow DESIGN.md for all UI work"). Per the Claude Code docs, project instructions live in ./CLAUDE.md or ./.claude/CLAUDE.md. |
One site, one repository |
| Claude Code skill | Create ~/.claude/skills/<your-skill-name>/SKILL.md (personal, all projects) or .claude/skills/<your-skill-name>/SKILL.md (this repository only). Add name and description in the front matter, then the rules below it. |
Reusing one brand across projects |
| Claude app skill | Zip a folder named after the skill, with the skill file at its root, then go to Customize > Skills, click "+", choose "+ Create skill", then "Upload a skill". | Using the rules in chat without code |
For a skill, the description tells Claude when to use it, so make it specific: "Brand colours, type and spacing rules for building or redesigning any web page for Studio Brand." Claude Code's docs recommend keeping SKILL.md under 500 lines and putting detail in supporting files. The help centre limits are 64 characters for the name and 200 for the description in the app route, and the zip must contain the skill folder as its root, not loose files.
A discrepancy to know about: the Claude Code docs call the file SKILL.md, while the help-centre article on custom skills writes skill.md. I could not confirm whether the app is case-sensitive, so use SKILL.md in Claude Code and check the app's upload message if it rejects your zip.
If you used a skill, you can call it by name in Claude Code (/your-skill-name) or let Claude pick it up from the description.
This prompt turns the file into the working brief. Fill in the placeholders.
You are a front-end designer working strictly within an existing design system.
Context: I am rebuilding [PAGE_OR_SITE]. It currently does [WHAT_IT_DOES_NOW]. It is for [AUDIENCE]. The design system is in [FILE_OR_SKILL_NAME].
Goal: a result that someone who knows the design system would accept as on-brand without edits.
Steps:
1. Read the design system first. List the colours, type styles, spacing steps and components you will use, so I can see you loaded it.
2. Build the page, using only those values. Do not substitute generic styling.
3. Where the system is silent (for example a pricing table or a form), reuse its spacing and type-weight rules and keep to its Do's and Don'ts. Do not invent a new pattern without flagging it.
4. Finish with two lists: "Followed exactly" and "Improvised", naming each improvised element and which rule I could add to cover it.
Constraints: no new colours, fonts or shadows. If any input above is missing or the file is unclear, ask me before building rather than guessing.
Self-check before you answer: scan your output for any colour, font size or spacing value that is not in the system, and fix it or list it under "Improvised".
Fill in: the page, what it does now, the audience, and the file or skill name.
If you have no system yet, use this to draft one:
You are a senior brand designer. I need a one-page design rules file for [BRAND_OR_SITE], aimed at [AUDIENCE], with the feel of [TWO_OR_THREE_REFERENCE_SITES].
Produce, in this order: colour tokens (background, text, accent, muted) with hex values and when each is used; two fonts and a type scale; a five-step spacing scale; corner radius; button, card and form-field rules; then eight Do's and Don'ts that can each be checked by looking at a page.
Constraints: no more than one accent colour; text must meet WCAG AA contrast (4.5:1 for body text). Ask me for any missing brand facts instead of making them up. Before answering, check each colour pair for contrast and say which you checked.
Fill in: brand, audience, and your reference sites.
npx @google/design.md lint DESIGN.md. It flags broken token references and contrast below WCAG AA, among other checks. Run npx only on packages you trust./context and confirm your memory file is loaded.