- Home
- Skills
- Maxritter
- Pilot Shell
- Standards Components
standards-components_skill
- 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.