| name | component-gallery |
| description | Research UI component patterns across 60 component types and 95 production design systems (2,676+ examples from component.gallery). Compare implementations, find alternative component names, ground frontend decisions in real-world precedent. Pairs with minoan-frontend-design for research-then-build workflows. Triggers on component patterns, how do others implement X, design system research, component comparison. |
| allowed-tools | Bash(component-gallery:*), Read, Grep, Glob |
Component Gallery — Pattern Research via Local RAG
Research real component implementations before building. The gap between "I'll make a sidebar" and "here's how Atlassian, Shopify, and GitHub each solved sidebar navigation" is the gap between guessing and grounding. This skill bridges it.
Philosophy
Every UI component has been built thousands of times. The best implementations share patterns that no single designer invented—they emerged from convergent problem-solving across design systems with different constraints. Studying these patterns before writing code prevents reinventing solved problems, surfaces accessibility requirements that are easy to miss, and reveals implementation trade-offs that only become visible when comparing multiple approaches side by side.
Pattern research is not copying. It is the equivalent of a literature review before writing a paper. Build with awareness of what exists, then make deliberate choices about what to keep, adapt, or reject.
Quick Reference — Static Indexes
Read these files directly for fast lookup. No RAG query needed.
| File | Contents |
|---|
references/component-index.md | All 60 component types with alt names, example counts, descriptions |
references/design-system-index.md | All 95 design systems with org, tech stack, features, links |
references/component-taxonomy.md | Components grouped by functional category (Forms, Navigation, Feedback, Layout, Data Display, Actions) |
For a quick answer to "what is this component called?" or "which design systems use React?"—read the index files. Reserve RAG queries for deeper questions.
RAG Query — Semantic Search
Query the component-gallery RLAMA collection for implementation details, cross-system comparisons, and pattern analysis.
python3 ~/.claude/skills/component-gallery/scripts/query.py "how do design systems implement date picker accessibility"
python3 ~/.claude/skills/component-gallery/scripts/query.py "compare sidebar navigation patterns"
python3 ~/.claude/skills/component-gallery/scripts/query.py "components for progressive disclosure of complex forms"
python3 ~/.claude/skills/component-gallery/scripts/query.py "flyout panel slide from edge"
python3 ~/.claude/skills/component-gallery/scripts/query.py "responsive table patterns" -k 20
Default retrieve-only mode returns raw chunks for Claude to synthesize. This produces stronger analysis than local model generation.
Workflow Protocol — Pairing with minoan-frontend-design
Component Gallery provides the what (pattern research, implementation precedent, accessibility requirements). Minoan Frontend Design provides the how (creative direction, typography, color, spatial composition, craft standards).
Research-then-build sequence
- Identify components needed. Read
references/component-index.md to confirm the component type exists and find its canonical name.
- Query for implementation patterns. Use RAG to retrieve how 3-5 design systems approach the component—focus on structure, states, accessibility, and responsive behavior.
- Synthesize findings. Identify convergent patterns (things most systems agree on) and divergent choices (where systems differ based on context).
- Build with minoan-frontend-design. Apply creative direction from the design skill. The component's structure is informed by research; its aesthetic is informed by the design skill.
- Verify accessibility. Cross-reference research findings against the implementation. Confirm ARIA roles, keyboard navigation, focus management, and screen reader announcements.
When to skip research
For trivial components (a single button, a text input) where the implementation is well-understood and creative direction is the primary concern, invoke minoan-frontend-design directly. Reserve component-gallery queries for components with meaningful structural complexity: data tables, date pickers, command palettes, multi-step forms, sidebar navigation, filterable lists.
Maintenance
python3 ~/.claude/skills/component-gallery/scripts/ingest.py --full
python3 ~/.claude/skills/component-gallery/scripts/ingest.py --rebuild-rag
python3 ~/.claude/skills/component-gallery/scripts/build_indexes.py
3D / WebGL Inspiration — mesh3d.gallery
For 3D interactive web experiences, query mesh3d.gallery — a curated directory of 207+ WebGL/Three.js/Spline websites, hand-picked by human curators. Filterable by technology, maker, and tags.
python3 ~/.claude/skills/component-gallery/scripts/fetch_mesh3d.py --tech "Three.js"
python3 ~/.claude/skills/component-gallery/scripts/fetch_mesh3d.py --maker "Lusion"
python3 ~/.claude/skills/component-gallery/scripts/fetch_mesh3d.py --search "portfolio"
See references/mesh3d-gallery.md for the full reference. Use component-gallery for 2D UI patterns, mesh3d.gallery for 3D interaction patterns.
Anti-Patterns
Guessing component structure. Never invent a component's ARIA pattern, keyboard behavior, or state machine from first principles when the collection contains documented patterns from production design systems. Query first.
Skipping accessibility review. Every component query should include or be followed by an accessibility check. The most common failure mode is building a visually correct component that is inaccessible to keyboard and screen reader users.
Treating examples as templates. Design system examples document their constraints (Shopify's Polaris serves commerce, Atlassian's ADS serves enterprise collaboration). Extract the structural pattern, not the specific aesthetic. The aesthetic comes from minoan-frontend-design.
Over-querying for simple components. A styled button does not need a five-system comparison. Match query depth to component complexity.
Ignoring responsive behavior. Desktop-only component research misses half the problem. Query explicitly for responsive patterns when the component will appear on mobile.
