UX copy generator · free AI skill

Generates production-ready UI microcopy across 6 component types — button labels, error messages, empty states, tooltips, onboarding flows, and confirmation dialogs — with accessibility annotations, character-count…

Purpose

Generate concise, accessible, on-brand microcopy for the specific UI components you're designing — with alternatives to A/B test, accessibility annotations, and character counts that fit real component constraints. Eliminates the "TBD copy" placeholder problem and the awkward gap between a designer's mockup and a writer's final pass.

When to Use

Invoke this skill when the user asks to:

Write button labels, CTA text, or action labels for a UI
Fix vague or blame-y error messages
Design empty state copy for a list, dashboard, or search result
Write tooltip or helper text for form fields and controls
Build onboarding, welcome, or first-run copy
Fill in placeholder microcopy across a screen or flow

Inputs Required

Before starting, collect:

Component type(s): Which of these you need — buttons, errors, empty states, tooltips, onboarding, confirmations (one or several)
Product context: What the product does and what this screen/flow accomplishes
User action or state: What the user is doing or what triggered this copy (e.g., "submitting a payment," "no results found," "form validation failed")
Voice & tone: 3–4 adjectives, or a link/reference to a voice guide (e.g., "friendly but direct," "calm and reassuring")
Character/space constraints: Any known limits (button max width, tooltip length, mobile vs. desktop)
Brand terms & forbidden words: Product names, capitalization rules, terms to avoid

If voice is unspecified, default to "clear, human, and low-friction" — plain language, active voice, no jargon. If character limits are unknown, apply the standard limits noted per component below.

Instructions

Generate Copy Across the Requested Component Types

For each component type requested, produce 3 variants (primary recommendation + 2 alternatives) unless the user asks for more. For every variant, include the copy, a character count, and a one-line rationale. Apply the universal rules first, then the component-specific rules.

Universal rules (apply to everything):

Active voice, present tense, second person ("you") where natural
Front-load the most important word — users scan, they don't read
No jargon, no internal terminology, no filler ("please," "kindly," "simply," "just")
Sentence case unless the brand rules specify otherwise
Accessibility: copy must make sense read aloud by a screen reader out of visual context

Component 1 — Button & Action Labels Standard limit: 1–3 words, ~25 characters max.

Use a verb that describes the outcome, not the mechanism ("Save changes," not "Submit")
Match the label to the user's goal, not the system's operation
Avoid ambiguous "OK" / "Yes" / "No" in confirmations — restate the action
Include an aria-label suggestion if the visible label is an icon or is ambiguous out of context

Component 2 — Error Messages Standard limit: 1 sentence, ~120 characters; add a second sentence only for recovery guidance.

Structure: what happened → why (if useful) → how to fix it
Never blame the user ("Invalid input" → "Enter a valid email address, like name@example.com")
No error codes in the user-facing string unless support workflows require them (note them separately)
Be specific: name the exact field or condition that failed
Reassuring tone for system errors, instructive tone for user errors

Component 3 — Empty States Standard limit: headline (~40 chars) + supporting line (~90 chars) + optional CTA.

Distinguish the type of empty state: first-use (nothing created yet), cleared (all done), no-results (search/filter returned nothing), or error-empty
First-use and cleared states should be encouraging and point to the next action
No-results states should offer a recovery path (clear filters, broaden search, add item)
Always pair with a concrete CTA where an action is possible

Component 4 — Tooltips & Helper Text Standard limit: 1 line, ~80 characters; helper text under a field can extend to ~120.

Explain the why or the format, not the obvious ("Email" field doesn't need "Enter your email")
Use for format hints, constraints, and consequences ("Used only for receipts")
Never hide required information in a tooltip — tooltips are progressive disclosure, not primary content
Write so it makes sense when read by a screen reader adjacent to the field label

Component 5 — Onboarding & First-Run Copy Standard limit: headline (~50 chars) + body (1–2 short sentences) per step.

Lead with the value the user gets, not the feature that delivers it
One idea per screen — don't stack multiple concepts
Progressive: earlier steps set context, later steps drive the first meaningful action
Include a skippable path — never trap the user; provide a "Skip" or "Do this later" label

Component 6 — Confirmation & Dialog Copy Standard limit: title (~40 chars) + body (1 sentence) + two action labels.

Title states the decision as a question or statement ("Delete this project?")
Body clarifies consequences, especially for destructive actions ("This can't be undone")
Action labels restate the specific action ("Delete project" / "Keep it") — never "OK/Cancel" for destructive actions
Match the emotional weight to the stakes — light for reversible, serious for destructive

Voice Consistency Pass

After generating all copy, review the full set as a group:

Check that terminology is consistent (one word per concept — don't switch between "delete," "remove," "trash")
Confirm the tone reads as one voice, not six disconnected snippets
Verify no forbidden words or off-brand terms slipped in

Output Format

Structure: One section per requested component type; each variant labeled Primary / Alt 1 / Alt 2 with copy, character count, and rationale
Length: 400–900 words depending on how many component types are requested
Format: Scannable — copy in bold or quotes, metadata (char count, aria-label, rationale) as sub-bullets
Sections: One per component type requested → Voice Consistency Pass summary → any accessibility notes flagged
Tone: Content designer reviewing a colleague's work — direct, opinionated about the recommendation, brief on rationale

Quality Checklist

Before delivering output, verify:

[ ] Every requested component type has a Primary variant plus at least 2 alternatives
[ ] Every variant has a character count and it respects the stated or standard limit
[ ] No error message blames the user; each includes a recovery path where one exists
[ ] Destructive confirmations use specific action labels, not "OK/Cancel"
[ ] No forbidden words or off-brand terms appear in any variant
[ ] Icon-only or ambiguous controls include an aria-label suggestion

Notes

The single highest-impact rewrite in most products is error messages — start there if the user is unsure where to begin
Character counts matter more than they seem: copy that fits in the mockup but truncates on a narrow mobile viewport creates real bugs
When the user provides a voice guide, mirror its exact terminology and capitalization rather than defaulting to sentence case
If a tooltip is doing load-bearing work (the UI doesn't function without reading it), flag it — that's a design problem, not a copy problem

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:

Drag this file into a new chat, or copy and paste its contents
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