用途
该技能用于在构建或修改 Gutenberg、插件或应用界面时，指导开发者按照 WordPress Design System 的方式组合 UI。适用范围包括尚未采用 WordPress Design System 包的自定义界面。
主要能力
- 从请求的行为出发，识别正在新增或修改的交互，并在目标项目中寻找相似实现。
- 对现有界面，在编辑前确认由哪个组件管理其状态。
- 对于文本或 prop 变更，保留现有受支持的组件，除非请求的行为需要替换。
- 通过 Design System MCP 服务器的 get_components 查找推荐组件，再用 get_component_details 检查其行为、props、用法和导入方式；无 MCP 时按照“选择推荐组件”的指引操作。
- 优先使用组件 props 已支持的样式；自定义样式时，如可用则使用 get_design_tokens，无 MCP 时使用令牌参考；按元素用途和状态选择语义化 --wpds-* 令牌，而非匹配原始值；对块或内容预览使用 --wp--preset--* 时采用当前主题的 theme.json 预设；不机械地把每个 CSS 字面量替换为令牌。
- 对 Gutenberg，对照当前源码验证 API；对外部项目，若使用不同包或 WordPress 版本，遵循目标版本检查。
- 选择满足交互契约的最小公开组合，产品特定组合保留在消费包中。
使用方式
该技能通过一套流程化的检查与决策指引来使用：
- 从请求的行为开始，识别交互并寻找相似实现。
- 选择组件与令牌，优先使用组件已支持的 props 或语义化令牌。
- 检查变更后的集成：在构建自定义按钮、对话框等组件前，先确认是否已有公开组件或组合满足需求；迁移时使用契约比较，包括仓库外使用的扩展点；对浮层或渲染目标变更，阅读“Setup depends on the document”，检查实际 portal 容器及其所属 document，验证样式传递、继承令牌和焦点，注意同 document 的 portal 不会创建新 document；对独立应用或 document，仅对在该处渲染的包验证设置，并记录影响完成度的未解决样式表、运行时样式、主题或浮层需求。
- 若公开 API 无法满足需求，按“Contributing to the Design System”描述缺失行为与选项；尊重用户已有的决定，否则在引入变通方案前先询问；包修复在 Gutenberg checkout 中使用 design-system-contribution，否则在用户授权范围内起草上游报告。
- 验证并收尾：使用“Verify the affected behavior”为变更的交互和渲染上下文选择检查项；复用现有覆盖，依赖依赖项自身的测试；仅当自身代码或集成引入现有覆盖未涉及的有意义回归风险时，才添加本地测试；报告已验证内容以及任何重大不确定性。
适用场景
- 在 Gutenberg 中构建或修改界面。
- 开发插件或应用界面，包括尚未使用 WordPress Design System 包的自定义 UI。
- 需要为交互选择合适的 Design System 组件与设计令牌。
- 需要判断是否应构建自定义组件，或复用已有公开组件与组合。
- 涉及迁移、浮层、portal 容器、渲染目标变更等集成检查。
- 需要向上游贡献或报告设计系统缺口。
限制
- 在 Gutenberg checkout 中，需从检出的修订版读取相对链接；在 checkout 之外，需从 GitHub 上 Gutenberg 的 .agents/skills/design-system-ui-composition/ 解析。
- 对 Gutenberg，API 必须对照当前源码验证。
- 对外部项目，若使用不同包或 WordPress 版本，需遵循目标版本检查。
- 同 document 的 portal 不会创建新 document。
- 仅对在目标 document 中渲染的包验证设置。
- 若公开 API 无法满足需求且用户已有决定，需尊重该决定；否则在引入变通方案前先询问。
- 包修复需在 Gutenberg checkout 中使用 design-system-contribution；否则需在用户授权范围内起草上游报告。
- 仅在自身代码或集成引入现有覆盖未涉及的有意义回归风险时才添加本地测试。
- 资料未提供该技能的收费、价格、平台支持范围或效果保证等信息。