Help us improve
Share bugs, ideas, or general feedback.
From grimoire
Designs props interfaces, composition models, and public APIs for reusable React/UI components using atomic design and inversion of control patterns.
npx claudepluginhub jeffreytse/grimoire --plugin grimoireHow this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:design-component-apiThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Design component interfaces that are easy to use correctly, hard to use incorrectly, and flexible enough to outlast their initial use case.
Designs reusable UI components with a clear props contract, single responsibility, and built-in accessibility before writing implementation code.
Builds production-ready frontend components with accessible markup, sensible props, and defined states. Use when creating, refactoring, or designing component APIs.
Provides React composition patterns to refactor components avoiding boolean prop proliferation, using compound components, render props, context providers, and React 19 APIs. For building flexible libraries.
Share bugs, ideas, or general feedback.
Design component interfaces that are easy to use correctly, hard to use incorrectly, and flexible enough to outlast their initial use case.
Adopted by: Radix UI, Headless UI, Chakra UI, and shadcn/ui — the most widely adopted React component libraries all use these patterns; Kent C. Dodds's compound component and inversion of control patterns are curriculum in React training programs globally
Impact: Radix UI's accessibility-first, behavior-composable API is now the standard reference for accessible component design; libraries using inversion of control report dramatically fewer "escape hatch" issues where users need to patch around the library
A component API is a contract. Once published and used, breaking changes cost the entire consuming codebase. Designing for composition, not configuration, produces components that can adapt to unforeseen requirements without API changes — extending the useful life of the interface.
<Modal showFooter showCloseButton footerContent={...}>, use <Modal><Modal.Header /><Modal.Body /><Modal.Footer /></Modal>; each compound component controls its own areaonSort={(data) => sort(data)} (library controls behavior), expose renderItem or getFilteredItems (consumer controls behavior); use this when built-in behavior will inevitably be wrong for some use caseany; prefer union types over booleans for mutually exclusive states (variant: 'primary' | 'secondary' not isPrimary: boolean)ref and spread remaining props onto the root element; this enables consumers to attach event listeners and accessibility attributesclassName or style prop and let consumers handle visual edge casesisDisabled not notEnabled; isOpen not closedonClick to mean "on card click" when the component is not the target elementConfiguration anti-pattern: <DataTable sortable filterable paginationPosition="bottom" emptyStateText="No results" />
Composition pattern: <DataTable><DataTable.Toolbar><DataTable.Filter /></DataTable.Toolbar><DataTable.Body /><DataTable.Pagination /></DataTable> — each child is independently replaceable.
UserCard with hardcoded user-domain props cannot become a ProductCard without a rewrite; design for the rendering pattern, not the data domain