# Design Md

> Create or update a repo's DESIGN.md — a living design-language contract for AI agents and humans — plus a portable frontend-design skill. Classifies the repo first (document an existing design language, merge with existing design docs, or propose a new direction with user approval) so it never overwrites a project's current design. Use when setting up design docs for a frontend project. Triggers on "add a DESIGN.md", "document our design language", "set up design docs", "create a design system doc", "bootstrap design".

- Skill: `nolly-studio/design-md` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add nolly-studio/design-md`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nolly-studio/design-md/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Design & Media
- License: MIT
- Author: nolly-studio (https://skillmd.com/u/nolly-studio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nolly-studio/design-md

---


# Design Language Doc (DESIGN.md)

You are creating this repository's design-language contract: a root `DESIGN.md` that tells agents and humans exactly how UI is built here, plus a portable `frontend-design` craft skill. The doc is **downstream of the code** — you describe the design language that exists, or propose one with user approval. You never invent a design language and present it as fact, and you never restyle existing UI to match a doc.

## Goal

1. Root `DESIGN.md` — the repo's design language, written from evidence, citing real files and tokens
2. `.agents/skills/frontend-design/SKILL.md` — portable craft doctrine (typography, surfaces, motion) that applies to any repo
3. A link from `AGENTS.md` so agents find the design language within one hop

## Reference templates

| File | Used for |
| --- | --- |
| `references/design-md-template.md` | `DESIGN.md` skeleton, filled from evidence |
| `references/skill-frontend-design.md` | `.agents/skills/frontend-design/SKILL.md` (create verbatim) |

## Phase 0: Audit, then classify (before writing anything)

**Config first.** If `docs/agents/skills-config.md` exists, read it before anything else — it may already record the classification mode and, for Mode C, a settled aesthetic direction from the `setup` interview. Never re-ask a decision recorded there. If the file does not exist (this skill was invoked directly), classify and settle decisions yourself as described below.

Gather evidence. Every claim in `DESIGN.md` must trace back to something you saw here:

- [ ] `package.json`: framework, UI libraries (react/vue/svelte, tailwind, shadcn, radix/base-ui, motion/framer-motion, lucide, fonts packages)
- [ ] Token layer: `globals.css` / `tailwind.config.*` / theme files — CSS variables, `@theme` blocks, custom utilities (shadows, radii, animations)
- [ ] Fonts: how they're loaded (`next/font`, `@font-face`, link tags), which families, which roles
- [ ] Component system: `components/ui/`, shared primitives, variant patterns (cva, variants props)
- [ ] Motion: keyframes, transition utilities, motion-library usage, `prefers-reduced-motion` handling
- [ ] The 3–5 most polished surfaces in the app — these define the _actual_ design language, whatever the tokens claim
- [ ] Existing design docs: `DESIGN.md`, `docs/design*`, brand guidelines, Figma links in READMEs, design-related Cursor rules or agent docs

Then classify the repo into exactly one mode:

### Mode A — Document (established design language, no design doc)

The repo has consistent tokens, deliberate font choices, a component system, recurring motifs. Your job is **extraction**: write `DESIGN.md` describing what exists, citing the files that prove it. Nothing about the actual design changes. Where the codebase is internally inconsistent, document the dominant/most-recent pattern and note the deviation — do not resolve it by fiat.

### Mode B — Merge (design docs already exist)

A `DESIGN.md`, brand guide, or design-related rules already exist. **Merge, never regenerate**: preserve every unique local rule, deduplicate against the template structure, keep one source of truth, and leave pointers behind if you consolidate scattered docs. If existing docs contradict the code, flag the contradiction to the user instead of silently picking a side.

### Mode C — Propose (greenfield, no coherent design language)

No established language exists. Choosing an aesthetic direction is a **user-owned decision**, not an evidence question. Run the decisions through the `frontier-interview` skill: aesthetic direction and tone is the root decision; font pairing (display + body), color approach and the accent budget, elevation strategy, and motion approach are downstream of it. Offer 2–3 distinct directions as the recommended answers where the product context supports them. Then write a one-page proposal to `docs/plans/design-language.md` (or `PLAN.md` if the repo has no `docs/plans/`) from the settled answers. **Stop and get user approval of the proposal before writing `DESIGN.md`.** After approval, write the full doc from the approved proposal.

## Deliverables

```
DESIGN.md                              # root design-language contract (living document)
.agents/
  skills/
    frontend-design/SKILL.md           # portable craft doctrine (references/skill-frontend-design.md)
