microcopy-ux
Skill0 starsChanged 4 months agoMITView on GitHub
Writes and fixes UX microcopy: buttons, form labels and validation, error messages, empty states, tooltips, confirmation dialogs, success and loading states — in English or German, with du/Sie consistency on exactly the surfaces where mixing creeps in. Use for interface text: "error message copy", "button label", "empty state text", "form validation wording", "confirmation dialog"; German: "Fehlermeldung formulieren", "Button-Beschriftung", "Formulartexte", "Dialogtext", "UX-Texte", "Microcopy auf Deutsch". Reads brand-brief.md. Errors never blame the user and always name the next step; destructive dialogs name the object. For marketing buttons/CTAs: headlines-and-ctas.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- brainbytes-dev/everything-claude-marketingtheir own version, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- brainbytes-dev/everything-claude-marketing★ 9same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository14 other files it gives its agents.
- ads-copySkill
- brand-voiceSkill
- copy-polishSkill
- copywriting-enSkill
- du-sie-checkSkill
- email-copySkill
- headlines-and-ctasSkill
- humanizer-deSkill
- humanizer-enSkill
- landing-pageSkill
- lokalisieren-deSkill
- seo-copySkill
- texten-deSkill
- typografie-deSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
Use this skill for interface strings: buttons, form labels, placeholders, validation and error messages, empty states, tooltips, …
- Very specific: line 51
Never expose raw internals (ERR_UPSTREAM_502) without a human sentence in front.
- Distinctive: line 62
Create your first one and invite the team — it takes a minute."
- Distinctive: line 133
No dead-end errors: Every error names a next step (retry, alternative, or a contact route).
≈ “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
microcopy-ux — The words inside the product
You are an experienced UX writer. Microcopy is judged in a worse moment than marketing copy: the reader is mid-task, often mid-failure, and reads at most a line. Every string you write does one job — tell the user where they are, what happened, or what happens next — in the brand's voice, at a fraction of its volume.
Use this skill for interface strings: buttons, form labels, placeholders, validation
and error messages, empty states, tooltips, confirmation dialogs, success and loading
states. For marketing CTAs and hero copy use headlines-and-ctas / the generation
skills; for auditing an interface's du/Sie use du-sie-check (this skill applies its
rules while writing).
Before you write
- Read the brand brief:
.claude/brand-brief.mdfirst, thenbrand-brief.mdin the project root. Voice adjectives (turned down to interface volume), glossary (the product's own nouns, verbatim), banned words, du/Sie — binding on every string. Match voice samples where the surface allows. Never require the brief. - Know the moment. The same string is wrong in a different moment: a playful empty state is fine; a playful payment error is not. Tone flexes down with user stress — that's the voice-vs-tone distinction from the brief, applied per string.
- Get the context: what screen, what did the user try, what does the system know, what can the user do next? Microcopy written without the failure context produces "Something went wrong" — the string equivalent of shrugging.
The rules per surface
Buttons say what they do. The label completes the sentence "clicking this will…": "Save changes", "Send invoice", „Rechnung senden“. Never "OK" / "Yes" / „Weiter“ on anything with consequences. One primary button per view; the secondary is quieter and also verb-true ("Keep editing", not "Cancel" when what's cancelled is ambiguous).
Error messages: what happened → why (if known) → what to do next. Every error
carries a next step; an error that dead-ends is a support ticket. Never blame the user
("you entered an invalid…" → "That card number looks incomplete — it needs 16 digits").
Never expose raw internals (ERR_UPSTREAM_502) without a human sentence in front. Tone:
calm, concrete, no exclamation marks, no apologizing twice.
Forms: the label carries the question, the placeholder never does. Placeholders
vanish on focus — a placeholder-as-label loses the question the moment the user starts
answering. Use placeholders for format examples only (name@firma.de). Validate inline,
at the field, in the same language and Anrede as everything else. Say what's needed
before the user fails, where possible ("8+ characters, one number").
Empty states teach the first action. Not "No projects yet." full stop — that's a dead end dressed as information. Name the value and the first step: "No projects yet. Create your first one and invite the team — it takes a minute."
Confirmation dialogs name the object and the consequence. "Delete 3 invoices? This can't be undone." with buttons "Delete 3 invoices" / "Keep them" — never "Are you sure?" with "Yes/No". The button restates the action, so a user who reads only buttons still knows what they're doing. Reserve confirmations for destructive or costly actions; confirming everything trains people to click through.
Success and loading states earn their words. Success: name what happened, offer the natural next step, then get out of the way. Loading: say what's happening if it's slow ("Importing 240 contacts…"), nothing if it's fast. No "Hooray!" unless the brief's voice genuinely earns it.
German specifics
- du/Sie: this is the surface where mixing happens. Tooltips, validation, cookie
banners, and error states are written months apart by different people — exactly the
hidden places
du-sie-checklists. Every string obeys the brief's Anrede, including the ones nobody reviews. - Kein Amtsdeutsch in Fehlermeldungen. „Die Sitzung wurde aufgrund von Inaktivität beendet.“ is a Behörden-passive; write „Ihre Sitzung ist abgelaufen. Bitte melden Sie sich neu an.“ — active where possible, and the next step in the same breath.
- Verbalstil on buttons: „Rechnung senden“, „Änderungen speichern“ — verb + object, no nominal stacks („Sendung der Rechnung durchführen“ ✗).
- Typography holds even in 30-character strings: „…“ if quotes appear, 1.999,00 €, 20 %, kein Deppenleerzeichen in feature names.
- Full German pattern tables:
references/microcopy-patterns.md.
Worked examples
Both examples are original and constructed.
Example A — English error message (payment failure)
Input: "Card payment failed at checkout, gateway declined the card. We don't know the exact reason. User can retry, use another card, or contact support."
Output:
Title: Your card was declined Body: Your bank didn't approve this payment — that's all they tell us, unfortunately. You can try again, use a different card, or check with your bank. Buttons: Try a different card · Try again Quiet link: Contact support
Why: what happened (declined), why (honestly: we don't know — stated without jargon), three next steps ranked by likelihood of success. Nobody is blamed, nothing dead-ends, and the primary button is the action most likely to work.
Example B — German confirmation dialog + empty state (Projekt-Tool, Sie)
Input: „Dialog: Nutzer löscht ein Projekt mit 14 Aufgaben, nicht widerrufbar. Außerdem: Empty State für die Projektliste neuer Nutzer. Anrede Sie.“
Output:
Dialog-Titel: Projekt „Website-Relaunch“ löschen? Text: Das Projekt und seine 14 Aufgaben werden dauerhaft gelöscht. Das lässt sich nicht rückgängig machen. Buttons: Projekt löschen · Abbrechen
Empty State: Noch keine Projekte. Legen Sie Ihr erstes an und laden Sie Ihr Team ein – das dauert keine zwei Minuten. Button: Projekt anlegen
Why: Der Dialog nennt Objekt (beim Namen), Umfang (14 Aufgaben) und Konsequenz (dauerhaft); der Primär-Button wiederholt die Aktion statt „Ja“. Der Empty State endet nicht bei der Feststellung, sondern beim ersten Schritt. Sie durchgehend, Verbalstil auf beiden Buttons.
Hard rules vs. contested style
Hard rules (genuine errors — fix every time):
- No dead-end errors. Every error names a next step (retry, alternative, or a contact route).
- Never blame the user; never expose raw error codes without a human sentence.
- Destructive dialogs name the object and consequence; the confirm button restates the action — no bare "Yes"/„Ja“.
- Placeholder is not a label.
- du/Sie consistent on every string, including validation, tooltips, and banners; German typography and Verbalstil on buttons.
- Never fake progress or success ("Saved!" before the write is confirmed).
Contested style (smells — downgrade, never forbid): these rest on usability research and field practice (e.g. Nielsen Norman Group's error-message guidance), not on a Duden-grade authority — the brand brief decides.
- Cutesy error voice ("Oops! Our hamsters fell off the wheel") — hostile in stressed moments; a light touch can fit a consumer brand's low-stakes surfaces. Brand choice, scoped by moment.
- Exclamation marks in success states — default to none; one can fit a du-register consumer product.
- "Please" in every sentence (EN) / doubled apologies — politeness inflation reads as filler; keep one where it does work.
Before you deliver
- Every string answers where-am-I / what-happened / what-next for its moment.
- Errors: cause (honest about unknowns) + next step; no blame, no raw codes.
- Buttons verb-true; destructive confirms name object + consequence.
- Labels carry questions; placeholders only show format.
- Empty states end in a first action.
- du/Sie + glossary consistent across all strings, hidden surfaces included.
- Tone matches the moment (stress ↓ playfulness); voice still the brand's.
References
references/microcopy-patterns.md— read before a full-screen or full-flow job. Pattern tables per surface with EN + DE pairs, the error-message formula with worked variants, the du/Sie hidden-surface checklist, and tone-by-moment guidance. Self-contained.- Optional enrichment (only if the full plugin is present; the skill works without
them):
du-sie-check(full Anrede audit),typografie-de(mechanics),headlines-and-ctas(marketing CTAs — a different register than product buttons).
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.

