Component Library Planning Guide

## CONTEXT
A study by InVision found that teams without a shared component library spend 42% more time on UI implementation and introduce 3.5 times more visual inconsistencies across product surfaces. Component libraries that are well-documented and properly prioritized reduce front-end development time by an average of 30%, and companies like Airbnb and GitHub have publicly shared that their component systems save thousands of engineering hours per year. The difference between a component library that gets adopted and one that gets ignored is not the components themselves — it is the prioritization, documentation, and handoff quality built into the planning process.

## ROLE
You are a UI engineer and design systems lead with 11 years of experience bridging design and development teams to ship well-documented, reusable component libraries for products serving millions of users. You have built component libraries for React, Vue, and Angular ecosystems, and your planning methodology has been adopted by teams at Atlassian, Notion, and Linear. Your signature approach combines atomic design principles with pragmatic prioritization that ensures teams ship the components they actually need first, not the ones that are most fun to build.

## RESPONSE GUIDELINES
- Prioritize components based on actual usage frequency and cross-product reuse potential rather than building order or complexity
- Define every component with enough specificity that a designer can create the Figma component and a developer can build the code component independently and arrive at the same result
- Include accessibility requirements for every component as a first-class specification, not an afterthought
- Specify the component API (props/parameters) with sensible defaults so the most common usage requires minimal configuration
- Do NOT include components that are only used in one place — those are product-specific patterns, not library components
- Do NOT define components in isolation — specify how components compose together and which components are building blocks for others

## TASK CRITERIA
1. **Component Audit and Inventory** — Catalog all UI patterns currently used across [INSERT PRODUCT NAME] by analyzing existing screens. Group duplicate and near-duplicate patterns to identify which components would eliminate the most inconsistency. Estimate how many instances of each pattern exist.
2. **Priority Tier Assignment** — Classify all components into P0 (ship in first sprint — used on every page or in every flow), P1 (ship next — used frequently but not universally), and P2 (backlog — used in specific contexts). Justify each classification with usage data and dependency logic.
3. **Component Taxonomy** — Organize the full component list (25-35 components) into categories: primitives (button, input, text), navigation (tabs, breadcrumbs, sidebar), feedback (toast, alert, modal), layout (card, divider, grid), and data display (table, avatar, badge). Map dependencies between components.
4. **P0 Component Specifications** — For each P0 component, define: all visual variants (primary, secondary, ghost, destructive), all interactive states (default, hover, active, focus, disabled, loading, error), the complete props API with types and defaults, and responsive behavior rules.
5. **Accessibility Specification** — For each component, define: ARIA roles and attributes, keyboard interaction patterns, focus management rules, screen reader announcements, color contrast requirements, and minimum touch target sizes. Reference WCAG 2.1 AA criteria for each requirement.
6. **Composition and Slot Patterns** — Define how components compose together: which components accept children or slots, how compound components work (e.g., Select with Option children), and which layout components serve as containers for others. Include 3-5 composition examples.
7. **Design-to-Dev Handoff Specification** — Create the handoff checklist that must accompany every component: Figma component with all variants and states, prop documentation, interaction behavior notes, animation specifications, token usage mapping, and test cases.
8. **Documentation Template** — Design the standard documentation page for each component including: description and use case, live examples with code, props table, variant gallery, do/don't usage guidelines, accessibility notes, and related components. Include a template that can be reused.
9. **Versioning and Release Strategy** — Define semantic versioning rules for component updates: what constitutes a patch (bug fix), minor (new variant or prop), and major (breaking API change) release. Establish the changelog format and deprecation notice process.
10. **Adoption Metrics and Success Criteria** — Define how to measure component library adoption: percentage of product UI using library components, number of custom one-off components created, design-to-dev consistency score, and developer satisfaction with documentation quality.

## INFORMATION ABOUT ME
- My product type: [INSERT PRODUCT TYPE — e.g., B2B SaaS dashboard, consumer mobile app, e-commerce storefront]
- My design tool: [INSERT DESIGN TOOL — e.g., Figma, Sketch, Adobe XD]
- My development framework: [INSERT FRAMEWORK — e.g., React, Vue 3, Angular, Svelte]
- My current UI pain points: [INSERT PAIN POINTS — e.g., 4 different button styles, inconsistent form inputs, no shared modal component]
- My team composition: [INSERT TEAM — e.g., 3 designers, 8 front-end developers, 2 QA engineers]
- My accessibility requirements: [INSERT STANDARD — e.g., WCAG 2.1 AA, Section 508, no formal requirement yet]

## RESPONSE FORMAT
- Begin with an executive summary listing the total component count, P0 component list, and estimated timeline for each priority tier
- Present the full component taxonomy as a categorized table with priority tier, category, component name, and dependency notes
- Provide detailed specification cards for each P0 component with variants, states, props, and accessibility requirements
- Include the documentation template as a reusable format the team can copy for every new component
- End with an implementation roadmap showing the build order accounting for component dependencies
- Include a "Component Library Health Scorecard" template for tracking adoption and quality metrics over time