component-scaffold

name	component-scaffold
description	Use when creating, updating, reviewing, or debugging UI components, pages, forms, layouts, responsive behavior, accessibility, component states, or design-system usage.

Component Scaffold

Use this skill for accessible, responsive, maintainable UI components.

Rules

• Follow the project’s existing frontend framework, folder structure, naming, and styling patterns.
• Inspect similar components before creating new ones.
• Do not add a new UI library, styling system, state library, animation library, or form library unless already used or explicitly requested.
• Reuse existing shared components, hooks, utilities, and design tokens.
• Keep components small, focused, and composable.
• Handle loading, error, empty, success, disabled, and pending states when relevant.
• Use semantic HTML.
• Support keyboard navigation.
• Provide visible focus states.
• Keep layouts responsive.
• Preserve existing dark mode, spacing, typography, colors, and design system rules.
• Avoid unrelated refactors.

Inspect First

Before changing UI code, check existing patterns for:

• component structure
• styling system
• design system
• forms
• state management
• data fetching
• loading/error/empty states
• responsive behavior
• accessibility
• tests

Implementation Checklist

• Identify the component/page purpose.
• Choose the correct file location.
• Define clear props and data needs.
• Reuse existing UI primitives.
• Implement only the required behavior.
• Add relevant states.
• Make it responsive.
• Add accessibility support.
• Keep API/actions/mutations in the project’s existing layer.
• Add or update tests if the project has them.

Accessibility Rules

• Use real buttons, links, labels, forms, headings, and landmarks where appropriate.
• Do not use clickable div or span when a semantic element fits.
• Every form control needs an accessible label.
• Icons-only buttons need accessible names.
• Interactive elements must work with keyboard.
• Do not remove focus outlines unless replacing them with a visible focus style.
• Use ARIA only when semantic HTML is not enough.
• Keep contrast readable.

Responsive Rules

• Follow existing breakpoints and layout conventions.
• Avoid fixed widths that break mobile.
• Prevent overlapping controls.
• Keep tap targets usable.
• Avoid unwanted horizontal scrolling.
• Preserve readability on small screens.

Form Rules

• Use the project’s existing form and validation pattern.
• Show clear validation errors.
• Prevent duplicate submissions.
• Show submitting/pending state.
• Preserve user input after validation failure.
• Do not rely only on client-side validation for server changes.

Security Rules

• Do not expose admin-only actions without server-side protection.
• Do not leak sensitive data into UI state, logs, or client-visible props.
• Keep destructive actions clear and guarded.
• Show safe user-facing errors only.

Tests

Cover relevant paths:

• render
• loading state
• empty state
• error state
• user interaction
• form validation
• disabled/pending state
• accessibility basics
• responsive behavior when relevant