New @shadcn/lint brings agent-friendly Tailwind design-system rules to ESLint and Oxlint

A linter that talks to agents

A new tool called @shadcn/lint takes aim at a specific friction point in AI-assisted frontend work: keeping generated code inside a project's design system. According to a dev.to post introducing the project, the linter is built for Tailwind design systems and is explicitly designed to interact with coding agents rather than only with human developers.

The core idea is straightforward. A team defines the style rules for its project, and the linter enforces them. What sets @shadcn/lint apart, the post explains, is what happens when a rule is broken: the error message details the violation and then guides the correction by pointing to the components, variants and themes that already exist in the project. That kind of context-rich output is exactly what an autonomous agent needs to self-correct on its next edit.

Where it fits

The post says the tool targets developers using AI agents on projects built with Tailwind v4. It runs through two linting engines, ESLint and Oxlint, and supports React, Svelte and Vue. Despite the package name, the shadcn/ui component library is not a prerequisite; the linter can be adopted independently of it.

The stated goals are consistency-oriented: prevent unwanted restyling of existing components and block arbitrary values from creeping in, all without altering the APIs of the components a project already exposes.

The rules that ship today

Two rules are highlighted. shadcn/no-restyle lets a project declare, component by component, which properties are allowed to change, so an agent or a human can adjust the permitted knobs but cannot freely rewrite a component's styling. shadcn/no-arbitrary-values requires code to draw from the theme's scales instead of one-off values, addressing a familiar source of visual drift in Tailwind projects, where ad-hoc measurements and colors accumulate in the markup over time.

Both rules are enabled in the project's normal linter configuration file, so enforcement slots into existing lint workflows and CI pipelines rather than requiring a separate toolchain.

Installation and onboarding

Getting started is notably agent-friendly. The post suggests passing the project's SETUP.md installation documentation directly to your coding agent and letting it handle setup, with manual installation offered as the alternative for teams that prefer to do it themselves.

Manual setup is a single npm command, npm install -D @shadcn/lint eslint @typescript-eslint/parser, followed by enabling the desired rules in an ESLint or Oxlint configuration. The official repository is hosted under the shadcn-ui organization on GitHub.

Why it matters

Tools like this reflect a shift in what linting is for. Traditionally, a linter's audience is the developer reading a terminal; here the primary reader is an agent that will parse the message and act on it. Error output that references the project's own components and theme, rather than generic style guidance, gives agents a concrete path to a valid fix instead of another guess.

The tool also targets two failure modes that anyone who has let an AI agent touch a UI will recognize: agents that "fix" styling by rebuilding a component from scratch, drifting away from the design system, and agents that sprinkle arbitrary values throughout the markup. Encoding those constraints as lint rules moves design-system enforcement into the automated feedback loop, before a human reviewer ever sees the diff.

For teams investing in agentic coding workflows on Tailwind v4, this is a small tool addressing a very real coordination problem: how to give an agent freedom to write UI code while keeping the result inside the system your designers actually defined.