Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Component generator

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…

download .md

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., <button> vs role="button")
  • Required ARIA attributes and their dynamic values
  • Keyboard interaction map (which keys do what — Enter, Space, Arrow, Esc, Tab)
  • Focus management behavior (trap, return, order)
  • Contrast requirement for text and non-text elements (4.5:1 / 3:1)

Step 7: Variant Matrix

Present a matrix or grid crossing variants against sizes/states:

  • Rows = variants, columns = sizes (or the relevant second dimension)
  • Note any invalid combinations explicitly ("Loading is not supported on the ghost variant")
  • Recommend a sensible default variant + size

Output Format

  • Structure: Seven titled sections in the order above; props and variant data as markdown tables
  • Length: 700–1,100 words
  • Format: Structured document — prose for description, lists for guidelines, tables for props and variants
  • Sections: Description → Anatomy → Usage Guidelines → Props/API Table → States → Accessibility → Variant Matrix
  • Tone: Design systems documentation — precise, prescriptive, opinionated about correct usage; no filler

Quality Checklist

Before delivering output, verify:

  • [ ] The description names an explicit alternative component and when to use it instead
  • [ ] Every prop row has all five columns filled (Prop, Type, Default, Required, Description)
  • [ ] Do's and Don'ts each contain 5–7 items, and each Don't includes a reason
  • [ ] Every interactive state (including Focus and Disabled) is specified
  • [ ] Accessibility section includes a keyboard interaction map and a contrast requirement
  • [ ] Variant matrix marks at least the recommended default and any invalid combinations

Notes

  • Boolean prop sprawl is a common failure mode — if a component has more than two mutually exclusive booleans, recommend consolidating them into a single enum/variant prop
  • Focus states are the most frequently under-documented; never let the focus row read "same as hover"
  • If the component is compound (e.g., Tabs → TabList → Tab → TabPanel), generate the props table per sub-component and note the composition contract between them
  • Tie state and variant styling to token references rather than raw values wherever the naming convention supports it

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills