Documentation Guidelines
How to write and generate documentation for Evolphin UI components.
This guide explains how to create documentation for components in Evolphin UI. You can either use LLM-based automation or write docs manually using our template.
Quick Start
π€ LLM Approach
Auto-generate docs using AI β best for new components
βοΈ Manual Approach
Write docs by hand β best for simple updates
When to Use Each Approach
| Situation | Recommended Approach |
|---|---|
| New component with many variants | π€ LLM |
| Bulk documentation (5+ components) | π€ LLM |
| Quick prop update | βοΈ Manual |
| Simple component (< 3 props) | βοΈ Manual |
| Need very specific wording | βοΈ Manual |
| First draft, then refine | π€ LLM β βοΈ Manual |
LLM-Based Approach
Use AI to generate comprehensive documentation automatically.
Files Location
How It Works
Copy the Prompt
Open llm.txt/component-docs-prompt.md and copy the entire contents.
Set the Component Name
Replace {COMPONENT_NAME} at the bottom of the prompt with your component:
Component to document: `button`Provide Component Source
Give the LLM the component source code from:
registry/default/ui/{component-name}.tsxGenerate & Review
- Run the prompt with your preferred LLM
- Review the generated documentation
- Make any necessary refinements
Example Prompt Usage
# Copy from llm.txt/component-docs-prompt.md
[... prompt content ...]
Component to document: `dialog`
---
Here is the component source:
[Paste contents of registry/default/ui/dialog.tsx]The LLM will analyze the component and generate complete documentation with all variants, examples, and API reference.
Manual Approach
For simple components or quick updates, use the manual template.
How It Works
Copy the Template
Copy llm.txt/component-template.mdx
Replace Placeholders
Replace all {placeholders} with actual values:
{ComponentName}βButton{component-name}βbutton{description}β Your description
Add Examples
Create a <ComponentPreview> for each:
- Default state
- Each variant
- Each size
- With icons
- Special states (loading, disabled)
Fill API Reference
Document all props in the table:
| Prop | Type | Default | Description |
| --------- | -------------------------- | ----------- | ------------ |
| `variant` | `"default" \| "secondary"` | `"default"` | Visual style |Save
Save to content/docs/components/{component-name}.mdx
Documentation Structure
Every component doc should have these sections:
Required Sections
| Section | Purpose |
|---|---|
| Title + Description | Frontmatter with SEO-friendly text |
| Installation | CLI commands with package manager tabs |
| Usage | Import statement + basic example |
| Examples | ComponentPreview for each variant |
| API Reference | Props table with types and defaults |
Optional Sections
| Section | When to Include |
|---|---|
| Accessibility | Keyboard/screen reader behavior |
| Subcomponents | If component has parts (Dialog.Trigger, etc.) |
| Composition | Complex usage patterns |
Quality Checklist
Before submitting documentation:
- Title matches component name
- Description is concise (one line)
- Installation has all 3 package managers
- Import path uses
@/components/ui/ - Every variant has a working preview
- API table includes ALL props
- Default values are documented
- Types are accurate
- No broken imports
ComponentPreview Usage
Always use <ComponentPreview> for interactive examples:
<ComponentPreview code={`<Button variant="secondary">Click</Button>`}>
<Button variant="secondary">Click</Button>
</ComponentPreview>The code prop must match what's rendered inside. Keep them in sync!
Multi-line Code
For complex examples:
<ComponentPreview
code={`<Button>\n <Mail className="mr-2 h-4 w-4" />\n Email\n</Button>`}
>
<Button>
<Mail className="mr-2 h-4 w-4" />
Email
</Button>
</ComponentPreview>File Naming
| Type | Convention | Example |
|---|---|---|
| Component docs | {kebab-case}.mdx | date-picker.mdx |
| Guide pages | {kebab-case}.mdx | getting-started.mdx |
| Meta files | meta.json | meta.json |