本技能面向 WordPress 设计系统贡献的代码审查场景，适用于审查 @wordpress/components、@wordpress/ui、@wordpress/theme 这些包的变更及其公开契约。它不用于仅消费这些包的应用代码审查。
主要审查方向包括：
-
行为放置与重复实现：检查产品特定行为是否被错误地放入设计系统包，或是否出现重复实现。在新增 API 或实现之前，应确认现有组件、辅助函数或令牌是否已能满足需求。当组件选择存在疑问时，可使用 MCP 服务器的 get_components 和 get_component_details，或指南中的推荐来源，并对照被审查的源码进行验证。
-
组件组合是否被破坏：检查 prop 与 ref 转发、渲染元素、受控与非受控状态、回调参数以及默认行为的变化。应检查受影响的包装组件和复合组件。对于引入有意义风险的集成变更，应测试我们改动的集成，而不重复底层依赖自身的行文测试。
-
不兼容的公开变更：使用指南中的契约比较，检查被移除或改变的 props、导出、令牌、样式钩子和扩展点。需要包括外部消费者；已迁移的 Gutenberg 调用方不能证明插件兼容性。检查已发布的类型是否通过声明的依赖解析。
-
破坏组合或主题化的样式：查找不合适的硬编码值、按值而非按用途选择的令牌、丢失的消费者覆盖，以及依赖样式表顺序的声明。在可用时，使用设计系统 MCP 服务器的 get_design_tokens。没有 MCP 时，使用令牌参考进行语义选择。遵循该包的样式指南了解其 CSS 约定。当变更可能改变 portal 目标或主题模式时，应检查这些方面。
-
交互或可访问性回归：检查变更可能影响的语义、可访问名称、键盘路径、焦点和禁用状态。使用指南中的验证指导来核对标准和浏览器证据。通过类型检查或 class 断言并不能证明交互或视觉一致性。
-
遗留的公开文档或生成产物：检查受影响的 prop 文档、stories、组件状态与推荐元数据、生成的令牌资产以及必需的 changelog。对于未改变的能力，不应要求新增 stories 或文档。
只有在变更的契约跨越独立更新的包与 WordPress 版本时，才应用 package-runtime-compatibility。对于 Emotion 迁移，使用迁移指南检查级联和消费者兼容性。
审查结果应紧扣本次变更，包括下游影响。缺少测试本身不构成问题发现。应复用已有覆盖，仅当代码或集成引入了具体且有意义的风险时才要求新增检查。对于可以用一个连贯修复解决的多个关注点，应合并处理。
在 Gutenberg 检出环境中，应从被检出的修订版本读取相对链接；不在检出环境中时，从 GitHub 上 Gutenberg 的 .agents/skills/design-system-code-review/ 解析这些链接。应阅读受影响包的 AGENTS.md 以及 Working with WordPress Design System packages。审查拟议的源码及其影响的消费者。对于包与应用代码混合的变更，还应针对应用代码使用 design-system-ui-review。