The Claude UX Copywriter Skill: Stop Shipping Lorem Ipsum and Generic Button Text

A ready-to-paste Claude Code skill that reviews and rewrites the interface copy in any generation: buttons, errors, empty states, and labels, all checked against real UX writing rules instead of the model's default marketing voice.

The problem with AI interface copy

Claude is good at building a screen and bad at writing what goes on it, unless you make it. Left alone, it reaches for the most statistically common words: buttons that say “Submit” and “Get Started”, errors that say “Something went wrong”, empty states that say nothing useful, and headlines stuffed with “seamless” and “unlock” and “supercharge.”

The layout looks finished. The copy is placeholder wearing a suit. And copy is the part of the interface users actually read.

Generic copy is the fastest way to make a good design feel cheap. The fix is not to ask nicely each time. It is to give Claude a checklist it runs every time.

This guide gives you that checklist as a skill. You paste one file, and from then on /ux-copy audits and rewrites the interface copy in any generation, against rules instead of vibes.


What you will build

By the end you will have:

  1. A real file at ~/.claude/skills/ux-copy/SKILL.md
  2. A /ux-copy command you can run in any project
  3. An audit that checks buttons, labels, errors, empty states, and headlines
  4. A rewrite pass that fixes the weak copy inline and tells you what changed

It works in about ten minutes. Tuning it to your product’s exact voice is the ongoing part.


The rules the skill enforces

These are the fundamentals AI copy gets wrong most often. The skill carries all of them.

  • Buttons name the action, not the form. “Send invite”, not “Submit.” The user should know what happens before they click.
  • Lead with the user’s goal, not the system’s process. “Find your plan”, not “Plan selection wizard.”
  • Errors say what happened and what to do next. “That email is already registered. Try signing in.” Never a bare “Error” or “Something went wrong.”
  • Empty states teach the first action. An empty list is the best place to show someone how to start, not a shrug.
  • Plain language over jargon. Write for a tired person on a phone, not for a spec document.
  • Sentence case, not Title Case Everywhere. It reads as human, not as a billboard.
  • Consistent terms. If it is a “project” on one screen, it is not a “workspace” on the next.
  • No marketing fluff in the product. Ban the buzzwords. The interface is not an ad.
  • No dark patterns. No guilt in the decline button, no fake urgency, no tricks.

Build the skill

Step 1: Create the folder and file

mkdir -p ~/.claude/skills/ux-copy
touch ~/.claude/skills/ux-copy/SKILL.md

Step 2: Paste the full skill

Open ~/.claude/skills/ux-copy/SKILL.md and paste this. It is ready to use as is. The bracketed [...] lines near the bottom are where you add your own product voice later.

---
name: ux-copy
description: Review and rewrite the interface copy in the most recent UI Claude
  generated or edited. Use after building any screen, component, form, error
  state, or empty state. Audits buttons, labels, errors, empty states, and
  headlines against UX writing rules, then rewrites the weak ones inline.
---

## What this skill does

Read the most recently generated or edited UI file. Find every piece of
user-facing copy: button labels, links, headings, field labels, helper text,
placeholders, error messages, empty states, confirmations, tooltips, and
toasts. Audit each one against the rules below. Rewrite the weak ones inline
and report what changed.

## The rules

### Buttons and links
- Name the action, not the mechanism. "Send invite", never "Submit".
- Start with a verb where possible. "Create project", "Delete file".
- Avoid "Click here", "Get started", and "Learn more" unless nothing better fits.
- The label must make the outcome obvious before the click.

### Headings and labels
- Lead with the user's goal, not the system's internal name.
- Sentence case, not Title Case. ("Account settings", not "Account Settings".)
- Field labels are nouns the user recognizes, not database column names.

### Helper text and placeholders
- Helper text explains the why or the format, not the obvious.
- Never put the label only in the placeholder. Placeholders disappear on input.

### Error messages
- Say what happened in plain words.
- Say what to do next.
- Never blame the user. Never ship a bare "Error" or "Something went wrong".
- Example shape: "[what happened]. [what to do next]."

### Empty states
- Teach the first action. An empty list is an onboarding moment.
- One sentence of context, one clear action. Not a dead end.

