Insights
A Figma plugin counts detached instances and raw values in one file. Whether code matches, or a detach was drift, needs a code check or an audit. A Figma plugin is enough when your question is about the file: which layers use raw values instead of variables, which instances are detached, which components come from the
A Figma plugin is enough when your question is about the file: which layers use raw values instead of variables, which instances are detached, which components come from the wrong library. It is not enough when the question is whether the coded product matches the system, or why teams keep leaving it. Those answers sit in code, in the running product and with the people who make the decisions, and a plugin reads only the design file.
The short version, as a rule you can apply:
- A plugin is enough for file hygiene before a handoff, and for finding where to look.
- Add a code-side check when you need to know whether the code follows the system's tokens and components.
- It has become an audit when you need to know why the divergence exists, whether it is legitimate, and who decides what happens to it.
This page is about that line. The full method and checklist for running an audit are in how to audit a design system.
What Figma and the audit plugins check
These descriptions come from each tool's own page, checked on 16 and 17 October 2026. Plans and features change, so confirm them before you rely on one.
| Tool | What its own documentation says it checks | Scope and availability |
|---|---|---|
| Figma Check designs | Hard-coded colours, text styles, corner radius and spacing that could be variables or styles; components, variables and styles from the wrong library, including libraries not added to the file. It flags components but leaves the swap to you, and it does not use LLMs or generative AI | One page at a time, selections up to 25,000 layers; available on Figma's two top paid tiers |
| Figma agent design system audits | Detached components, style inconsistencies, token drift across files, hard-coded values and style overrides, checked against the library you connect | All paid plans; described as an open beta when checked |
| Figma library analytics | Inserts, detaches and instances of components, styles and variables, by team and file, with up to a year of history | Available on Figma's two top paid tiers |
| Design System Auditor (Community plugin) | Detached components; spacing, padding and corner radius that do not follow tokens; text without a text style; fills and strokes not attached to a style or variable; effects not from a design system style; an adherence percentage for each artboard | Treats component instances as fully adherent and does not look into their child layers |
| ComponentQA (Community plugin by BiblioKit) | Detached, overridden, duplicate, reset and unused components; hard-coded colours, spacing, type, radii and shadows; a health score from 0 to 100 weighted by severity | Runs on a selection, a page or all pages; monitoring files over time and some audit categories need its paid plan |
Every row reads the design file. None of these pages describes opening the code repository or the running product, which is the first limit worth knowing before you choose one.
What a tool can see, and what needs a person
A plugin counts what is visible in one representation. The judgement about what the count means sits elsewhere.
| A tool can count | A person has to establish |
|---|---|
| Detached instances | Whether the detach was a legitimate product variation, a workaround for a missing state, or drift |
| Raw values where a variable exists | Whether the raw value carries a meaning the token set lacks, or is simply a mistake |
| Components from a library the file is not subscribed to | Why the team reached for that library, and who owns the fix |
| Components that are never used | Whether a component is unused because it is wrong, redundant or simply new |
| Overrides on an instance | Whether the override changes meaning (a status colour) or only content (a label) |
| An adherence or health percentage | Which divergence costs the product most |
| Nothing, from the design file alone | Whether the coded component matches the Figma one, state by state |
| Nothing, from the design file alone | Whether a status or permission means the same thing in every product that shows it |
The detach is the clearest case. Figma's documentation on detaching an instance says it turns the instance into a regular frame, removes the link to the main component, and stops applying the component's changes to it. So a detach count tells you which screens have left the system. It does not record why. A team that detached a shared table because it has no permission state has found a gap in the system; a designer who detached it to try an idea has made a hygiene problem. Both add one to the same count, and only a conversation with the team tells them apart.
Where the numbers mislead
Counts are useful for choosing where to look. They become misleading when they are read as a verdict, and the tools' own documentation shows where.
- An instance can score as fully adherent. Design System Auditor states that it treats component instances as fully adherent and does not look into their child layers. By that description, a hand-set colour inside an instance would not lower the score.
- Some work is invisible to analytics. Figma library analytics do not track component usage in other people's draft files, do not count nested components as insertions, and only hold style and variable data from 10 October 2024. Exploration in a colleague's drafts does not reach the numbers.
- A built-in check sees one page at a time. Check designs runs on a single page and limits a selection to 25,000 layers, so a file-wide picture means running it page by page.
- A score ranks by volume. A weighted health score summarises how many issues there are and how severe the tool rates them. It cannot know that one missing state in a billing workflow matters more to your product than forty unlinked text styles on a marketing mock-up.
None of this makes the tools wrong. It means a plugin report is a list of places to look, not a finding.
What a code-side check adds
Several of the search questions about auditing a design system ask something else: whether production matches the system. A design-file plugin does not reach production. These checks do, each in a limited way.
- Raw values in stylesheets. Stylelint's `color-no-hex` rule disallows hex colours, and `declaration-property-value-disallowed-list` lets a team ban specific property and value pairs. Together they catch the code equivalent of a hard-coded fill.
- Where shared components are used, and with which props. The open-source react-scanner statically analyses code and extracts React components and their props into a JSON report. By default, when a prop value is an expression or a variable, the report shows its syntax type rather than its value, so it tells you how a component is called more than what it ends up showing.
- Whether the rendered interface changed. Playwright's visual comparisons compare each run against a reference screenshot that an earlier run created and the team committed. That catches an unintended change against the last accepted rendering of the code. It does not compare the code with the Figma component, and the documentation warns that rendering varies with operating system, browser and hardware.
- Accessibility in the running product. In 2017, when the UK Government Digital Service tested ten automated tools against a page with 143 deliberate barriers, 42 were missed by every tool, and the best single tool found 37%, counting only errors and warnings. The W3C's current guidance on selecting evaluation tools (updated 13 May 2024) makes the same point directly: "Tools cannot check all accessibility aspects automatically. Human judgement is required."
A code-side check answers whether the code follows its own rules. Whether those rules match the design, and which of the two should govern, is still a decision someone has to make.
Plugin, code check or audit: a decision rule
Match the tool to the question you are actually asking.
| The question you are asking | What is enough | Why |
|---|---|---|
| Is this file clean before handoff? | A plugin or Check designs | The answer lives entirely in the design file |
| Where should we start looking? | A plugin, plus library analytics if your plan has them | Detach and insert counts point at the component families worth a closer look |
| Does our code use the tokens and shared components? | Add a code-side check: lint rules and a usage scan | The answer lives in the repository, which a design plugin does not open |
| Did this release break what already shipped? | Visual comparisons and automated accessibility tests, plus manual keyboard and screen reader testing | Automated checks catch regressions against a baseline; people catch what tools miss |
| Why do teams keep detaching or copying this component? | An audit | The cause sits in request history, product needs and the people involved |
| Does this status mean the same thing in all three products? | An audit | Meaning is a product decision, not a property of a layer |
| Who decides whether this variation stays? | An audit | Ownership is an organisational fact; no file records it |
Three signs that a plugin question has turned into an audit question: the same component family shows up detached or copied in more than one product; designers and engineers disagree about which source is right; and the same fix has been made twice in different places. At that point another count will not settle it, because the disagreement is about cause and authority, not about how many issues there are.
How Tcules uses tools in an audit
We use tooling to find candidates, not to reach conclusions. In our Design System Audit, AI helps us compare naming, token usage, component properties and repeated code patterns across large sources, and it produces likely divergence candidates faster than a manual inventory alone. The meaning of the system still needs a practitioner: two similarly named components may carry different product authority, and two visually different ones may correctly implement the same contract. We review AI-assisted findings against product behaviour, source context and consequence before they enter the audit record.
Each finding records the system asset, the consuming product, the design and code evidence, the divergence, its consequence, how often it recurs, its likely cause and its owner, and ends in a disposition, from aligning design and code to deliberately keeping a decision product-specific. We do not reduce the system's health to one score. We start from the system, two product areas that consume it and one repeated cost.
If you want to test the line yourself first, our Design System Drift Checker walks one component family through four traces: whether design agrees with itself, whether code matches design, whether the running product matches code, and whether the system can absorb what you found. When the gap is mainly between Figma and Storybook, we compare which tools help when Figma and Storybook drift apart. When the question is where a defined product decision is lost on its way to production rather than how the system is adopted, our Design-to-Code Audit is the narrower fit. And if you want to place your system on a broader scale before choosing any of these, start with our design system maturity model.
Reviewed by Chirag Patel, our Senior Designer.