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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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. When a Gutenberg change replaces a @wordpress/components component with its @wordpress/ui replacement, use the reviewer checks for that stage in Replace a legacy component.

Keep the review focused