frontend-react

Use when creating, editing, restructuring, or reviewing a React frontend component — including its folder layout and file organization (tsx/scss/index), where a component or sub-component should live, BEM class naming, SCSS styling, rem sizing, i18n of user-visible strings, barrel exports, and replacing inline JS style/hover handlers (e.g. onMouseEnter toggling classes) with CSS. Covers "this component file is in the wrong place — fix the structure", moving a flat .tsx into its own folder, and any question about how a component's files, styles, or markup should be organized.

Rules for FEATURE components in a React codebase — domain-coupled blocks that compose primitives and hold business logic/data. Activate when building or editing a domain feature (a panel/table/editor tied to your business data), or adding a new domain area. Framework-agnostic. Reached via frontend-react:component-placement.

Use when about to add, hand-roll, rename, move, or remove a custom React `use*` hook.

Rules for LAYOUT / app-chrome components in a React codebase — the shell, top bar, sidebar, command palette, and global overlays that frame every page. Activate when editing or adding app chrome. Framework-agnostic. Reached via frontend-react:component-placement.

When building or editing a React component that renders asynchronously-loaded data, decide whether it needs a loading skeleton — and if so, build a separate skeleton component colocated next to it from the shared Skeleton primitive. Activate whenever a component gains a loading state, shows a blank/"Loading…" gap, or you are reviewing async data UI.

Use this skill whenever writing, adding, or asking about a Storybook story for a React/UI component — including "add a story for X", "write a .stories file", questions about which states/variants a story should cover (default, empty, error, loading, disabled), how to show a component's skeleton alongside it in a story, what mock data a story should use, or whether a just-finished component needs a story at all. Also use right after creating any new React component to decide whether a story is warranted: on the first component in a project, explain Storybook and ask the user yes/no, record the choice in CLAUDE.md, then honor it for every component after. Do NOT use for general code review, component file placement, hooks, i18n, or repo/CI setup scripts.

Before creating ANY shared/reusable UI primitive in a React codebase (button, input, checkbox, radio, switch, select, textarea, dialog, tooltip, dropdown, badge, card, separator…), search the project's primitive library first to avoid duplicates — reuse or extend what exists; build new only when truly absent. Framework-agnostic (no specific UI or styling library assumed). Activate whenever about to add or hand-roll a reusable field/control/primitive.