ux-writing
UX Writing
Interface text is the interface talking. This skill makes every string earn its place: concrete, plain, and helpful. A user should know what happened and what to do next without rereading.
Scope
This skill owns every string a user reads: buttons, menu items, labels, placeholders, tooltips, error messages, empty states, confirmations, notifications, onboarding steps.
Neighbors own the rest. Whether an empty state or error state exists at all is ux-check territory; this skill writes the words once the state exists. How text looks (size, contrast, truncation) is ui-polish. This skill decides what strings say, never how they are styled.
Three contested lines, settled here: casing as written is this skill, text-transform applied in CSS is ui-polish, and each files its own finding only against its own artifact. Whether a confirmation dialog should exist is ux-check; this skill writes the one that must exist and does not argue for undo instead. Accessible names (alt, aria-label, title) belong to ux-check whole, existence and wording alike: they are written once, and two owners meant two findings on one string. You touch them only when a string never reaches the catalog on a localized product.
Skills outside this line can own the same ground (better-writing and the like, which allows title case per element type where we do not). If one is loaded, follow the project's choice and say in the report which rule you applied. One string, one finding.