Design System Checklist

Source: 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.