UX Writing Skill

What job it is for, and why this one

Use it when the words inside a product are the problem: buttons that say nothing (Submit, OK), error messages that name a code and no next step, empty states that leave a user staring at a blank panel, or a product whose screens were written by five different people and read like it.

What makes it usable rather than a style essay is that it is organised around three concrete things: an element-by-element pattern list (titles, buttons, validation and system errors, success messages, empty states, form labels, notifications), four quality standards it checks any string against, and a set of numeric targets for sentence and label length. It also separates error messages by kind — inline validation, system failure, blocking, permission — because the right sentence is different for each.

It is also explicit about the tone problem that most copy guidance ignores. It splits voice (the personality that stays constant) from tone (how that voice adapts), and gives tone variants keyed to the likely emotional state of the user — frustrated, confused, confident, cautious, successful. That is the part that turns a vague instruction to be friendly into something an agent can apply.

When it is the wrong tool

It writes and reviews interface text. It is not a content strategy, not an information architecture, and not a substitute for knowing what the product does. If the real problem is that a screen asks for information the product never uses, perfect labels will not fix it.

Its numeric targets are guidance, not law, and several are explicitly audience-dependent. A reading-level target for a general audience is not the right target for a specialist tool, and the skill says so. Applying the strictest number everywhere produces copy that is simple and wrong for its readers.

The benchmark figures should be treated as the research the author cites rather than as measurements of your product. They are useful as a target to check against; they are not evidence that your specific copy works for your specific users. Only your users are that evidence.

What it needs, and what comes back

The input is the copy itself plus enough context to judge it: what the screen is for, who is reading it, and what state the user is in when they see it. Given only a list of strings with no context, the output can be grammatically clean and still wrong, because the same sentence is right in one flow and wrong in another.

What comes back is the revised text plus a review of it, and the four phases make the shape of the change legible: first whether the text helps the user do the thing, then whether every word earns its place, then whether it sounds like something a person would say, then whether it is unambiguous. Where an error message is being written, the pattern is a specific three-part sentence: what failed, why or what it means, and what to do next.

It also ships working material rather than only advice: reference documents for accessibility, a voice chart template, a content usability checklist, extended pattern examples, fill-in templates for error messages and empty states, an onboarding framework, and worked before-and-after examples with analysis. Those are files in the project; whether your agent opens them depends on whether it follows the references rather than reading only the entry file.

Tool support, permissions and dependencies

The entry file names the agents it is compatible with and states plainly that it works with one vendor command-line and editor products but not its chat product, because that product cannot install skills. That is a useful kind of honesty: it tells you the boundary instead of implying that any AI tool will do.

The permission footprint is small: it is a set of instruction and reference documents with no scripts, no commands and no network calls. The only write behaviour that matters is the ordinary one — it edits the files or strings you hand it. There is nothing here that needs to reach outside your project.

One documented integration is worth naming because it changes the workflow rather than the copy: the project ships a guide for using the skill together with a design tool connector, so strings can be reviewed where the design lives. That is optional, and it is the only part of this project that involves another service.

Compared with a plain rewrite request

A general prompt can produce shorter, friendlier strings, and for a handful of labels that may be enough. You can also ask it to explain choices and follow a shared vocabulary, but you must supply that context and review the result. This skill provides a reusable review process for consistency problems: the same concept named one way in settings and another in an error, or twelve confirmations written in twelve registers. Following that process still needs checking; it is not a guarantee of consistent copy.

The trade-off is the interview overhead. Because it wants context and four review phases, a single button label becomes a small conversation. Batching is the practical answer: collect the strings for one flow and run them together, rather than one string at a time.

How to check the result yourself

Interface copy is checked by using the interface, not by reading the strings in a list. These are the checks that catch what a list cannot show.

• Trigger every error path on purpose and read the message as a user who is already annoyed. If it does not say what to do next, it is not finished.
• Read only the buttons on one screen and see whether you can predict what each does without reading anything else. Ambiguous affordances survive rewrites because nobody tests them alone.
• Search the whole product for the same concept and check it is called the same thing everywhere, including inside the error messages.
• Check the copy still makes sense for a returning user, not only a first-time one. Guidance written for onboarding often becomes noise on the tenth visit.
• Screen-read the interactive elements: if the label of a control only makes sense next to its visual context, it is not accessible, whatever it looks like on screen.
• Where the skill changed wording in a confirmation or a destructive action, re-check that the consequence is still stated. Tightening a warning is how a warning stops warning.

Source, version and what was actually read

The judgements above were made against the commit shown on this page. When the published record moves to a different commit, this guide is not displayed, so it cannot end up describing a version nobody re-read.

What was read: the entry file of the project at that commit, in full. It lists the principles, the element patterns, the tone framework, the accessibility section, the benchmark figures, the editing phases and its own file inventory. The referenced companion files and the templates were not opened, so their quality is not judged here. Nothing was installed or executed, no agent was run, and no copy from a real product was processed. The benchmark numbers referred to above are the figures the author cites, reproduced as targets to check against, not as results measured for this listing.