CI Compliance Gate: the check Command

check turns your design system into a CI gate. It scans your UI source files against the same rules the check_compliance MCP tool and Layout Live use (hardcoded colours, hardcoded spacing, missing token references, unknown components) and fails the build when violations cross your threshold. Context tells the agent what on-brand means; check makes sure nothing off-brand merges anyway.

Usage

Run it from a project with a .layout/ kit (created by init or import):

bash

npx @layoutdesign/context check

It scans the project's UI sources, prints each violation with the rule, file and line, the offending value, and the nearest design token as a suggested fix, then exits with a code CI can act on.

Flags

Flag	What it does
--ci	Emits GitHub Actions annotations, so violations appear inline on the pull request diff.
--changed <ref>	Checks only files changed versus the given base ref (e.g. origin/main). Keeps large repos fast and gates only what the PR touched.
--format json	Machine-readable output: every violation with rule, file, line, offending value, and nearest-token suggestion. Default is a human-readable report.
--warnings-as-errors	Treats warnings as errors, so any violation fails the gate.
--max-warnings <n>	Allows up to n warnings before the gate fails. Useful for ratcheting an existing codebase down over time.
--exclude <globs>	Glob patterns to skip, e.g. legacy directories or generated files.

Adopting on an existing codebase? Start with --changed so only new work is gated, and use --max-warnings as a ratchet: set it to today's count and lower it every sprint.

Exit codes

Code	Meaning
0	Pass. No violations beyond your thresholds.
1	Gate failed. Violations exceeded the thresholds (errors, or warnings past --max-warnings).
2	Setup error. No .layout/ kit found, unreadable config, or similar. Fix the setup rather than the code.

GitHub Actions setup

A complete workflow that checks only the files a pull request changed and annotates violations inline on the diff:

yaml

name: Design system compliance
on: [pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # needed for --changed to resolve the base ref
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Check design system compliance
        run: npx @layoutdesign/context check --ci --changed origin/${{ github.base_ref }}

Commit your .layout/ directory to the repo so CI has the kit to check against, the same way you commit an ESLint config.

check works in any CI system, not just GitHub Actions: without --ci it prints a plain report and the exit codes drive the pass/fail, and --format json feeds any custom reporting you run on top.

Where it fits in the golden path

Layout enforces your design system at three points: the MCP server gives your agent the right context while it writes, Layout Live gates human tweaks to tokens as they happen, and check is the last line, catching anything off-system before it merges, whoever (or whatever) wrote it.