Jump to

Skill · Frontend component build

Frontend component build.

A component is not done until it handles all six dimensions.

Build production-ready components from stack-agnostic principles that translate to React, Vue, Svelte, or vanilla web components. A complete component handles six dimensions: anatomy, variants, states, the props API, accessibility, and tests. Skip any one and the component is incomplete.

Accessibility is built in from the start, not bolted on later, because adding it after the fact is several times harder. Semantic HTML comes first, and ARIA only where the markup needs help.

Audience: front-end engineers building a component from scratch, refactoring one, designing a component API, or implementing a reusable UI element from a design.

View the skill on GitHubBrowse the full catalog

The framework

Six dimensions of a complete component.

A complete component handles all six. Each one has a visual side and an accessibility side.

  1. 01Anatomy: name the parts before any markup (a button is container plus label plus optional icon plus optional loading indicator). Naming the parts makes the API obvious.
  2. 02Variants: a managed set, not a free-for-all. Visual, size, and functional variants, documented, with new ones rejected without a real use case.
  3. 03States: default, hover, focus (always), active, disabled, loading, error, and empty. Every state needs both visual and accessibility treatment.
  4. 04Props and API: minimal required props, enum strings over boolean explosion, children over invented text props, composition over configuration, and typed props.
  5. 05Accessibility: semantic HTML first, keyboard navigation with visible focus, 44 by 44px targets, and ARIA only where semantic HTML falls short.
  6. 06Tests: visual regression across variants and states, automated accessibility checks, keyboard navigation, component logic, and integration in real parents.

How the skill runs

Ten steps from use case to documented component.

The skill names the parts, designs the contract, builds with semantic HTML, and proves the component works before declaring it done.

  1. 01

    Understand the use case

    What UI need the component serves, where it appears, and which components sit next to it.

  2. 02

    Sketch the anatomy

    Name the parts that make up the component.

  3. 03

    List variants and states

    Match the design system, or define new variants and states where there is a real need.

  4. 04

    Design the API

    Required props, optional props, children, and events, all typed.

  5. 05

    Build the markup with semantic HTML

    Choose the right elements; avoid a generic div for anything interactive.

  6. 06

    Style with tokens

    No hardcoded colors, spacing, or sizes.

  7. 07

    Add interaction

    Focus management, keyboard handlers, and ARIA where semantic HTML needs help.

  8. 08

    Add states

    Hover, focus, active, disabled, loading, and error, each with visual and accessibility treatment.

  9. 09

    Test

    Automated accessibility, keyboard navigation, and visual regression at minimum.

  10. 10

    Document

    Usage, the API, examples, and the anti-patterns that say when not to reach for it.

Reference files

Three references that go alongside the SKILL.md.

  • references/component-spec-template.md

    A template for documenting a component (props, states, accessibility, edge cases) before building it.

  • references/component-api-patterns.md

    Patterns for flexible component APIs: compound components, controlled versus uncontrolled, the polymorphic as prop, render props, and slots.

  • references/accessibility-patterns.md

    ARIA patterns for common interactive components, anchored to the semantic-HTML-first principle.

Browse all reference files on GitHub

Bridges to other skills

Where the component sits in the bigger picture.

Implementing one component is this skill's lane. These cover the system around it and the work beyond the UI.

  • The system

    design-system

    Decides which components exist and how they relate across the product. This skill implements one of them well.

  • Page-level design

    design-standards

    Page-level design decisions (hierarchy, spacing, mobile rules) are a design-standards job. This skill handles the component's own architecture.

  • Backend and data

    code-review-web

    Backend and data work beyond the component sits with code review. Component build stops at the UI boundary.

  • Performance

    performance-optimization

    When the work is performance-only (bundle size, render cost, Core Web Vitals), reach for the dedicated performance skill.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.mdBrowse the full catalog

Frequently asked questions.

What are the six dimensions of a complete component?
Anatomy (name the parts before writing markup), variants (a managed set, not a free-for-all), states (every state the component must handle), props and API (the component's contract), accessibility (built in from the start), and tests (proof it works). Skip any one and the component is incomplete: a component with no error state, no focus treatment, or no accessibility test is not finished.
What states must a component handle?
Default, hover (where a pointer is supported), focus (always, because keyboard navigation requires it), active or pressed, disabled, loading where applicable, error for inputs and validation-bound components, and empty for components that display data. Every state needs both a visual treatment and an accessibility treatment: a disabled button should look disabled, carry aria-disabled, and not respond to clicks; a loading state should announce through aria-live so screen readers know something changed.
Why are boolean props a red flag?
Three booleans imply seven combinations to reason about and test. Prefer enum strings such as variant: 'primary' | 'secondary' | 'ghost' over primary={true} ghost={false}. Keep required props minimal so everything else has a sensible default, accept children where content is content rather than inventing headerText and bodyText props, and prefer composition over configuration: a component that does five things through twelve props often should be five smaller components.
How much accessibility belongs in the component?
All of it, from the start, because adding accessibility later is several times harder. Use semantic HTML first: a real button element, not a div with an onClick that loses keyboard support and screen reader semantics. Make it keyboard navigable with visible focus, give interactive targets at least 44 by 44px, and reach for ARIA only where semantic HTML is insufficient, because made-up ARIA is worse than none. A component without at least automated accessibility testing is not done.
How is this different from design-system and design-standards?
Design-system decides which components exist and how they relate across the product. Design-standards makes the page-level design decisions: hierarchy, spacing, mobile rules. Frontend-component-build implements a single component well, with its anatomy, variants, states, typed API, accessibility, and tests. Use it when the task is building or refactoring one component, not designing the library or laying out a page.
What does a complete component delivery include?
The component code in the appropriate framework; a Storybook (or equivalent) entry showing every variant and state; documentation covering the anatomy, a props and API table, usage examples from basic to edge cases, when to use it versus an alternative, anti-patterns, and accessibility notes; and tests spanning visual regression, automated accessibility, and component logic. Documentation is part of the delivery, because a component the next maintainer cannot understand is one they cannot safely use.