Use when reviewing a Gutenberg, plugin, or application UI/UX change for correct public WordPress Design System usage and user-facing behaviour, including a component, control, visual styling, token, interaction, layout, overlay, or other user-facing interface; do not use to implement a change or review Design System package source.
SkillScore83Maintained
Automatic
◆Design & UX Review pack
Last verified 10/10/2026
What it changes
Passed 19 of 23 test cases with the skill, and 16 of 23 without it.
Without skill70%
With skill83%
Checks it passed that the model alone missed
Recommends semantic `--wpds-*` tokens for interface styling.
Recommends identifying the missing capability as a Design System gap.
Recommends evaluating consumer changes against consumer design system UI review guidelines.
and 2 more in the full report
4 fixed15 passed either way3 still failing1 broke
Pass-rate lift
+13 pp
Tokens
+6%
Agent turns
0%
Response time
-28%
Model gemini-3.6-flashMeasured 10/10/2026v219 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
A team needs a drag-and-drop sortable tag selection field in a Gutenberg sidebar. The `@wordpress/components` library does not currently provide a sortable token component. Should the team write complex CSS hack overrides on `FormTokenField` or take another approach?
What was checked, without and with the skill
Checked
Without skill
With skill
Advises against creating fragile CSS overrides on internal component structures.
Passed
Passed
Recommends identifying the missing capability as a Design System gap.
Missed
Passed
case-19 · gemini-3.6-flash · 10/10/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md23 linessingle file
Review UI for Design System use
In a Gutenberg checkout, read the relative links below from the checked-out revision. Outside a checkout, resolve them from .agents/skills/design-system-ui-review/ in Gutenberg on GitHub.
Read Working with WordPress Design System packages. Inspect the changed UI and styles, and consumers affected by the change. For a mixed package-and-consumer change, also use design-system-code-review on the package source.
What to look for
Custom UI that duplicates a recommended component. Check hand-built controls such as notices, buttons, dialogs, and menus. Use the Design System MCP server's get_components, then get_component_details to verify the recommended component's behavior, props, and import. Without MCP, use the guide's recommendation sources. Recommend a replacement when it meets the requirements and avoids unnecessary custom code or improves consistency; a visible bug is not required.
Hard-coded visual values. Look for colors, spacing, radii, typography, and shadows that should follow the Design System. Use the Design System MCP server's get_design_tokens when available. Without MCP, use the token reference to find a semantic token for the element's purpose and state. Prefer an existing component prop when it already expresses the intent. Do not replace every CSS literal or select a token merely because its current value matches.
Tokens used for the wrong purpose. Use semantic --wpds-* tokens for Design System interface styling and --wp--preset--* when styling blocks or content previews with the active theme's theme.json presets. Judge what is being styled: a content preview inside the editor can still need the active theme's presets. Check token roles and states as well as prefixes.
Dependence on component internals. Flag imports from package-private paths and selectors that depend on private classes or markup. Use documented props, styling hooks, or composition. If none meets the need, identify the missing capability rather than inventing an unsupported override.
Accessibility problems in custom controls or composition. Check accessible names, required keyboard behavior, focus indication, and focus handling affected by the change. If a recommended component supplies the missing behavior, name it. Use the guide's verification guidance for the applicable standards and browser checks.
Styles or theming lost at the rendering destination. Inspect the actual portal container and owner document. A same-document portal can lose inherited tokens without needing another stylesheet or root provider. For iframes and new windows, check existing document setup before recommending additions.
Components used outside their documented purpose. Compare new component uses and changed compositions with Storybook usage guidance or package documentation. Check intended use separately from prop support and accessibility.
For Gutenberg, verify recommendations against the reviewed source. For external projects using a different package or WordPress version, follow the guide's target-version checks. For replacements, use its contract comparison, including external extension points.
Keep the review focused
Do not request unrelated cleanup or migrate an existing supported component for a narrow copy or prop edit. Downstream breakage caused by the change is still in scope, even when the affected consumer is unchanged.
Do not request tests merely because coverage is absent. Rely on dependency coverage for behavior the dependency owns. Request a local test only for a concrete, meaningful regression risk introduced by our code or integration that existing coverage does not address. Follow the guide's test-selection guidance; avoid speculative edge cases and exhaustive combinations.
Name the verified component or token and explain what it improves. Combine findings when one replacement resolves them. Do not invent a replacement when the correct outcome is to identify a Design System gap.