better-writing

Installation
SKILL.md

Writing that disappears into the interface

Clear and brief beats clever, consistency beats variety, and the best error message is the interaction redesigned so the error can't happen. Apply these principles when writing or reviewing any user-facing text.

How copy renders (capitalization via text-transform, truncation, smart punctuation) is covered by the better-typography skill; error markup and announcements (aria-invalid, live regions) by the better-accessibility skill; room for translated strings by the better-layout skill. If those skills are unavailable, keep these local minimums: rendering (capitalize with text-transform only when the source stays natural case, and truncate with text-overflow: ellipsis on a wrapping container); error markup (mark invalid inputs with aria-invalid="true" and tie the visible message to the field with aria-describedby); announcements (announce post-submit results in a live region, e.g. role="status", and keep messages concise); translated strings (leave at least 30% headroom for expansion in buttons, labels, and table headers, and never build copy by concatenating fragments across languages).

Core Principles

1. Recon the Existing Voice

Before writing or reviewing, inspect nearby interface copy, the product's terminology, localization conventions, and any voice or content style guide. Preserve intentional brand character when it remains clear and appropriate to the stakes. Treat a difference from generic plain language as a finding only when it creates inconsistency, ambiguity, translation risk, or an inappropriate tone.

2. One Voice, Flexible Tone

The product has one voice, established by its existing system rather than invented during a local edit. Keep terms consistent: if it's "Archive" in the menu, it isn't "Move to storage" in the toast. Tone flexes with the stakes:

Installs
1
GitHub Stars
5
First Seen
2 days ago
better-writing — bjornmelin/dev-skills