ui-copy
Writing Interface Strings
Default posture: every string names the object and the outcome, in the reader's words, in sentence case, with nothing hedged. Two structural laws carry most of the work — a button says what will happen when it is pressed, and an error says what happened and what to do next, in that order. Generic strings are the single loudest signal that nobody designed the surface: Submit, Invalid input and Something went wrong are three different ways of refusing to say anything. ui-states decides when an empty, loading, error or offline state appears and how it is anchored; this skill writes the words that go inside it — if the question is "when does this show" or "skeleton or spinner", that is ui-states, not this. Field label placement and validation timing are forms. The type the strings are set in is typography.
Read the product's existing strings before writing one. Detect the established voice and copy it: sentence case or title case, Sign in or Log in, you or the workspace name, whether errors address the user or describe the system. Detect the i18n mechanism too — a message catalog, next-intl, or strings hardcoded in JSX — and add new strings where the existing ones live. Introducing a second word for the same object, or a second casing convention, costs more than any individual string is worth; if the app already says Log in, write Log in even when Sign in is better.
Quick Reference
| Open this | When |
|---|---|
| patterns.md | You need the actual replacement string for a specific surface — a destructive confirm, a validation error, an empty state, a toast — rather than the rule behind it. |