Writing

This skill writes and reviews interface copy such as labels, errors, empty states and confirmations, along with the terms that run through them. It matches the product's existing voice and flags copy that misleads people or leaves them without a way forward.

A deliberate brand voice is not a defect. Raise a departure from plain language only when it creates inconsistency, ambiguity, translation risk or a tone the stakes don't support. Rewording that merely suits your taste is not a finding.

How copy renders, including text-transform, truncation and smart punctuation, belongs to better-typography. Error markup, announcements and the attributes that carry accessible names belong to better-accessibility. Room for translated strings belongs to better-layout.

Inventory the existing strings first

Before writing or reviewing, find where the copy lives and read the copy around the change:

1. Search for the translation call (t(, i18n., <FormattedMessage, $t() and the locale files it reads, such as locales/**/*.json, messages/*.json, *.po and *.strings. Copy may also come from a CMS or the API.
2. List the noun used for each object and the verb used for each action, as in "project" or "workspace" and "Delete" or "Remove".
3. Note the case used per element type and any voice or content style guide.

New copy uses the terms on that list. A synonym is a finding only where the same thing is named two ways.

One voice, one vocabulary

The product has one voice and its existing copy establishes it. A local edit does not get to invent a new one. If it's "Archive" in the menu, it isn't "Move to storage" in the toast.

A multi-step flow uses one vocabulary throughout: "Get started" to enter, either "Continue" or "Next" to advance, "Done" to finish. Tone flexes with the stakes: