--- name: component-generator description: "Generates complete design system component documentation including a component description, anatomy breakdown, usage guidelines (do's and don'ts), a full props API table, accessibility requirements, states specification, and a variant matrix. Use when documenting a new component, standardizing an existing one, or building out a design system's component library reference." argument-hint: "[component-name] [framework]" allowed-tools: ["Read"] --- # Component Generator ## Purpose Produce complete, implementation-ready documentation for a single design system component — description, anatomy, usage rules, props API, states, accessibility, and variants — so designers and engineers work from one authoritative spec instead of scattered Figma comments and tribal knowledge. ## When to Use Invoke this skill when the user asks to: - Document a new component being added to the design system - Standardize or backfill documentation for an existing component - Generate a props/API table for a component's implementation - Write usage guidelines (do's and don'ts) for a component - Define the states, variants, or accessibility requirements for a component - Build out entries for a component library reference site or Storybook ## Inputs Required Before starting, collect: - **Component name**: The name of the component (e.g., Button, Toast, Combobox) - **Component purpose**: What it does and the problem it solves for users - **Framework/target**: React, Vue, Web Components, Swift, plain HTML/CSS, or design-only - **Known variants**: Visual or behavioral variants that exist (e.g., primary/secondary, sizes) - **Known states**: Interactive states to support (default, hover, focus, disabled, loading, etc.) - **Design tokens/naming convention**: Prop naming style (camelCase, kebab, boolean prefixes) and any token references - **Accessibility target**: WCAG level (AA default) and any known patterns (e.g., ARIA combobox) If framework or accessibility target is missing, default to React with camelCase props and WCAG 2.1 AA, and note the assumption. ## Instructions ### Step 1: Component Description Write a 2–3 sentence description covering: - What the component is and its single core responsibility - When to use it versus a related component (name the alternative explicitly, e.g., "Use Button for actions; use Link for navigation") - Keep it functional — no marketing language ### Step 2: Anatomy Break the component into its named structural parts, listed in visual/DOM order: - Name each part (e.g., Container, Leading icon, Label, Trailing icon, Helper text) - One phrase per part describing its role - Flag which parts are optional versus required - Reference tokens where relevant (spacing, radius, color roles) ### Step 3: Usage Guidelines (Do's and Don'ts) Produce two parallel lists of 5–7 items each: - **Do**: Concrete, specific rules ("Do keep button labels to 1–3 words in sentence case") - **Don't**: Common misuse patterns, each paired with the reason ("Don't use more than one primary button per view — it dilutes the primary action") - Cover: content, placement, quantity, and pairing with other components ### Step 4: Props / API Table Generate a table with one row per prop: | Prop | Type | Default | Required | Description | - Use the specified naming convention and framework types (e.g., `'primary' \| 'secondary'`, `boolean`, `ReactNode`) - Boolean props default to `false` and use affirmative naming (`disabled`, not `notEnabled`) - Include callbacks/events (`onClick`, `onChange`) with their payload signature - Include accessibility-related props (`aria-label`, `id`) where the component needs them - Order: required props first, then optional, then event handlers ### Step 5: States Specification For each interactive state, define the visual and behavioral change: - Default, Hover, Focus (keyboard-visible), Active/Pressed, Disabled, Loading, Error (where applicable) - Note which token or style role changes per state - Specify focus indicator requirements (visible, non-color-only) ### Step 6: Accessibility Requirements List the requirements to meet the target WCAG level: - Semantic element or role (e.g., `