reviewing-design-system

Reviews finished design-system documents against a usability, consistency, and accessibility bar and emits an approve or revise verdict.

1|1|Updated May 24, 2026
One-click install
npx skills add https://github.com/bm629/agent-skills --skill reviewing-design-system-bm629
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reviewing-design-system
Source: https://github.com/bm629/agent-skills/tree/main/skills/reviewing-design-system
Command: npx skills add https://github.com/bm629/agent-skills --skill reviewing-design-system-bm629

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Design-system documents often look complete while being unbuildable — raw hex values in component specs, missing states, non-numeric accessibility claims. This Skill acts as an independent acceptance gate that judges a finished design-system document (or an amend delta) against a fixed, single-sourced bar, so wireframing and UI engineering only proceed on a document they can actually build from. ## Core Features & Use Cases - Thirteen-condition checklist: Judges DTCG-typed intent-named tokens, five-part component specs, API consistency, catalog coverage, numeric WCAG 2.2 AA accessibility, i18n, governance, and groundedness. - Delta-scoped amend review: Reviews versioned changes for scope-confinement, orphaned token references, semver accuracy, and deprecation safety without re-litigating untouched parts. - Machine-parseable verdict: Emits exactly VERDICT: approve or VERDICT: revise plus actionable findings (failed condition, location, fix), with proportionality rules that prevent false-revising thin systems. - Use Case: Before handing a design system to UI engineering, run this review on the document; a revise verdict returns findings the author resolves in one bounded pass. ## Quick Start Use reviewing-design-system on docs/design-system.md and give me the verdict with any blocking findings.

Frequently Asked Questions about reviewing-design-system

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a design system document before engineering builds from it?

Run this review skill on the finished markdown document. It checks thirteen conditions covering tokens, components, accessibility, and governance, then emits VERDICT: approve or VERDICT: revise with actionable findings for each blocking gap.

What makes a design system document fail a buildability review?

Common failures include raw hex or pixel values in component specs instead of semantic tokens, tokens not expressed in W3C DTCG format, components missing states or accessibility sections, non-numeric accessibility claims, and catalog coverage gaps for components real screens need.

Can this review a design system amend or versioned delta?

Yes, it supports delta-scoped review of amends. It checks scope-confinement, orphaned token references, semver bump accuracy against the change class, changelog correctness, and deprecation paths, without re-litigating untouched parts of the prior version.

Does the review require WCAG 2.2 accessibility compliance?

Yes, accessibility must be numeric against WCAG 2.2 AA: 4.5:1 text contrast, visible and not-obscured focus indicators, a 2px/3:1 focus-appearance house rule, 24x24 target size, keyboard operability, and reduced-motion support. Aspirational statements without thresholds are a gap.

When should I not use this design system review skill?

Do not use it for authoring or repairing a design system, reviewing per-screen wireframes or user flows, grading engineering design docs or ADRs, or evaluating a coded component library. It only judges the textual design-system document as an acceptance gate.