Component PR Review Checklist

Component library PRs create contracts that many teams inherit. This checklist keeps reviews focused on usability, safety, and long-term maintenance.

• Prop names match existing library conventions.
• Required props are truly required for a valid component.
• Variants are finite and documented.
• Escape hatches are intentional and do not bypass tokens by default.
• Breaking changes include migration notes.

• Keyboard behavior matches the expected pattern.
• Focus states are visible and token-based.
• Labels, descriptions, and error messages are connected correctly.
• Disabled and loading states communicate meaning without color alone.
• Screen reader behavior has been tested for interactive components.

• No raw colors, spacing values, or one-off shadows are introduced.
• Responsive behavior is encoded in the component or documented for consumers.
• The component supports light and dark themes.
• Visual states cover hover, active, focus, disabled, loading, success, warning, and error where relevant.

• The component works in common layout patterns.
• Slot or children APIs are constrained enough to protect accessibility.
• Product-specific behavior is not baked into the primitive.
• Examples show realistic composition, not only isolated demos.

• Unit tests cover behavior, not implementation details.
• Visual examples include all meaningful variants.
• Documentation explains when not to use the component.
• Changeset or release notes describe consumer impact.

Ask: "If another team copies this pattern six months from now, will the API still guide them toward the right outcome?"