What counts as UI

The gate is a fixed list of file globs, the same in every repository. There is nothing to configure, because a per-repository include list would be design knowledge held on our side, and the only place design knowledge belongs is your repository.

The file globs

A changed file counts as UI when its path matches one of:

**/*.tsx  **/*.jsx  **/*.vue  **/*.svelte  **/*.astro
**/*.html  **/*.css  **/*.scss  **/*.sass  **/*.less  **/*.mdx
**/*.styles.{ts,js}  **/*.styled.{ts,js}
tailwind.config.{js,cjs,mjs,ts}

Tests and test material do not count either: a *.test.* or *.spec.* file, or anything under test/, tests/, fixtures/, __tests__/, __fixtures__/ or __mocks__/, since a test's markup is never shipped. A Storybook story does count, because it is a component your team looks at. Files the pull request deletes do not count. Draft pull requests wait, silently and without a check, until they are marked ready for review.

One matching file is enough. A pull request with 40 backend files and one .css file is reviewed, and only that file's added lines are looked at, which is why the numbers on the check count UI files rather than changed files.

If nothing matches, the check reads Skipped · no UI files changed in neutral, no comment is posted, and no review is spent. That is the common case for a backend team and it is meant to be free.

What your design system is read from

Crocotaste reads your system at the pull request's base commit, so a change to DESIGN.md inside a pull request never judges that same pull request. It reads DESIGN.md at the repository root, or docs/DESIGN.md when there is no root one, and nothing deeper, along with your stylesheets, Tailwind configs and component files. When you have more component files than a review reads, your shared primitives (a ui/, generic/ or primitives/ folder) come first, and stories and tests are left out. A component is any PascalCase export from a file under components/ or ui/ (a function, a class, a constant, or a forwardRef or memo default export), and a Vue, Svelte or Astro file there is a component named after the file. A component built with cva or tv has its variant groups read and shown to the AI review, so a component restyled by hand into a look one of its variants already gives can be pointed at that variant. The rules you already wrote for your coding agents are read too: a bullet in AGENTS.md, CLAUDE.md or your Cursor rules under a heading about design, UI, styling, CSS, Tailwind or accessibility is a convention a finding can cite, and the rest of those files is left alone. A rule is read only under such a heading, so a .cursorrules with no headings gives nothing. A repository whose only system is those rules is reviewed, and each pull request uses a review.

Very large files, generated directories (node_modules, dist, build, .next, coverage, out, vendor) and test material (test, tests, fixtures, __tests__, __fixtures__, __mocks__) are skipped, so a fixture's tokens are never read as your team's. A custom property named for a dimension (--control-lg, --icon-size, --max-w-canvas) is read as a size and never offered for padding or a gap. A repository big enough to hit one of the reading limits is told so on the pull request: the summary says References were capped rather than quietly reviewing against half a system.

In a monorepo the root DESIGN.md is the one read, so the repository is reviewed against one system rather than one per package; a DESIGN.md inside a package, an example or a test fixture is never picked up. If your packages have genuinely different rules, keep the shared file at the root and record the per-package rules as conventions and decisions inside it.

What is judged

Only the lines your pull request added can be findings. The AI review also sees the lines you removed in the same files, as context and never as an anchor, so dropping an alt or a dark: variant your DESIGN.md requires is reported on the line that replaced it; untouched files are never findings, so a review can only ever be about work in this pull request. A pull request past the review ceiling is skipped whole, never in part: more than 100 UI files, 5000 added UI lines or 300 changed files. The check states the measured size and the ceiling, no review is spent, and splitting the pull request gets each part reviewed normally.

Why my pull request was not reviewed

In order of how often it turns out to be the answer:

1. No UI file changed. Check the file list against the globs above.
2. The pull request is still a draft. Mark it ready for review; the check appears then.
3. The balance is empty. The check says Review budget used · top up or upgrade; see billing and reviews.
4. The repository had nothing to check against yet: no DESIGN.md, no tokens, no components and no UI rules in an agent guide were parsed. The check says Skipped · no design system found and no review is spent; add a DESIGN.md or your tokens.
5. The repository is paused or on demand in the dashboard (on demand reviews only on @crocotaste review or Re-run), or GitHub removed it from the installation.
6. GitHub could not deliver the webhook. GitHub does not retry a failed delivery, so comment @crocotaste review or press Re-run in the dashboard. When a review fails covers this and every other failure.