Catch design system violations in UI code instantly

Runs a fast, grep-based scan for common design-system violations - completing in seconds, unlike a deep manual audit - intended to run after every file change.

grep -n '#[0-9a-fA-F]\{3,8\}' [file] | grep -v 'theme.css\|tokens\|\.json'

It runs eight checks: hardcoded hex colors that should be semantic tokens (e.g. text-[#3C3C3C] should be text-text-primary); raw pixel values in Tailwind utilities instead of scale classes (e.g. p-[24px] should be p-6, gap-[12px] should be gap-3); old width/height syntax instead of the unified size-* utility (e.g. w-4 h-4 should be size-4); physical (LTR-only) spacing properties instead of logical properties (e.g. ml-2/mr-4 should be ms-2/me-4); forbidden pure-black colors (text-black, bg-black, #000000) that should use the active skin's text-primary token instead; components missing a data-slot attribute; font-size CSS variables used inside Tailwind's text-[var(--...)] syntax, flagged as critical because Tailwind v4 reads that namespace as color rather than font-size (fix: use an explicit text-[13px] value instead); and className built with a template literal instead of composed via cn().

Each check is implemented as one or two grep invocations against the target file(s), searching for the violation pattern (with false-positive exclusions where needed, e.g. excluding theme.css/tokens/.json files from the hex-color check). Results are reported in a fixed format: FAIL for hard violations (hardcoded hex, raw pixel values), WARN for softer issues (physical properties, missing data-slot), PASS when clean, with a file:line reference and the specific fix for each violation, plus a total error/warning count.

Use it for a quick automated check after a file change to catch common design-token violations in seconds. It only flags violations - it does not apply fixes. For deeper design judgment (composition, hierarchy, rhythm) use /ss-review; for accessibility specifically use /ss-a11y; for Nielsen UX heuristics use /ss-audit; for actually applying refactors, use /ss-review.

Input is a target file (or files) to lint, given as $ARGUMENTS. Output is a formatted pass/fail/warn report per violation, with file:line location, the specific rule broken, and the recommended fix.

Built around Tailwind CSS v4 utility conventions and a cn() className-composition helper - the font-size check specifically targets a known Tailwind v4 namespace conflict between CSS variable font sizes and color variables.

Developers who want an instant, automated check for common design-system violations (hardcoded colors, raw pixel values, physical spacing properties, missing data-slot attributes) right after editing a file, before escalating to a deeper manual review.