Component Library

Name: Component Library
Author: aneja5

Use when building a component catalog, when standardizing component props and states across a product, when two engineers are about to build competing versions of the same component, or before a major UI build sprint.

aneja5 1688aa3 7.0 KB Updated Sep 17, 2026

Web & Frontend

Install

Press C to copy

$ npx skillmds@latest add aneja5/component-library

Installs into ~/.claude/skills (or .claude/skills inside a project). Restart Claude Code to pick it up.

Download SKILL.md

＋ Add to collection

README badge

[![SkillMD](https://skillmd.com/badge/aneja5/component-library.svg)](https://skillmd.com/skills/aneja5/component-library)

Trust & safety

Audits pending

Not yet audited · commit 1688aa3

Works with: Claude Code Claude.ai OpenAI Codex +

File contents

Component Library

Overview

Catalog every component the product needs before the build sprint — props, states, responsive behavior, accessibility, composition rules, and microcopy. Output is .forge/component-library.md. Inherits tokens from design-system, behaviors from interaction-patterns, and voice + icons from brand-and-identity. Consumed by page-composition, data-visualization, and every UI build task.

When to Use

A major UI build sprint is starting and no component catalog exists
Two engineers are about to build a Button / Card / Modal independently
The codebase has 3 different Button components with different APIs
A new domain-specific component (ScoreCard, RepCard, CallTimeline) is being designed
A redesign is replacing shadcn defaults with domain-shaped components

When NOT to Use

A single one-off component for one screen — incremental-implementation
Backend-only services
The product genuinely doesn't have a UI yet — establish design-system and interaction-patterns first

Common Rationalizations

Thought	Reality
"We'll extract components as we go"	Extraction after the fact means 3 versions of `Button` with different APIs. Catalog first, build once.
"This is premature abstraction"	A component catalog is not abstraction. It's a vocabulary. You define words before writing sentences.
"Just use shadcn and move on"	shadcn gives generic components. `ScoreCard`, `RepCard`, `CallTimeline` are domain-specific — those need defining.
"Props can evolve"	Props that evolve without a catalog diverge. One engineer adds `size`, another adds `isLarge`. The catalog prevents this.
"We don't need a loading state for that component"	Every async component lies about readiness without a loading state.

Red Flags

Two components doing the same job under different names (Button and ActionButton, Card and Panel)
A component with 15+ props — it's two components fused
A component without a loading or empty state
Hardcoded strings inside a component instead of prop-driven microcopy
No accessibility attributes (role, aria-*) on interactive components
A component accepting className as a token-override escape hatch

Core Process

Step 1: Read upstream artifacts

Read .forge/design-system.md (tokens, spacing, motion, breakpoints), .forge/interaction-patterns.md (behaviors per shape), .forge/brand-identity.md (voice + icon system). The catalog inherits from these. If any are missing, run them first — building the catalog without them encodes accidents as decisions.

Step 2: Inventory — what the product actually needs

List every component the product needs. Group by category. Only include what's used. Generic libraries rot fast.

Category	Components
Layout	Container, Grid, Stack, Divider
Navigation	Navbar, Sidebar, Tabs, Breadcrumb, BottomNav
Feedback	Toast, Alert, Badge, Progress, Skeleton
Input	TextField, Select, Checkbox, Radio, Toggle, DatePicker, Search
Display	Card, Table, List, Avatar, Chip, Tooltip, EmptyState
Overlay	Modal / BottomSheet, Drawer, Popover, DropdownMenu
Data	Chart, Metric, ScoreCard, Timeline, Heatmap

Domain-specific components (e.g., ScoreCard, RepCard, CallTimeline) are first-class catalog entries, not afterthoughts.

Step 3: Define each component

For every component, document:

Props — name, type, default, required. Be specific: variant: 'primary' | 'secondary' | 'ghost', never style: object.
All 6 states — default / hover / active or pressed / disabled / loading / error. Loading is skeleton or spinner per interaction-patterns.
Responsive behavior — what changes at each breakpoint from design-system (size, layout, density, hidden affordances).
Accessibility — role, ARIA attributes, keyboard interaction, focus behavior, screen-reader narration where non-obvious.
Composition rules — what nests inside what. "Card contains CardHeader + CardBody + CardFooter. CardHeader contains title + optional action."
Microcopy — default labels per brand-identity voice. Empty state text. Error text. Placeholder text. Microcopy is prop-driven, never hardcoded.

Step 4: Naming and file conventions

Naming: PascalCase. Multi-product repos use a product prefix (MgrScoreCard, RepScoreCard) only when behavior differs; identical components stay shared.
File structure: one component per file; co-located styles (.tsx + .module.css or equivalent); co-located tests (Component.test.tsx); co-located stories (Component.stories.tsx) if Storybook is used.
Export rule: named exports only; no default exports (default exports break grep and rename).

Step 5: Anti-patterns to document

State the forbidden patterns explicitly in the catalog:

<div> — use a Button with the ghost variant


A Card doing its own data fetching — data flows in via props, not internals
Components accepting className for token overrides — leaks the design system
A loading prop AND a separate isLoading prop — pick one name product-wide
A Modal that takes a children and a content prop — choose composition or content, not both


Step 6: Write .forge/component-library.md
Section order: upstream-read confirmation, inventory by category, per-component specs, naming + file conventions, anti-patterns. Prepend a forge:meta header (generated_by: component-library, generated_at: <ISO 8601 UTC with Z>, depends_on: [.forge/design-system.md, .forge/interaction-patterns.md, .forge/brand-identity.md] — paths only, never hashes, generated_from: {.forge/design-system.md: <hash>, .forge/interaction-patterns.md: <hash>, .forge/brand-identity.md: <hash>} — each upstream's content_hash AT generation time, content_hash: <sha256 first 8 of THIS file's body>).
Verification

 All three upstream artifacts read (or noted absent and the gap accepted)
 Every component has all 6 states defined (default / hover / active / disabled / loading / error)
 Every prop has a type — no any, no object without a typed schema
 Every component has responsive behavior documented per breakpoint
 Every interactive component has accessibility attributes (role, ARIA, keyboard, focus)
 No two components overlap in purpose (Button ≠ ActionButton)
 Domain-specific components (ScoreCard, RepCard, CallTimeline, etc.) are included, not deferred
 Microcopy is prop-driven — no hardcoded strings inside components
 Anti-patterns section is non-empty and specific
 .forge/component-library.md written with forge:meta header

   1---2name: component-library3description: Use when building a component catalog, when standardizing component props and states across a product, when two engineers are about to build competing versions of the same component, or before a major UI build sprint.4---56# Component Library78## Overview910Catalog every component the product needs *before* the build sprint — props, states, responsive behavior, accessibility, composition rules, and microcopy. Output is `.forge/component-library.md`. Inherits tokens from `design-system`, behaviors from `interaction-patterns`, and voice + icons from `brand-and-identity`. Consumed by `page-composition`, `data-visualization`, and every UI build task.1112## When to Use1314- A major UI build sprint is starting and no component catalog exists15- Two engineers are about to build a `Button` / `Card` / `Modal` independently16- The codebase has 3 different `Button` components with different APIs17- A new domain-specific component (`ScoreCard`, `RepCard`, `CallTimeline`) is being designed18- A redesign is replacing shadcn defaults with domain-shaped components1920## When NOT to Use2122- A single one-off component for one screen — `incremental-implementation`23- Backend-only services24- The product genuinely doesn't have a UI yet — establish `design-system` and `interaction-patterns` first2526## Common Rationalizations2728| Thought | Reality |29|---------|---------|30| "We'll extract components as we go" | Extraction after the fact means 3 versions of `Button` with different APIs. Catalog first, build once. |31| "This is premature abstraction" | A component catalog is not abstraction. It's a vocabulary. You define words before writing sentences. |32| "Just use shadcn and move on" | shadcn gives generic components. `ScoreCard`, `RepCard`, `CallTimeline` are domain-specific — those need defining. |33| "Props can evolve" | Props that evolve without a catalog diverge. One engineer adds `size`, another adds `isLarge`. The catalog prevents this. |34| "We don't need a loading state for that component" | Every async component lies about readiness without a loading state. |3536## Red Flags3738- Two components doing the same job under different names (`Button` and `ActionButton`, `Card` and `Panel`)39- A component with 15+ props — it's two components fused40- A component without a `loading` or `empty` state41- Hardcoded strings inside a component instead of prop-driven microcopy42- No accessibility attributes (`role`, `aria-*`) on interactive components43- A component accepting `className` as a token-override escape hatch4445## Core Process4647### Step 1: Read upstream artifacts4849Read `.forge/design-system.md` (tokens, spacing, motion, breakpoints), `.forge/interaction-patterns.md` (behaviors per shape), `.forge/brand-identity.md` (voice + icon system). The catalog inherits from these. If any are missing, run them first — building the catalog without them encodes accidents as decisions.5051### Step 2: Inventory — what the product actually needs5253List every component the product needs. Group by category. **Only include what's used.** Generic libraries rot fast.5455| Category | Components |56|---|---|57| Layout | Container, Grid, Stack, Divider |58| Navigation | Navbar, Sidebar, Tabs, Breadcrumb, BottomNav |59| Feedback | Toast, Alert, Badge, Progress, Skeleton |60| Input | TextField, Select, Checkbox, Radio, Toggle, DatePicker, Search |61| Display | Card, Table, List, Avatar, Chip, Tooltip, EmptyState |62| Overlay | Modal / BottomSheet, Drawer, Popover, DropdownMenu |63| Data | Chart, Metric, ScoreCard, Timeline, Heatmap |6465Domain-specific components (e.g., `ScoreCard`, `RepCard`, `CallTimeline`) are **first-class catalog entries**, not afterthoughts.6667### Step 3: Define each component6869For every component, document:7071- **Props** — name, type, default, required. Be specific: `variant: 'primary' | 'secondary' | 'ghost'`, never `style: object`.72- **All 6 states** — `default / hover / active or pressed / disabled / loading / error`. Loading is skeleton or spinner per `interaction-patterns`.73- **Responsive behavior** — what changes at each breakpoint from `design-system` (size, layout, density, hidden affordances).74- **Accessibility** — `role`, ARIA attributes, keyboard interaction, focus behavior, screen-reader narration where non-obvious.75- **Composition rules** — what nests inside what. *"`Card` contains `CardHeader` + `CardBody` + `CardFooter`. `CardHeader` contains title + optional action."*76- **Microcopy** — default labels per `brand-identity` voice. Empty state text. Error text. Placeholder text. Microcopy is prop-driven, never hardcoded.7778### Step 4: Naming and file conventions7980- **Naming:** PascalCase. Multi-product repos use a product prefix (`MgrScoreCard`, `RepScoreCard`) only when behavior differs; identical components stay shared.81- **File structure:** one component per file; co-located styles (`.tsx` + `.module.css` or equivalent); co-located tests (`Component.test.tsx`); co-located stories (`Component.stories.tsx`) if Storybook is used.82- **Export rule:** named exports only; no default exports (default exports break grep and rename).8384### Step 5: Anti-patterns to document8586State the forbidden patterns explicitly in the catalog:8788- `<div onClick={...}>` — use a `Button` with the `ghost` variant89- A `Card` doing its own data fetching — data flows in via props, not internals90- Components accepting `className` for token overrides — leaks the design system91- A `loading` prop AND a separate `isLoading` prop — pick one name product-wide92- A `Modal` that takes a `children` *and* a `content` prop — choose composition or content, not both9394### Step 6: Write `.forge/component-library.md`9596Section order: upstream-read confirmation, inventory by category, per-component specs, naming + file conventions, anti-patterns. Prepend a `forge:meta` header (`generated_by: component-library`, `generated_at: <ISO 8601 UTC with Z>`, `depends_on: [.forge/design-system.md, .forge/interaction-patterns.md, .forge/brand-identity.md]` — paths only, never hashes, `generated_from: {.forge/design-system.md: <hash>, .forge/interaction-patterns.md: <hash>, .forge/brand-identity.md: <hash>}` — each upstream's content_hash AT generation time, `content_hash: <sha256 first 8 of THIS file's body>`).9798## Verification99100- [ ] All three upstream artifacts read (or noted absent and the gap accepted)101- [ ] Every component has all 6 states defined (`default / hover / active / disabled / loading / error`)102- [ ] Every prop has a type — no `any`, no `object` without a typed schema103- [ ] Every component has responsive behavior documented per breakpoint104- [ ] Every interactive component has accessibility attributes (`role`, ARIA, keyboard, focus)105- [ ] No two components overlap in purpose (`Button` ≠ `ActionButton`)106- [ ] Domain-specific components (`ScoreCard`, `RepCard`, `CallTimeline`, etc.) are included, not deferred107- [ ] Microcopy is prop-driven — no hardcoded strings inside components108- [ ] Anti-patterns section is non-empty and specific109- [ ] `.forge/component-library.md` written with `forge:meta` header

  aneja5/forge-skills/tree/main/skills/component-library commit 1688aa30f2 
   Related skills
 Browse category 
     Web Artifacts Builder 158k 
 anthropic
 Creates elaborate, multi-component HTML artifacts using React, Tailwind CSS, and shadcn/ui for complex frontend projects.
  
   Senior Frontend 20.4k 
 alirezarezvani·Audited
 Scaffold Next.js/React projects, generate components, analyze bundle sizes, and apply React/Next.js optimization patterns.
  
   Senior Fullstack 20.4k 
 alirezarezvani·Audited
 Scaffolds fullstack projects (Next.js, FastAPI, MERN, Django) and analyzes code quality with security and complexity scoring.
  
   Md Document 20.4k 
 alirezarezvani·Audited
 Converts long-form markdown documents (specs, RFCs, reports, plans) into a single-file HTML page with sticky table of contents, scrollspy, search filter, code-copy buttons, and customizable design tokens.
  
   Md Slides 20.4k 
 alirezarezvani·Audited
 Converts a markdown deck into a single-file HTML presentation with keyboard navigation, presenter mode, and print-to-PDF support.
  
   Browser Automation 20.4k 
 alirezarezvani
 Automate browser tasks, scrape websites, fill forms, capture screenshots, and extract structured data from web pages using Playwright.
  
 
 
  Frequently asked questions
     
 Run npx skillmds@latest add aneja5/component-library in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
 
   
 Use when building a component catalog, when standardizing component props and states across a product, when two engineers are about to build competing versions of the same component, or before a major UI build sprint. It is listed under Web & Frontend on SkillMD.
 
   
 This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
 
   
 This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
 
   
 Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
 
   
 aneja5 (@aneja5) published this skill. Their other Agent Skills are listed on their SkillMD profile.

   npx skillmds@latest add aneja5/component-library

Component Library

File contents

Component Library

Overview

When to Use

When NOT to Use

Common Rationalizations

Red Flags

Core Process

Step 1: Read upstream artifacts

Step 2: Inventory — what the product actually needs

Step 3: Define each component

Step 4: Naming and file conventions

Step 5: Anti-patterns to document

Step 6: Write .forge/component-library.md

Verification

Related skills

Frequently asked questions

How do I install the Component Library skill?

What does the Component Library skill do?

Is Component Library safe to use?

Which AI agents work with Component Library?

Is Component Library free to use?

Who published Component Library?

Step 6: Write `.forge/component-library.md`