.agents/design-system-style-rules.md
Use these rules when reviewing CSS/SCSS/Vue style changes, especially in
packages/frontend/ and packages/frontend/@n8n/design-system/.
Prefer this order when choosing visual values:
packages/frontend/@n8n/design-system/src/css/_tokens.scsspackages/frontend/@n8n/design-system/src/css/_primitives.scssIf no token exists, request a short rationale in the PR.
Flag hard-coded visual values and suggest token alternatives. This includes:
#fff, rgb(), hsl(), oklch())px, rem, numeric layout constants in styles)cubic-bezier(...))Severity: strong warning (expected migration to tokens/primitives when possible).
In _tokens.scss, the compatibility section labeled
"Legacy tokens (kept for compatibility)" is considered legacy usage.
When new or modified code uses these legacy token families, flag it as a migration opportunity and recommend semantic token usage where available.
Severity: strong warning (discourage new usage, allow compatibility paths).
Flag new usage of deprecated/legacy style surfaces in design-system components, for example:
Button.legacy.scss and legacy button override classeshighlight, highlight-fill)Severity: strong warning (prefer modern semantic variants/components).
If a PR changes one token reference to another (for example
--text-color -> --text-color--subtle), flag it as a soft warning.
Ask for intent in the PR description/comment:
Do not treat token substitution as a hard failure by default.