Automating design system standards enforcement

WHAT THIS TESTS Whether you can design defense in depth that gives fast local feedback and a hard CI backstop, rather than relying on humans to remember the rules.

A GOOD ANSWER COVERS Layer enforcement from the inside out. In the editor, ship a shared ESLint and Stylelint config with custom rules: ban raw hex and px where tokens exist, require approved component imports, flag deprecated props, and check API conventions; these show squiggles as the contributor types. Add pre-commit hooks via husky and lint-staged so violations block the commit locally and feedback is instant. Encode accessibility checks with axe-core run inside unit tests and Storybook interaction or a11y tests, plus type-level enforcement through strict TypeScript and exported prop types. In CI, run the identical lint, type, a11y, and unit suites as required status checks, add visual regression with a tool like Chromatik or Playwright snapshots, and block merges on failure. Keep local and CI configs identical to avoid surprises.

COMMON WRONG ANSWERS Relying on manual code review to catch token misuse and a11y issues. Running checks only in CI, so contributors discover problems late. Writing prose guidelines with no automated enforcement. Different rule sets locally versus CI, causing it-works-on-my-machine failures. Ignoring accessibility automation.

LIKELY FOLLOW-UPS How do you write a custom ESLint rule to ban raw colors? What can axe catch automatically and what still needs manual a11y review? How do you keep local and CI configs in sync? How do you avoid slow CI from heavy visual tests?

ONE CONCRETE EXAMPLE A contributor types a raw hex color; a custom ESLint rule flags it in-editor and suggests the matching token. A pre-commit hook blocks the commit until fixed. Their PR runs the same ESLint, axe-based a11y tests, TypeScript check, and visual regression in CI as required checks, so a non-conforming change cannot merge.