| name | design-system-code-review |
| description | Use when reviewing a Gutenberg change to a WordPress Design System package or its public contract, including `@wordpress/components`, `@wordpress/ui`, or `@wordpress/theme`; do not use to implement the change or review a consumer-only application. |
Review a WordPress Design System contribution
Establish the review boundary
- Define the changed public surface and observable behaviour.
- Scan the complete diff once, then classify it as:
- Internal: no public contract or observable behaviour changes.
- Public: adds, removes, renames, or changes supported behaviour.
- Read Working with WordPress Design System packages
and the applicable package source guidance.
- Apply the public guide's evidence precedence: the diff is the proposed
post-change state, target source is its baseline, and MCP is supplementary
current-design context.
Review proportionally
For an internal change, verify contract preservation and focused coverage, then
skip the public-only work below. For a public change:
- assess Gutenberg and external package consumers separately;
- verify compatibility and migration rather than treating repository migration
as sufficient;
- before drafting findings for a removal, replacement, or rename, compare the
old and new accepted values, semantics, states, interaction, and styling in
a compact contract table; complete the comparison even after finding one
valid defect;
For either classification, use the public guide's
package completion gate
and inspect only the surfaces applicable to the change.
If a published package can run with a dependency supplied separately by WordPress, apply the package-runtime-compatibility skill before concluding the review.
Use browser evidence when source or class assertions cannot establish visual,
focus, motion, or layout parity.
Finding evidence gate
Before reporting a finding, identify the exact changed line, affected public
contract or behaviour, target-source or consumer evidence, and concrete impact.
Treat incomplete diff context as a verification gap unless the complete patch
proves the defect. Apply the same evidence and precision standard even when
another valid defect already exists.
Output contract
Recheck every finding against the complete diff and source. Separate defects,
verification gaps, and optional follow-ups. Report material findings with
proportional severity and the smallest coherent direction; report no findings
when the evidence exposes none.
