Compose a WordPress Design System interface

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.

Start with the requested behavior

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.

Choose components and tokens

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.