Routing-first reusable component architecture for shared frontend primitives, slots, controlled ownership, alternate-root composition, and docs/verification packets. Use when the user needs to decide what should become a shared primitive, how a component API should expose variants or subcomponents, when parent state should control the component, how to compose a button/link/dialog onto alternate element types, or what Storybook/example coverage is required. Route design-token or cross-product governance to `design-system`, accessibility-heavy remediation to `web-accessibility`, layout adaptation to `responsive-design`, app-level state ownership to `state-management`, and React performance work to `react-best-practices`.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
ui-component-patterns
description
Routing-first reusable component architecture for shared frontend primitives, slots, controlled ownership, alternate-root composition, and docs/verification packets. Use when the user needs to decide what should become a shared primitive, how a component API should expose variants or subcomponents, when parent state should control the component, how to compose a button/link/dialog onto alternate element types, or what Storybook/example coverage is required. Route design-token or cross-product governance to `design-system`, accessibility-heavy remediation to `web-accessibility`, layout adaptation to `responsive-design`, app-level state ownership to `state-management`, and React performance work to `react-best-practices`.
allowed-tools
Read Write Bash Grep Glob
compatibility
Best for React, TypeScript, and frontend/fullstack repos where the main job is reusable component API architecture. Not for full design-system governance, accessibility-only remediation, responsive layout strategy, or React/Next.js performance tuning as the primary owner.
Use this skill when the job is to classify the reusable component problem, choose one primary component packet, and leave behind a short component-architecture brief instead of a giant React-pattern dump.
The job is not to catalog every possible component pattern.
The job is to:
identify the reusable component pressure first,
choose one bounded packet,
keep shared-vs-local and parent-vs-component ownership visible,
separate alternate-root composition from broader system or accessibility work,
A team has too many similar buttons, cards, dialogs, field wrappers, or nav patterns and needs one shared primitive or component-family boundary.
A request mixes variants, slots, controlled-vs-uncontrolled behavior, wrappers, and docs expectations and needs routing before implementation.
You need to decide whether something should stay product-local, become a shared primitive, or split into primitive plus wrapper.
A component API is growing escape hatches and someone needs to shrink it into one honest packet.
The tricky part is alternate-root composition (button vs a/router Link, slotted child, custom wrapper) rather than pure styling.
Storybook/examples exist, but the docs/verification packet for states, usage rules, or edge cases is still unclear.
When not to use this skill
The main task is token governance, visual-language rules, primitive naming policy, or cross-product system direction → design-system
The main task is keyboard/focus behavior, semantics, labels, announcements, contrast, or manual accessibility remediation → web-accessibility
The main task is viewport/container adaptation, breakpoint strategy, reflow, or responsive media → responsive-design
The main task is broader app/workflow state ownership, server/client boundaries, or cross-screen state coordination → state-management
The main task is rerender churn, hydration, route performance, or bundle/runtime behavior →
react-best-practices
The reusable component boundary is already settled and the real job is just implementing it; in that case implement directly instead of reopening the architecture decision
Instructions
Step 1: Frame the reusable component job before naming props
primitive-boundary → decide shared vs local scope, primitive vs wrapper split, and what absolutely stays outside the shared API
slot-anatomy → define subcomponents/slots, variant boundaries, composition rules, and anatomy expectations for reusable structure
controlled-ownership → decide whether parent state, workflow state, or component-local defaults own the lifecycle
alternate-root-composition → handle asChild / component / wrapper-root behavior, prop spreading, refs, and semantic constraints when the primitive must compose onto another element
docs-verification → define Storybook/examples, state matrix, anti-usage notes, and the smallest credible verification surface for the component family
Step 6: Keep mechanism choice separate from ownership choice
Ownership — ui-component-patterns, design-system, web-accessibility, responsive-design, state-management, or react-best-practices
If the request starts from screenshots, Storybook drift, or a code diff, say explicitly that those artifacts are the signal, not the finished component decision.
Step 7: Route adjacent work explicitly
Use these route-outs when the problem crosses boundaries:
