Prompts / design_system_audit
Design system audit chain Free
A full design system audit across foundations, tokens, components, accessibility, adoption and governance, with a scorecard and a 30-60-90 day plan.
Run it
- Claude Code:
/mcp__designers__design_system_audit - Claude Desktop and claude.ai: plus menu, Add from Designers, Design system audit chain
- Any app: Use the design_system_audit prompt from the Designers server on figma library link, repo, or description of the system.
Arguments
| Name | Meaning |
|---|---|
system * | Figma library link, repo, or description of the system |
products | The products that consume it |
* required
What your assistant is told to do
The full instructions, so you can see exactly what you are asking for:
Audit this design system for adoption and correct reuse, not completeness.
System: <system>
Consumers: <products>
Read resource designers://reference/design-system-audit-checklist and follow its six sections in order. Work as a chain; finish each step before the next, and keep a running findings list.
Step 1 inventory: If the input is a Figma link: parse it (figma.com/design/:fileKey/..., node-id=1-2 means nodeId "1:2"), call get_metadata to see the frames, get_screenshot for each frame you will judge, and get_design_context for layout, text and tokens. Read the picture before the code. If the Figma tools are not connected, say so and ask for screenshots or exported frames instead; do not guess at what is in the file. Use get_metadata to list pages, components and variants; get_variable_defs for tokens. Count components, variants and states; list the unused and the duplicated.
Step 2 tokens: run the prompt token_audit logic and call check_contrast_tokens on the token set for the full contrast matrix and lint_token_names for the names and colour-blind merge check.
Step 3 components: sample the ten most used. For each, check states, accessible name and keyboard behaviour on paper, target size, content rules, and parity with code if the repo is available. Use get_design_context on a few.
Step 4 accessibility: run check_contrast on component states (focus ring, error, disabled) and note which components lack accessible defaults.
Step 5 adoption: ask the person for two or three consuming teams and why they work around the system; if you can see a live product call detect_design_slop and audit_page_accessibility on it to compare against the system.
Step 6 governance: ask or infer ownership, contribution path, releases, deprecation.
Output: a scorecard (foundations, tokens, components, accessibility, documentation, adoption, governance, each 0 to 4 with one line of evidence), a top-ten fix list ordered by impact and effort, a 30-60-90 day plan, and a list of what you could not verify. Be specific enough that a team could start Monday.