UI Lint Rules

Catch the interface mistakes that reviews keep missing, before they reach a branch.

involved Developer Experience

What it adds

A set of automated checks over the app's own markup and component usage for unlabelled controls, invalid variants, and unsafe interactive elements.

What your agent is told to do

1
Start from the defects the app has actually shipped — read recent bug reports and review comments — and write rules for those, rather than adopting a large generic rule set that mostly reports things nobody intends to fix.
2
Cover the categories that reviewers reliably miss: controls without accessible names, variant or size values a component does not support, click handlers on non-interactive elements, headings that skip levels, and images with no alternative text decision.
3
Report each finding with the file, the line, what is wrong, and what to do instead. A rule that only names itself gets suppressed rather than fixed.
4
Provide a documented suppression mechanism that requires a reason on each exception, and surface the list of active suppressions, so exceptions are visible debt rather than an invisible amnesty.
5
Do not autofix anything ambiguous. Replacing a missing accessible name with a guess produces markup that passes the check and still fails the user, which is worse than the original failure because it stops being reported.

Edge cases it handles

A noisy rule set is worse than none, because the whole thing gets disabled after the first review that reports two hundred findings. Introduce rules as warnings, drive the count to zero, and only then make them errors.
Autofixing must be limited to cases with exactly one correct outcome, such as normalising a renamed variant value; anything requiring a judgement about meaning must be reported for a human.
Every rule needs a documented exception path with a required reason, and the exception must be scoped to the specific line rather than switching the rule off for a whole file.
Rules must be versioned with the design system, so a component renaming its variants ships the rule change alongside it and does not break every consumer at once.
Rules that need runtime information — computed contrast, actual focus order — cannot be answered from source alone; route those to a browser-based check and say clearly which layer owns each rule.
Findings on generated or vendored code must be excluded by default, or the report is dominated by files nobody will edit.
Raw colour, spacing, and radius values are the subject of Design Token Linter; consume its findings here rather than writing a second, differently-tuned set of token rules.

Definition of done

Checks run on every change and report file, line, cause, and remedy for each finding.
The rule set covers accessible names, invalid component variants, non-interactive click targets, and heading structure.
Autofix applies only to cases with a single unambiguous correct result.
Exceptions require a stated reason, are scoped to a line, and are listed somewhere visible.
Rules are versioned with the design system and change alongside the components they check.
The current codebase reports zero errors, so any new finding is genuinely new.
Token-value rules are delegated to Design Token Linter rather than duplicated.
The feature matches the existing design system.
No existing functionality is broken.

Related features

AI Cost Budgets

Multi-Model Routing

SEO Setup

How it works

1

Copy the link

Grab the Markdown instruction URL for this feature.
2

Give it to your AI

Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
3

It inspects, then implements

Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.