---
name: reviewing-ui-for-drift
description: Reviews a pull request or diff for design system drift and reports findings with file and line, covering invented components, literal values, duplicated functionality, deprecated APIs and unmet accessibility requirements. Use when reviewing a PR that touches UI, when asked to review code as a design system maintainer, before merging generated UI, or when the user mentions design review, code review, drift, or system compliance. Applies to review of any diff containing components or styles, especially agent-authored ones.
license: CC0-1.0
---

# Reviewing UI for drift

Drift is rarely one bad decision. It is thirty reasonable-looking ones, each
of which passed review because the reviewer was reading for correctness rather
than for membership in the system.

Read for membership. The code can be entirely correct and still be drift.

## What to read for, in order

### 1. Does this component already exist?

The highest-value question and the one no shipped tool answers. For every new
component in the diff, search the library for something that does the same
job. A new `DisabledButton` is almost always `Button` with a prop. A new
`InfoCard` is usually `Card`.

If it is 80% an existing component, say which one and what the 20% is. That
difference is either a missing prop on the existing component — the right fix
— or a genuine new case.

### 2. Is anything invented?

Cross-check every rendered component against the export list. `Box`, `Stack`,
`Container` and `Flex` are the usual imports from libraries this project does
not use.

### 3. Are values tokens?

Any literal colour, spacing, radius or type size is a finding, with one
exception: token definition files themselves.

### 4. Are prop types closed?

A new prop typed `string` where a union belongs is the seed of the next
drift. It will not fail today. It will produce four invented values within a
month, because each one that survives becomes a sample the next generation
copies.

### 5. Does the accessible name say what the thing does?

Not whether an accessible name exists — whether it means anything. See the
semantic accessibility skill.

### 6. Is the documentation still true?

If the diff renames or removes an export, does the agent-facing documentation
still name the old one? Stale docs are an active hallucination source: the
model reads the README, uses the name, and produces a build failure that
traces back to your own docs.

## How to report

One finding per row. File and line. The expected value, not just the
violation. Most severe first. If the diff is clean, one line saying so.

Do not soften findings into questions. "Consider using a token here" reads as
optional; "literal `#2563EB`, expected `var(--color-action-primary)`" does
not.

## What is not drift

Be willing to pass things. These are not findings:

- A one-off layout in a genuinely one-off surface, using system tokens.
- A composition that looks unusual but uses only system parts.
- Deviation that the author has flagged and justified in the description.

A review that flags everything is as useless as one that flags nothing,
because the team learns to ignore it.