Docs
CI and baselines
check runs the same rules as check_ui and exits 1 on errors (or on more than --max-warnings warnings). It skips the design system's own component files, the ones components matches: they implement the scale and the primitives the rules enforce, so a fresh shadcn/ui project's p-[3px] is not a finding. --include-design-system, or "includeDesignSystem": true in the config, lints them too.
Pin it as a dev dependency, so CI, the plugin's hook and everyone on the team run the same version:
npm install --save-dev @dgesteves/design-system-mcp- run: npx design-system-mcp check . --format github --require-design-system--format github prints workflow commands, so findings show up as annotations on the pull request. --format json prints the raw results.
When no components or no color tokens are found, check and check_ui say which rules could not run and point here, so a clean result is not mistaken for a checked one. In CI, --require-design-system turns that into a failure (exit code 2), for when the design system moves and the globs stop matching.
Adopting it in an existing codebase
An established app can start with hundreds of findings (midday's dashboard has about 1,300). Record them once and commit the file:
npx -y @dgesteves/design-system-mcp check "src/**/*.tsx" --update-baseline# Baseline: 1,307 findings in 275 files → design-system-mcp.baseline.jsonFrom then on, check reads design-system-mcp.baseline.json from the root whenever it exists and fails only on new findings: No new problems in 504 files (1,307 in the baseline). Entries are keyed by file, rule and the offending text with a count, not by line, so edits elsewhere in a file do not invalidate them, while a second bg-[#f7f7f7] where the baseline accepts one is reported. When findings get fixed, check says so and prints the command that drops them, which locks in the progress. Entries of a rule you turn off are kept rather than reported as fixed, a malformed baseline (a bad merge, say) is an error rather than something to overwrite, and paths are matched by their real spelling, so APP/ on macOS or a linked checkout finds the same entries. --ignore-baseline shows everything, and --baseline <file> uses another path. The baseline applies to the CLI only: check_ui still shows an agent every finding in the file it is editing.
Generated from the README when the site is built: #ci, #adopting-it-in-an-existing-codebase.