// Review UI changes in gray-ui-csm for compliance with PROJECT_RULES.md, semantic token usage, shared primitive reuse, responsive behavior, theme parity, and interaction-state coverage. Use after building or editing UI, before merge, or when checking whether a screen still matches the repo's design system.
Implement or modify code in gray-ui-csm while following PROJECT_RULES.md, established route and feature boundaries, shared UI reuse, and mock-data placement rules. Use when building a screen, refactoring a flow, deciding where code should live, wiring state, or checking whether a change matches the repo's implementation patterns.
Review gray-ui-csm changes for maintainability, scaling risk, hardcoding, layering drift, and deviation from PROJECT_RULES.md and established repo patterns. Use after implementation, before commit, or when deciding whether a change will remain easy to extend and safe to build on.
| name | gray-ui-csm-design-system-review |
| description | Review UI changes in gray-ui-csm for compliance with PROJECT_RULES.md, semantic token usage, shared primitive reuse, responsive behavior, theme parity, and interaction-state coverage. Use after building or editing UI, before merge, or when checking whether a screen still matches the repo's design system. |
Use this skill as a focused UI review pass after implementation. Read PROJECT_RULES.md first and compare the change against the repo's actual design system, not against generic frontend taste.
Start with:
components/ui or components/data-grid primitivesapp/globals.cssFlag when the change:
components/uicomponents/data-gridReview whether the changed surface still respects:
Prefer consistency with:
app/globals.csstickets and customersFlag screens that look locally correct but drift from the repo's visual language.
Return findings first, ordered by severity.
For each finding, include:
If there are no findings, say so explicitly and mention any residual gaps such as unverified responsive states or theme states.