### Voice and consistency
- Plain language. Write for a tired person on a phone.
- One term per concept across the whole product. No project-vs-workspace drift.
- No dark patterns: no guilt-tripped decline buttons, no fake urgency, no tricks.

### Banned words inside the product UI
- unlock, leverage, empower, supercharge, revolutionize, seamless, effortless,
  elevate, delight, magic, simply, just, easy
- These belong in ads, not in working interfaces. Remove on sight.

## My product voice
[Add your own here. Examples:]
- [Person: second person ("you"), or none.]
- [Tone: calm and direct, or warm and playful.]
- [Specific terms: the canonical word for each core object.]
- [Anything the rules above should override for this product.]

## How to audit

For each piece of copy found:
1. Identify its type (button, label, error, empty state, heading, helper).
2. Check it against the matching rule set above.
3. If it is weak, rewrite it inline in the file.
4. If it hits a banned word or a dark pattern, flag it explicitly, then fix it.

## Output format

First, a short list of changes:
- [type] "[old copy]" to "[new copy]" because [rule]

Then a scorecard, each scored 0 to 10:
- Action clarity: do buttons and links name real outcomes?
- Error usefulness: does every error say what to do next?
- Empty-state usefulness: does every empty state teach the next action?
- Plain language: jargon and fluff removed?
- Consistency: one term per concept?
- Dark-pattern cleanliness: zero manipulative copy?

If every dimension scores 8 or higher and no banned words remain, print:
"UX copy audit passed."
Otherwise print:
"UX copy audit failed. Fix the items above and re-run."

Step 3: Test it

Open any project. Ask Claude Code to build a small form, a sign-up flow, or a screen with an empty state. Then run:

/ux-copy

Claude reads the screen it just built, audits the copy, rewrites the weak parts, and prints the change list plus the scorecard.

Before and after one run

Claude builds a team-invite form. The button says “Submit”, the error says “Something went wrong”, and the empty state says “No members.” You run /ux-copy. The button becomes “Send invite”, the error becomes “We could not send that invite. Check the email address and try again,” and the empty state becomes “No one here yet. Invite your first teammate to get started.” Same layout. The screen suddenly reads like a real product.


Tune it to your product

The starter rules fix the universal problems. The “My product voice” section is where it becomes yours. After a few runs, add:

  • Your canonical term for each core object (is it a “board”, a “project”, or a “space”?)
  • Your person and tone (do you address the user as “you”, or avoid it?)
  • Any rule the defaults should override for your specific product

The banned-words list does most of the work on day one. The product-voice section is what makes the output sound like your product and not just like clean generic copy.


Ship it

Exercise

Install the skill and run it on a real screen

20 min
  1. Write the skill file

    Run mkdir -p ~/.claude/skills/ux-copy && touch ~/.claude/skills/ux-copy/SKILL.md. Paste the full skill from Step 2. Leave the rules as they are for now, but read them so you know what the audit will enforce.

    • The file exists at ~/.claude/skills/ux-copy/SKILL.md
    • The frontmatter name is ux-copy and the description explains when to use it
    • You have read the banned-words list and the error-message rule
  2. Run /ux-copy on a screen with an empty state

    Ask Claude to build a screen that has a list, an empty state, a primary button, and at least one error case. Run /ux-copy. Read the change list. Confirm the button now names an action and the error now tells the user what to do.

    • At least one button label changed from a generic word to a real action
    • The error message now says what happened and what to do next
    • The empty state teaches the first action instead of just stating emptiness
  3. Add one line of your product voice

    Open the skill again. In “My product voice”, write the single canonical term for your product’s core object, and whether you address the user as “you”. Re-run /ux-copy on the same screen and watch the copy shift toward your voice.

    • The skill now contains at least one product-specific rule
    • The second run produced copy that matches your term and person
    • You know which rule to add next the moment you notice the copy drift

What you learned

Done with this guide?

Mark it complete to track it on your dashboard.

Read time
10 min
Free to try Cancel anytime
The guides alone saved me a full day of work every sprint.
Senior Design Systems Lead
Enterprise SaaS
Pro
Full access to everything.
$39 /month
  • All guides, prompts, and templates
  • Starter kits and templates
  • New content every week
  • Priority support