{"id":"41dc8613-9d91-4e20-81ca-e644dcf716c7","shortId":"yESQCe","kind":"skill","title":"frontend-component-build","tagline":"Build production-ready frontend components with accessible markup, sensible props, defined states, and tested behavior. Use this skill whenever the user wants to build a component from scratch, refactor an existing one, design a component API, or implement a UI element with prope","description":"# Frontend Component Build\n\nBuild production-ready components. Stack-agnostic principles. Most patterns translate to React, Vue, Svelte, or vanilla web components.\n\nThis skill is about implementing a component well. For broader system design see `design-system`. For day-to-day visual decisions see `design-standards`.\n\n---\n\n## When to use\n\n- Building a new component from scratch\n- Refactoring an existing component\n- Designing a component API (props, slots, events)\n- Adding accessibility to an existing component\n- Implementing a component from a design\n\n## When NOT to use\n\n- Building a full design system (use `design-system`)\n- Page-level design decisions (use `design-standards`)\n- Backend or data work (use `code-review-web`)\n- Performance-only optimization (use `performance-optimization`)\n\n---\n\n## Required inputs\n\n- The component's purpose (what UI need it serves)\n- The design (or willingness to design it)\n- The framework or technical context\n- The states the component must support\n- Accessibility requirements\n\n---\n\n## The framework: 6 dimensions\n\nA complete component handles six dimensions. Skip any one and the component is incomplete.\n\n### 1. Anatomy\n\nIdentify the parts that make up the component before writing any markup.\n\n**Common anatomies:**\n- Button: container + label + (optional) icon + (optional) loading indicator\n- Modal: backdrop + container + header + body + footer + close affordance\n- Form input: label + input + (optional) help text + (optional) error message\n- Card: container + (optional) header + body + (optional) footer + (optional) media\n\nNaming the parts up front makes the API obvious.\n\n### 2. Variants\n\nWhat variations does the component support?\n\n- **Visual variants** (primary, secondary, ghost, danger)\n- **Size variants** (small, medium, large)\n- **Functional variants** (with icon, without icon, icon-only)\n\nVariants should be a managed set, not a free-for-all. Document the supported set; reject requests for new variants without a real use case.\n\n### 3. States\n\nWhat states must the component handle?\n\n- **Default**\n- **Hover** (when pointer is supported)\n- **Focus** (always - keyboard navigation requires it)\n- **Active / pressed**\n- **Disabled**\n- **Loading** (where applicable)\n- **Error** (for inputs, forms, validation-bound components)\n- **Empty** (for components that display data)\n\nEvery state needs visual treatment AND accessibility treatment.\n\n### 4. Props / API\n\nDesign the component's contract.\n\n**API design principles:**\n\n- **Required props minimal.** What's truly needed every time? That's required. Everything else has a sensible default.\n- **Boolean props are red flags.** Three booleans means seven combinations. Prefer enum strings: `variant: \"primary\" | \"secondary\" | \"ghost\"` over `primary={true} ghost={false}`.\n- **Children > props.** Where content is content, accept children. Don't invent `headerText` and `bodyText` props when slots work.\n- **Composition > configuration.** A component that does 5 things via 12 props often should be 5 smaller components.\n- **Type the props.** TypeScript or PropTypes or JSDoc. The type is documentation that won't go out of date.\n\n### 5. Accessibility\n\nBuild it accessible from the start. Adding accessibility later is 5x harder.\n\n**Universal:**\n- Semantic HTML elements (`