review-react-component-design
GitHub审查React组件设计,评估边界、API、可重用性及打包成本。检查数据流、无障碍、SSR约束及树摇优化,确保架构合理与性能最优。
触发场景
安装
npx skills add videojs/video.js --skill review-react-component-design -g -y
SKILL.md
Frontmatter
{
"name": "review-react-component-design",
"description": "Review React component designs. Use for boundaries, APIs, opt-outs, and bundles."
}
React component design review
Read the proposal, nearby records, and relevant React code, tests, exports, and package metadata.
- Ask whether the proposal is a reusable primitive or app/skin composition before adding a component or part.
- Trace ownership and data flow across core, DOM behavior, and React. Check effects and cleanup.
- Review compound anatomy, React and CSS APIs, and whether each addition has a consumer. Leave visual structure to CSS. If the surface spans independent features, separate them into another component or hook. Treat descendant selectors,
:has(), and other complex selectors introduced by composition as a likely sign of a weak primitive boundary or missingdata-*or CSS custom-property hooks. - Exercise omission, render replacement, styling, behavior, and import opt-outs.
- Weigh API complexity against bundle cost and verify client boundaries. Compound APIs should use tree-shakeable ESM namespace re-exports rather than runtime namespace objects. Check accessibility, interaction, and SSR constraints.
Use packages/react/src/ui/, use-render.tsx, and package metadata as evidence. Report findings by severity with the smallest change.
Where local precedent is insufficient, consult React for data flow, Base UI for headless composition, WAI-ARIA APG for interaction patterns, and webpack for tree shaking.
Example
Input: “Review this React chapter-menu design.”
Output: Prioritized findings about boundaries, APIs, opt-outs, SSR, accessibility, and bundle cost.
版本历史
- 8a0a3d8 当前 2026-10-20 08:03