docs/
  plans/
    design-language.md                 # Mode C only: the approved proposal
```

Plus one edit: add `- [Design Language](DESIGN.md)` to the Quick Links in `AGENTS.md` (create the section if the repo has an `AGENTS.md` without it; skip if there is no `AGENTS.md`).

## Process (in order)

1. **Phase 0** audit and classification (checklist above)
2. Mode C only: interview (per the `frontier-interview` skill), write the proposal, present it, and **wait for approval**
3. Write `DESIGN.md` using `references/design-md-template.md` as structure — filled from evidence (Modes A/B) or the approved proposal (Mode C)
4. Create `.agents/skills/frontend-design/SKILL.md` verbatim from `references/skill-frontend-design.md` (stripping the template preamble), unless the repo already has an equivalent craft skill — then skip it
5. Link `DESIGN.md` from `AGENTS.md` Quick Links
6. Run the **verification pass** below
7. Report: mode chosen and why, files created, contradictions found between docs and code, rules preserved from pre-existing docs

## Writing rules for DESIGN.md

- **Cite real files.** Every token, utility, font, and component pattern named in the doc must link to the file that defines it
- **Name the budgets.** Great design languages are mostly restraint — make limits explicit ("one accent pairing per view", "at most one display-font moment per page"), because agents follow budgets better than vibes
- **Include the one-liner.** A blockquote near the top that compresses the whole language into one paragraph an agent can carry to another surface
- **End with a per-page checklist** of verifiable items, phrased so an agent can self-review against them
- **Sizes over adjectives.** "`rounded-3xl` cards, `rounded-full` CTAs" beats "generously rounded"
- Semantic tokens over hardcoded values everywhere the repo's token system reaches; name the sanctioned exceptions explicitly

## Constraints

- **Never restyle existing components to match `DESIGN.md`.** The doc describes or proposes; it does not authorize a refactor. If the user wants the UI brought in line with the doc, that is a separate, explicit task
- In Modes A and B, do not "improve" the design language while documenting it — record improvement ideas at the end under a clearly-marked "Open questions" section instead
- Do not copy another product's design language (fonts, palettes, motifs) into `DESIGN.md` unless verified in THIS repo or approved in the Mode C proposal
- Prefer an accurate short doc over an impressive long one — an agent that trusts a wrong design doc produces confidently wrong UI
- Match the repo's markdown tone and formatting

## Re-runs, stamps, and owned files

- **Stamp every emitted artifact.** The first line of every file this skill creates (`DESIGN.md`, the proposal doc, the emitted frontend-design skill) is `<!-- generated by design-md v<version> -->` (version from this skill's frontmatter). In emitted SKILL.md files, place the stamp immediately after the frontmatter.
- **Ownership by stamp.** On re-run, a file carrying this skill's stamp may be updated — but rules the user added or edited since are preserved, never regenerated away. A file without this skill's stamp is not yours (a hand-written `DESIGN.md` is Mode B by definition): merge into it in place; never overwrite it and never create a duplicate beside it.
- **The `AGENTS.md` edit is idempotent.** The Quick Links line is a single-line insertion into a file this skill doesn't own: check for presence, add if absent, touch nothing else.

## Verification pass (required before finishing)

- [ ] Every file path referenced in `DESIGN.md` resolves to an existing file
- [ ] Every token, utility class, and font named in the doc exists in the codebase (grep for it)
- [ ] Modes A/B: no rule in the doc contradicts what the most polished surfaces actually do
- [ ] Mode B: every unique rule from the pre-existing docs survived the merge (diff them)
- [ ] Mode C: the doc matches the approved proposal; the proposal file exists in `docs/plans/`
- [ ] The `AGENTS.md` link resolves
- [ ] The checklist at the end of `DESIGN.md` contains only items an agent can verify from code
- [ ] Every emitted file carries this skill's generation stamp; no file without the stamp was overwritten

## Done when

- An agent building UI in this repo can answer "what fonts, what tokens, what radii, what shadows, what motion?" from `DESIGN.md` alone, one hop from `AGENTS.md`
- The user's existing design decisions are intact — nothing was overwritten, and any new direction was explicitly approved
- The portable `frontend-design` craft skill is installed
- Every doc statement is evidence-backed (or approval-backed) and the verification pass is clean