What problem does it solve?
When maintaining a design system that ships components to both React (browser DOM) and Lynx (native renderer), it is hard to know whether both platforms expose the same exports, props, slots, variants, states, events, and accessibility surface. This Skill statically compares the two public surfaces of a single component in the current checkout and separates genuine implementation gaps from expected platform constraints.
Core Features & Use Cases
- Cross-platform API comparison: Reads the component's real implementation, public API, Recipe, Registry, and documentation paths for both React and Lynx, then reports common values, reactOnly, and lynxOnly per dimension with confidence levels (confirmed, partial, unknown).
- Platform difference classification: Distinguishes documented Lynx platform constraints (no asChild/Slot composition, native accessibility-* properties instead of ARIA, accessibility-heading instead of heading levels, no keyboard focus model, no CSS media queries) from differences that still need manual review.
- Conservative confidence handling: When props use extends, Omit, or inherited external types, it downgrades affected dimensions to unknown instead of falsely declaring gaps.
- Use Case: Before adding a new prop to ProgressCircle, run the parity check to confirm whether React and Lynx currently expose the same props and whether any existing difference is an intentional platform constraint.
Quick Start
Ask the AI to run the seed-api-parity comparison for a component such as ProgressCircle and summarize which differences are expected platform constraints versus ones needing review.