taste-ux-copy
Skill1 starsChanged 3 months agoMITView on GitHub
UX writing for agent-built interfaces: voice and tone, headline formulas, button labels, microcopy, error messages, empty states, loading text, pricing labels, and inclusive language — with before/after pairs and a copy checklist. Use whenever generating any interface text. Stack on the design-taste core skill.
In this repository23 other files it gives its agents.
- brutalist-industrialSkill
- cinematic-motionSkill
- corporate-trustSkill
- dark-techSkill
- design-tasteSkill
- editorial-minimalSkill
- japanese-minimalSkill
- neo-brutalismSkill
- playful-colorSkill
- quiet-luxurySkill
- retro-printSkill
- taste-accessibilitySkill
- taste-brand-identitySkill
- taste-code-craftSkill
- taste-code-reviewSkill
- taste-colorSkill
- taste-design-reviewSkill
- taste-design-systemSkill
- taste-gsapSkill
- taste-landing-pageSkill
- taste-motionSkill
- taste-typographySkill
- taste-web-performanceSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 52
Every error message has three beats, in order:
- Distinctive: line 88
Write for translation: no nested variables mid-sentence ("Your {{count}} friends" → "Friends: {{count}}"), no idioms ("hit the ground …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
taste-ux-copy
Copy is the interface's personality and its instruction manual. Bad copy makes good design look broken.
1. VOICE & TONE (Decide It First, Then Write)
Pick a voice from the brand read and lock it:
| Voice | Sounds like | Fits |
| Plainspoken | "We tell you when something's wrong. Here's what to do." | Enterprise, fintech, health |
| Direct | "Type less. Ship more." | Developer tools |
| Warm | "You're almost done — one step left." | Consumer, education |
| Dry-humor | "No, this isn't a cult. The newsletter is just that good." | Consumer, indie brands |
Rules that hold in every voice: be concrete ("42 rows" not "some data"), be honest (no "just" — "Just enter your email" is a lie), address the reader as you/your on marketing, no exclamation marks except one-per-page celebrations, no passive voice in errors, no corporate filler ("leverage", "streamline", "robust").
2. HEADLINES (Formulas That Work)
- Outcome + audience: "Analytics that don't need a data team."
- Before → after: "From 'where are my users going?' to 'oh, there.'"
- Name the pain: "Your signup form is leaking 63% of visitors."
- Authority + promise: "The 2026 pricing guide for indie SaaS."
- Curiosity with a payoff (never curiosity alone): "We deleted our dashboard. Here's what we replaced it with."
Rules: H1 under 12 words; one idea; the product name can live in the subline, not the H1; no punctuation theatrics (?!,!!!); no "The Future of X" openers.
3. BUTTONS & ACTIONS (The Most-Read Words on the Page)
- Buttons say the action: "Save changes" > "Submit" > "OK". First-person lifts consumer conversion: "Start my free trial".
- Destructive actions say what dies: "Delete project" (never "OK"). Paired with a cancel that's equally visible.
- Loading/disabled states say what's happening, not a promise: "Saving…" > "Please wait". Never "Almost done" if it's not provable.
- The label must survive without context: no icon-only buttons without accessible text.
4. ERRORS (Formula: What + Why + Fix)
Every error message has three beats, in order:
- What happened, in plain language ("We couldn't save this section").
- Why (one clause max: "the file is larger than 10 MB").
- The fix (the verb: "Remove some images and try again", or a link).
Before/after pairs:
| Before | After |
| "Error 500 — please try again later" | "This page hit a snag on our side. Reload — your work is saved." |
| "Invalid input" | "Add at least 8 characters. A number helps." |
| "Password incorrect" | "That password doesn't match. Forgot it? Reset here." |
Field-level errors sit next to the field, not in a toast on the other side of the screen. Never blame the user ("You entered…" → "This field needs…").
5. EMPTY STATES (Every Empty State Has a Job)
- Name the emptiness ("No projects yet").
- Why it's empty (one line: "Projects show up here when you create them").
- The next action (one button: "Create your first project").
- Optional: a tiny win ("Takes about 4 minutes").
An empty state with no next step is a dead end. A dead end is a product failure.
6. STATUS & LOADING
- Progress: verbs, not promises ("Uploading 3 of 8 files…").
- Completion: state what changed, not just "Done" ("8 files uploaded to /reports").
- Notifications: subject + one clause + optional action, under 20 words: "Payment failed — your card was declined. Update it here."
- Skeleton states: never show a skeleton for longer than ~2s without a message.
7. INCLUSIVE & LOCALIZED READY
- No "guys", "man-hours", gendered pronouns in generic copy; "they" is fine. Avoid "simply/easily/just" (they insult the reader's context).
- Numbers: "1,024" not "1k" where precision matters; dates spell out where ambiguous (July 3 ≠ 7/3).
- Write for translation: no nested variables mid-sentence ("Your {{count}} friends" → "Friends: {{count}}"), no idioms ("hit the ground running"), no emoji-only messages.
8. CHECKLIST (Fail the Copy If…)
- Any sentence with "leverage", "streamline", "robust", "seamless", "cutting-edge".
- Any error without a fix.
- Any button that says "Submit" or "OK" where a real verb exists.
- Any empty state without a next action.
- Any headline over 12 words or with a "!".
- Any claim the page can't support on the same viewport.
- Two different labels for the same action on one page.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

