ui-component-patterns

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.
license	MIT
metadata	{"tags":"ui-components, react, typescript, composition, variants, slots, reusable, frontend","platforms":"Claude, ChatGPT, Gemini, Codex","version":"2.1.0","source":"akillness/oh-my-skills","modernization":"2026-04-13T00:00:00.000Z","hardening":"2026-04-19T00:00:00.000Z"}

UI Component Patterns

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:

1. identify the reusable component pressure first,
2. choose one bounded packet,
3. keep shared-vs-local and parent-vs-component ownership visible,
4. separate alternate-root composition from broader system or accessibility work,
5. route neighboring frontend concerns honestly.

Read these support docs first:

• references/intake-packets-and-route-outs.md
• references/component-api-checklist.md
• references/handoff-boundaries.md

When to use this skill

• 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 →