---
name: design-system-checklist
description: Reference checklist (230 items across design language, foundations, components, and maintenance) for planning, building, auditing, or documenting a design system. Use this whenever the user is starting a design system from scratch, reviewing/auditing an existing one for gaps, writing a component spec (button, modal, select, etc.) and wants to make sure they haven't missed states like disabled/error/a11y, deciding what design tokens or foundations to define (color, spacing, typography, elevation, motion, iconography), or planning design-system team processes (documentation, contribution guidelines, local library rules, roadmaps). Trigger even if the user just says things like "what should my button component support", "am I missing anything in my color system", "help me document our design system", or "build a design system checklist/audit for us" — don't wait for the exact phrase "design system checklist."
---

# Design System Checklist

Source: [designsystemchecklist.com](https://www.designsystemchecklist.com/) (open-source project by Arda Karacizmeli, Dmitry Belyaev, and Steven Baguley). This skill packages the full checklist content (all 4 categories, 42 sections, 230 items, plus curated reference links to how Atlassian, Material, Reshaped, Polaris, Chakra, MUI, and other well-known systems handle each item) so it can be applied without re-fetching the site.

This is not a definitive or mandatory list for every design system — treat it as a set of prompts to check against, not a rigid spec. Skip items that don't apply to the user's product or platform.

## The four categories

| Category | File | Sections | Items | Covers |
|---|---|---|---|---|
| Design language | `references/design-language.md` | 2 | 10 | Brand (vision, principles, tone, terminology, assets) and cross-product guidelines (accessibility, writing, microcopy, terminology, i18n) |
| Foundations | `references/foundations.md` | 6 | 26 | Design tokens: color, layout, typography, elevation, motion, iconography |
| Components | `references/components.md` | 29 | 166 | Per-component checklists for 29 common UI components (button, modal, select, toast, tabs, etc.) — states, variants, sizes, composition, and accessibility for each |
| Maintenance | `references/maintenance.md` | 5 | 28 | Running the design system as an ongoing product: documentation, local/team libraries, team processes, community support, contribution |

Each reference file has: a short category description, a table of contents linking to its sections, and per-section checklist items formatted as `- [ ] **Title** — description`, followed by links to how real design systems implement that section.

## How to use this

**Load only the reference file(s) relevant to the task** — don't load all four unless doing a full audit. Skim the table of contents at the top of `components.md` before loading the whole file, since it's the largest (166 items); jump to just the component(s) the user needs.

### Planning a new design system from scratch
Read all four files in order (design-language → foundations → components → maintenance). Use them to scope out a roadmap or a phased plan — most teams build foundations and a handful of core components (button, text field, select, modal) before tackling the long tail of components and maintenance processes.

### Auditing / reviewing an existing design system
Ask the user what they want audited (whole system vs. a specific area), then check what they already have against the relevant checklist items. Present gaps as a prioritized list rather than dumping the raw checklist — group by category, and call out anything accessibility-related as higher priority since it's usually load-bearing for compliance.

### Writing or reviewing a single component's spec
Load only the relevant section of `components.md`. If the exact component isn't listed (e.g. "date range picker"), use the closest analog (e.g. Calendar) plus general patterns from other similar components (e.g. Select's error/disabled/label items) and say so explicitly rather than inventing items with false confidence.

### Defining foundations / design tokens
Load `foundations.md`. Pay attention to the accessibility-flagged items (color contrast, reduced motion, icon accessible names) — these are the ones most often skipped.

### Setting up team process / documentation / contribution model
Load `maintenance.md`. This is the category least tied to visual design and most relevant to design-system program/ops questions.

### Generating a document or spreadsheet for the user
If asked to turn this into a deliverable (Word doc, checklist spreadsheet, tracker), use the docx/xlsx skills as normal, but populate the content from these reference files rather than regenerating checklist items from memory — the descriptions and resource links here are the actual source content and shouldn't be paraphrased-then-reinvented.

## Attribution
When presenting this content, it's fine to mention it's based on the open-source Design System Checklist project. Don't claim the curated example links (Atlassian, Material, Reshaped, etc.) as your own research — they're sourced from the project's resource lists.