Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →wordpress/design-system-ui-composition
Use when building or changing a Gutenberg feature, plugin interface, or standalone application UI with public `@wordpress/components`, `@wordpress/ui`, or `@wordpress/theme` APIs, including when the code does not yet use the Design System; do not use to change package source or depend on package-private implementation details.
Passed 18 of 22 test cases with the skill, and 12 of 22 without it.
and 6 more in the full report
6 fixed12 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
We have a custom modal dialog in our editor plugin that was built from scratch. I want to replace it with standard design system UI elements and properly handle token styling and overlays. Can you update the React component for this interface?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends standard `@wordpress/components` Modal instead of native HTML dialog elements. | Missed | Passed |
| Inspects the portal container document context to verify overlay style delivery. | Missed | Passed |
The instructions your model reads when the skill loads.
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-composition/ in Gutenberg on GitHub.
Identify the interaction being added or changed and find a similar implementation in the target project. For an existing interface, check which component manages its state before editing.
For a text or prop change, keep the existing supported component unless the requested behavior requires a replacement.
Use the Design System MCP server's get_components to find the recommended component, then get_component_details to check its behavior, props, usage, and import. Without MCP, follow Choose a recommended component.
Prefer component props for styling they already support. For custom styles, use the Design System MCP server's get_design_tokens when available. Without MCP, use the token reference. Choose semantic --wpds-* tokens by the element's purpose and state, not by matching a raw value. Use --wp--preset--* when styling blocks or content previews with the active theme's theme.json presets. Do not mechanically replace every CSS literal with a token.
For Gutenberg, verify the API against the current source. For external projects using a different package or WordPress version, follow the target-version checks.
Choose the smallest public composition that meets the interaction contract. Keep product-specific compositions in the consuming package.
If a public API cannot meet the need, describe the missing behavior and options using Contributing to the Design System. Respect an existing user decision about the gap; otherwise ask before introducing a workaround. Package fixes use design-system-contribution in a Gutenberg checkout. Outside one, draft an upstream report within the user's authorized scope.
Use Verify the affected behavior to select checks for the changed interaction and rendering context. Reuse existing coverage and rely on dependency tests for behavior the dependency owns. Add a local test only when our code or integration introduces a meaningful regression risk that existing coverage does not address. Report what was verified and any material uncertainty.
test cases passed, vs 12 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.