Component Inspiration Registry
Goal
Make UI work reusable and memorable by organizing components as variants, patterns, and showcases instead of one-off generic sections.
When to use
Use for component libraries, landing-page sections, animated UI components, shadcn-style registries, pattern collections, design systems, or reusable client project blocks.
Workflow
- Inspect existing components, folders, naming patterns, and styling conventions.
- Identify whether the request needs a single component, a family of variants, or a showcase/registry pattern.
- Define the component contract: props, variants, slots, data shape, responsive behavior, and accessibility expectations.
- Create visual variation through layout, density, motion, texture, masks, imagery, or states, not random decoration.
- Keep examples realistic and aligned with the project brand instead of generic placeholder content.
- Avoid copying external libraries directly; use them as inspiration and implement within the project style system.
- Document usage when the component is intended for reuse.
Quality bar
- Run lint/type/build or the project equivalent.
- Verify at least one realistic usage example if practical.
- Check accessibility basics for interactive components.
Validation
- Components are reusable, typed, and composable.
- Variants are meaningful, not duplicate copies with tiny style changes.
- Showcases help future work move faster without creating template-looking UI.
Final response
- Summarize component contract, variants created, and how to reuse them.
1---2name: component-inspiration-registry3description: Use this when creating reusable frontend component systems, inspiration libraries, variants, showcases, design sections, animated components, or UI pattern registries.4---56# Component Inspiration Registry78## Goal910Make UI work reusable and memorable by organizing components as variants, patterns, and showcases instead of one-off generic sections.1112## When to use1314Use for component libraries, landing-page sections, animated UI components, shadcn-style registries, pattern collections, design systems, or reusable client project blocks.1516## Workflow17181. Inspect existing components, folders, naming patterns, and styling conventions.192. Identify whether the request needs a single component, a family of variants, or a showcase/registry pattern.203. Define the component contract: props, variants, slots, data shape, responsive behavior, and accessibility expectations.214. Create visual variation through layout, density, motion, texture, masks, imagery, or states, not random decoration.225. Keep examples realistic and aligned with the project brand instead of generic placeholder content.236. Avoid copying external libraries directly; use them as inspiration and implement within the project style system.247. Document usage when the component is intended for reuse.2526## Quality bar2728- Run lint/type/build or the project equivalent.29- Verify at least one realistic usage example if practical.30- Check accessibility basics for interactive components.3132## Validation3334- Components are reusable, typed, and composable.35- Variants are meaningful, not duplicate copies with tiny style changes.36- Showcases help future work move faster without creating template-looking UI.3738## Final response3940- Summarize component contract, variants created, and how to reuse them.
YankielDBC2