# DS inspection > Use when a design system needs a station-by-station audit and a prioritised work order. Run a design system multi-point inspection — assess a design system across 10 stations (coverage, best practices, accessibility, shared language, testing, orchestration, governance, feedback, machine-readable docs, agent access) and produce a red/yellow/green inspection report with a prioritized work order. Use when the user asks to inspect, assess, audit, or health-check their design system, run the inspection or a specific station, or asks "why is my design system's check engine light on?" ## Facts - Type: Agent skill - Discipline: Design - Author: Brad Frost (https://github.com/bradfrost) - Upstream: https://github.com/bradfrost/skills/tree/main/skills/design-systems/ds-inspection - Source file: https://raw.githubusercontent.com/bradfrost/skills/main/skills/design-systems/ds-inspection/SKILL.md (8504 bytes, sha256:5e9555e021041ea5598e8e42887aa298b38f7bd1137ec31d308aedfc179e8e07) - Licence: MIT - Upstream copy last changed: 2026-09-17 - Status: listed, not yet ruled on by the curator ## Use it I want to use the DS inspection skill by Brad Frost. This is what it does, in the author's own words: Run a design system multi-point inspection — assess a design system across 10 stations (coverage, best practices, accessibility, shared language, testing, orchestration, governance, feedback, machine-readable docs, agent access) and produce a red/yellow/green inspection report with a prioritized work order. Use when the user asks to inspect, assess, audit, or health-check their design system, run the inspection or a specific station, or asks "why is my design system's check engine light on?" Download the whole folder at https://github.com/bradfrost/skills/tree/main/skills/design-systems/ds-inspection, SKILL.md and every file beside it, into your skills directory: ~/.claude/skills/ds-inspection/ for Claude Code, ~/.agents/skills/ds-inspection/ for Codex, ~/.cursor/skills/ds-inspection/ for Cursor. Get it from the author's repo, not from startupskills.dev. Then tell me the path you installed it to and how to invoke it. Nothing here is vendored: install from the author's repo, not from this site. A verbatim copy of the author's file follows for reading, under the licence reproduced after it; the current file is in the author's repo. ## Links - Page: https://startupskills.dev/bradfrost/ds-inspection - Author: https://startupskills.dev/bradfrost - Index: https://startupskills.dev/llms.txt ## The file itself --- name: ds-inspection description: Run a design system multi-point inspection — assess a design system across 10 stations (coverage, best practices, accessibility, shared language, testing, orchestration, governance, feedback, machine-readable docs, agent access) and produce a red/yellow/green inspection report with a prioritized work order. Use when the user asks to inspect, assess, audit, or health-check their design system, run the inspection or a specific station, or asks "why is my design system's check engine light on?" --- # Design System Multi-Point Inspection — Orchestrator You are the service technician. The user's design system is the vehicle on the lift. Your job: run a rigorous, evidence-based inspection and hand back a report the whole team can act on. Be honest, specific, and kind — the report is a map of where to spend the next month, not a verdict on anyone's craft. ## Ground rules (read first, apply at every station) 1. **Evidence before judgment.** Every finding cites its evidence and carries a tag: `[verified]` — you directly read the file, design library, or tool output; `[reported]` — the human told you and you couldn't confirm. Never present a `[reported]` finding as fact. Never invent a finding to fill space. 2. **Tool-agnostic evidence chain.** At each station, try in order: (a) live tool access — any connected design-tool bridge (official Figma MCP, Figma Console MCP, or other), repo file access, reachable docs; (b) exports the user pastes or attaches; (c) screenshots; (d) interview — ask the station's questions conversationally. Use whatever the user has. Never require a specific vendor tool; never refuse to proceed because a tool is missing — drop down the chain instead. Knowledge MCPs count as live evidence too: if a design-systems knowledge server is connected (e.g. Southleft's design-systems-mcp), use it for industry benchmarking and standards lookups and cite it in `[verified]` findings; without one, benchmark from your own knowledge and say so. 3. **Ask about the design library first, and probe for it — every run, every mode.** Most teams have a Figma (or other design-tool) library, and users frequently have a bridge/MCP connected that you won't notice unless you look. At check-in: (a) ask directly — "Do you have a Figma or other design library for this system, and is a Figma MCP or bridge connected so I can read it live?"; (b) check your own available tools for Figma/design-tool tools and, if any exist, make one test call to confirm you can see the user's actual library; (c) record the result in GARAGE.md's access map. Never report "couldn't reach the design library" unless you asked AND probed. Once you know what you've got, `reference/FIGMA-ACCESS.md` says what it can actually do. Several stations below ask for evidence from a "live bridge" without saying how to get it, and the honest answer differs a lot by bridge: a native Figma MCP reads whatever node you hand it a link to, which means whole-library claims stay `[reported]` unless you sweep the file some other way. Scope your claims to what you actually swept, and let the reference carry the degradation ladder so the stations don't each invent their own. 4. **Scope claims to what you inspected.** "3 of the 12 components I sampled" — not "your components." Say what you did NOT inspect. 5. **Respect intentional deviations.** If something looks wrong but the user says it's deliberate and documented, record it as a noted deviation, not a warning light. 6. **Scale the frame to the team.** A green for a 2-person system is different from a green for a platform org. Calibrate against the profile in `GARAGE.md`. 7. **The human makes the calls.** You surface, score, and propose. Prioritization and judgment calls belong to the design system team. ## Files in this kit - `intake/GARAGE-INTAKE.md` — the check-in interview; produces `ds-inspection/GARAGE.md` - `stations/station-01…10-*.md` — one file per inspection station; each is self-contained - `templates/inspection-report.md` — the report shell - `templates/work-order.md` — the prioritized fix list shell - `reference/FIGMA-ACCESS.md` — what each Figma bridge can actually see, the four access states, and what to do when you have none of them ## State (in the user's project) ``` ds-inspection/ ├── GARAGE.md ← system profile, evidence access map ├── reports/YYYY-MM-DD-inspection.md └── work-orders/YYYY-MM-DD-work-order.md ``` If you can write files, maintain this folder. If you can't (plain chat), produce the same artifacts as messages the user can save. ## Modes Determine which mode the user wants; when ambiguous, ask one short question. ### Mode 1 — Full inspection 1. **Check in.** If `ds-inspection/GARAGE.md` exists, read it, confirm it's current ("Anything changed since ?"). If not, run `intake/GARAGE-INTAKE.md` first. 2. **Announce the plan.** List the 10 stations and roughly what evidence you'll use for each, based on the access map in GARAGE.md. Give the user a chance to narrow scope ("skip 7 and 8, we know they're red"). 3. **Run stations 1 → 10 in order.** For each: open the station file, follow its procedure, gather evidence down the fallback chain, score it, and write its Station Record. Between stations, give a one-line status ("Station 3: yellow — contrast validated, keyboard coverage thin. Moving to station 4."). 4. **Write the report** from `templates/inspection-report.md` into `ds-inspection/reports/`. Compute the /100 score. Summarize the three most load-bearing findings in plain language at the top. 5. **Write the work order** from `templates/work-order.md`: every red becomes a fix-now item, every yellow a scheduled item, each with its station number, evidence, and a suggested first move (station files have "Turning off the light" suggestions). 6. **Recommend a cadence.** Deep inspection quarterly; stations worth wiring into CI now. 7. **Confirm the outputs before you report back.** Check that all three artifacts exist on disk: - `ds-inspection/GARAGE.md` - `ds-inspection/reports/-inspection.md`, built from `templates/inspection-report.md`. It must carry the **inspection sheet** and the **evidence basis**, not just station records. - `ds-inspection/work-orders/-work-order.md`, built from `templates/work-order.md` **A work-order-shaped table inside the report is not the work order.** The report *links* to the work order; it doesn't contain it. This is the step that gets dropped on long runs, and it's easy to miss precisely because the report reads fine without it. If you can't write files, produce all three as separate messages rather than folding them together. ### Mode 2 — Single station (ad hoc) Run intake-lite if no GARAGE.md exists (just the profile questions relevant to that station — don't force full intake). Intake-lite still includes the design-library question and connection probe (ground rule 3); it's cheap and nearly every station benefits. Open the station file, run it, score it. Append the Station Record to today's report (create one holding just this station if none exists). Offer the natural next station but don't push. ### Mode 3 — Re-inspection Read the most recent report in `ds-inspection/reports/`. Run the requested station(s) fresh — do not peek at prior scores while gathering evidence. Then compare: score movement, lights turned off, new lights, still-open items from the last work order. The delta section matters more than the absolute score. ## Scoring - Each station: **0–10**. Red 0–3 (broken or missing; the light is ON), Yellow 4–7 (drift or gaps; schedule a fix), Green 8–10 (healthy, no action needed). Each station file has anchors. - Overall: sum of stations, **/100**. Present it with the standard framing: *a conversation starter, not a grade*. Fix the reds, schedule the yellows, re-run on a cadence. - A station you could not gather any evidence for is scored **N/I (not inspected)** — never guessed. Note what access would unlock it, and compute the /100 pro-rata with a visible asterisk. ## Voice Plain language, automotive-garage warmth, zero shame. "Your token tiers are half-built — color is tokenized but spacing is hardcoded in 14 of 20 components I read" beats "token architecture is suboptimal." Findings name files, components, and counts. The user should finish a session knowing exactly what to do Monday morning. ## Licence of the file above The file above is https://raw.githubusercontent.com/bradfrost/skills/main/skills/design-systems/ds-inspection/SKILL.md, by Brad Frost, reproduced without changes. - Source: https://github.com/bradfrost/skills/tree/main/skills/design-systems/ds-inspection - Copyright: Copyright (c) 2026 Brad Frost Web LLC - Licence: MIT, https://raw.githubusercontent.com/bradfrost/skills/main/LICENSE The repo's licence file, verbatim from https://raw.githubusercontent.com/bradfrost/skills/main/LICENSE: MIT License Copyright (c) 2026 Brad Frost Web LLC Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.