standards-components_skill

This skill guides building reusable, single-responsibility UI components with clear interfaces and composition for scalable frontend development.
  • TypeScript

419

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill maxritter/pilot-shell --skill standards-components

  • SKILL.md10.1 KB

Overview

This skill guides creation and refactoring of reusable, composable UI components that follow the single responsibility principle, explicit interfaces, and minimal props. It applies across frameworks (React, Vue, Svelte, Web Components) and common component file types (.jsx, .tsx, .vue, .svelte). Use it to make components easier to test, maintain, and compose into larger UIs.

How this skill works

The skill inspects component boundaries, prop shapes, state placement, and composition patterns. It recommends splitting multi-responsibility components, grouping related props, providing sensible defaults, and keeping implementation details encapsulated. It also enforces TypeScript interfaces or prop types, documentation examples, and testing requirements.

When to use it

  • Creating new component files (.jsx, .tsx, .vue, .svelte) in components/, src/components/, ui/, lib/
  • Modifying existing components to improve reusability or readability
  • Defining component props, interfaces, or default values
  • Implementing composition patterns (Card.Header, Card.Body, etc.) instead of heavy configuration props
  • Deciding where component-level state should live or when to lift state
  • Refactoring monolithic components into smaller focused pieces

Best practices

  • One responsibility per component; if you need “and” in the description, split it
  • Prefer composition over configuration; build complex UIs by composing focused parts
  • Keep props minimal (aim <7); group related props into objects when needed
  • Define explicit TypeScript interfaces or PropTypes and provide sensible defaults
  • Encapsulate internal state and implementation details; expose only necessary API
  • Write tests for default rendering, variations, interactions, and error states

Example use cases

  • Split a 400-line UserDashboard into UserProfile, UserSettings, NotificationPanel, and ActivityFeed
  • Refactor a configurable Card with many boolean props into a Card with Card.Header, Card.Body, Card.Footer subcomponents
  • Design a Button component with a ButtonProps interface, sensible defaults, and tests for click and disabled states
  • Replace deep prop drilling by providing context for shared data (user, theme) to inner components
  • Group styling-related props into a single colors object instead of multiple color props

FAQ

Keep state local if only the component needs it. Lift state when multiple sibling components require the same data. Use context or a store when unrelated parts of the app need access.

How do I know a component is too big?

If it exceeds ~200–300 lines, has multiple responsibilities, or is hard to test, split it into smaller focused components.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational