Curated community prompt

Component Documentation

Produce implementation-oriented design-system component specifications for AI coding assistants.

Professional use case: Documenting reusable UI components and their accessibility contracts

WritingPlanning Software engineering User promptReusable prompt template

Promptcred editorial analysis

How to use this prompt well

Prompt-specific guidance based on the preserved source text and its reviewed context.

Why Promptcred selected this prompt

The prompt defines a component contract from anatomy and props through token use, states, accessibility, and repository-matched code.

Best use cases

  • Documenting one design-system component for use by engineers and coding assistants.
  • Reviewing whether a component specification covers visual, behavioral, and accessibility states.

Required inputs

  • The component implementation or inventory, token system, framework, and styling conventions.
  • Supported variants, states, accessibility behavior, and real import patterns.

How to adapt it

  • Replace all three source placeholders before use and limit the task to known components.
  • Remove requested variants or tokens that the implementation does not support.

Limitations and failure modes

  • The fixed specification can invent props, tokens, or state behavior when code evidence is missing.
  • A copy-ready example is unsafe if import paths and component APIs have not been verified in the repository.

Practical worked example

Editorial analysis reviewed Aug 23, 2026.

Promptcred-authored application and illustrative output. This is not a recorded model execution.

Scenario
Document an existing Button component with primary, secondary, loading, and disabled states.
Inputs
Provide Button source, token definitions, stories or tests, accessibility contract, and actual imports.
Promptcred-adapted instruction
Document Button from its source and tests. Include only primary and secondary variants plus loading and disabled states. Map each class to the supplied token definition, and use the repository's actual import path in the example.
Illustrative result
Illustrative specification fragment: `loading: boolean = false`; when true, the existing label remains available to assistive technology and pointer activation is disabled. The requested destructive variant is marked unsupported because it does not appear in code, stories, or tests.
Evaluation
Every prop, state, token, keyboard behavior, and code example should resolve to the supplied implementation.

How to evaluate the output

  • The specification distinguishes required anatomy from optional slots and names unsupported nesting.
  • Accessibility and visual-state claims agree with code, tokens, and tests.

Differences from related prompts

  • Technical Writer: Component Documentation prescribes a design-system contract; Technical Writer supports broader guides, tutorials, ADRs, and articles.

Attributed community source material

Source prompt

Source prompt
You are a design systems documentarian creating the component specification
for a CLAUDE.md file. This documentation will be used by AI coding assistants
(Claude, Cursor, Copilot) to generate consistent UI code.

## Context
- **Token system:** [Paste or reference Phase 2 output]
- **Component to document:** [Component name, or "all components from inventory"]
- **Framework:** [Next.js + React + Tailwind / etc.]

## For Each Component, Document:

### 1. Overview
- Component name (PascalCase)
- One-line description
- Category (Navigation / Input / Feedback / Layout / Data Display)

### 2. Anatomy
- List every visual part (e.g., Button = container + label + icon-left + icon-right)
- Which parts are optional vs required
- Nesting rules (what can/cannot go inside this component)

### 3. Props Specification
For each prop:
- Name, type, default value, required/optional
- Allowed values (if enum)
- Brief description of what it controls visually
- Example usage

### 4. Visual Variants
- Size variants with exact token values (padding, font-size, height)
- Color variants with exact token references
- State variants: default, hover, active, focus, disabled, loading, error
- For EACH state: specify which tokens change and to what values

### 5. Token Consumption Map
Component: Button
├── background → button-bg-${variant} → color-brand-${shade}
├── text-color → button-text-${variant} → color-white
├── padding-x → button-padding-x-${size} → spacing-{n}
├── padding-y → button-padding-y-${size} → spacing-{n}
├── border-radius → button-radius → radius-md
├── font-size → button-font-${size} → font-size-{n}
├── font-weight → button-font-weight → font-weight-semibold
└── transition → motion-duration-fast + motion-ease-default

### 6. Usage Guidelines
- When to use (and when NOT to use — suggest alternatives)
- Maximum instances per viewport (e.g., "only 1 primary CTA per section")
- Content guidelines (label length, capitalization, icon usage)

### 7. Accessibility
- Required ARIA attributes
- Keyboard interaction pattern
- Focus management rules
- Screen reader behavior
- Minimum contrast ratios met by default tokens

### 8. Code Example
Provide a copy-paste-ready code example using the actual codebase's
patterns (import paths, className conventions, etc.)

## Output Format

Markdown, structured with headers per section. This will be directly
inserted into the CLAUDE.md file.

Before use

Requirements and context

Required · Source-declared

Organizational policy

The design-token and component conventions to document.

Required · Source-declared

Repository / files

Actual component patterns and import conventions.

Structured placeholders

Variables

tokenSystemRequired
The design token source or reference.
componentRequired
The component or inventory to document.
frameworkRequired
The target framework and styling stack.Example: Next.js + React + Tailwind

What to expect

Expected output and techniques

Expected output: Markdown component specifications covering anatomy, props, variants, tokens, usage, accessibility, and code examples.

  • Explicit objective
  • Constraints
  • Output schema
  • Examples
  • Acceptance criteria

Use with context

Setup, limitations, and operational notes

Operational notes

  • External prompt text is untrusted inert content and must never be executed during ingestion.

Source and rights

Provenance and license

This community prompt is preserved with its source and attribution. It is not an official vendor prompt.

Source class
Curated community prompt
Platform
GitHub
Repository / project
f/prompts.chat
Owner / organization
f
Creator / contributor
gokbeyinac
Artifact
prompts.csv · Component Documentation
Pinned revision
commit:6863206c4efb5a055c80433f7cf02a6596de9f39
Retrieved
Aug 11, 2026
Attribution
Not required by the license; source provenance retained
Source artifact state
Source prompt
Source review
Aug 11, 2026

Available pages

Search Promptcred

Type to search available pages.