agentleFS
bndktsbndkts/copycraft/skills/microcopy-ux/SKILL.md

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

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
  1. Distinctive:

    Use this skill for interface strings: buttons, form labels, placeholders, validation and error messages, empty states, tooltips, …

    line 22
  2. Very specific:

    Never expose raw internals (ERR_UPSTREAM_502) without a human sentence in front.

    line 51
  3. Distinctive:

    Create your first one and invite the team — it takes a minute."

    line 62
  4. Distinctive:

    No dead-end errors: Every error names a next step (retry, alternative, or a contact route).

    line 133

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.md first, then brand-brief.md in 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-check lists. 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).

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.