Menu
Reviews and writes text for clarity, tone, and consistency. Use when writing UI copy, documentation, handbook content, or error messages.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Drives implementation outside-in: starts from an acceptance test for user-visible behavior, then works inward layer by layer, stubbing what doesn't exist yet. Use when building a feature across collaborating components to let design emerge from usage rather than speculation.
Autonomous end-to-end feature development with phased validation gates. Use when building major new functionality or adding substantial features.
End-to-end GitHub issue lifecycle: pick up an issue, create a worktree, build the fix or feature, open a PR, watch CI, and iterate until green. Use when picking up, fixing, or implementing a GitHub issue or ticket.
Decomposes work into ordered, shippable slices. Use when breaking down features, planning implementation order, or slicing work into deliverable increments.
Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.
Refactoring process. Invoke immediately when user or document mentions refactoring, or proactively when code gets too complex or messy.
| name | writing-style |
| description | Reviews and writes text for clarity, tone, and consistency. Use when writing UI copy, documentation, handbook content, or error messages. |
STARTER_CHARACTER = ✍️
Review and write text that's clear, helpful, and human.
Check for existing voice guidelines (docs/handbook, CLAUDE.md, style guides). When found, follow them. When none exist, use the defaults below.
Tone: Friendly and direct. Like a helpful colleague, not a corporate manual.
Qualities:
Avoid dashes and em-dashes. Use colons, periods, or restructure the sentence instead.
Anti-pattern: "Couldn't save — you're offline"
Use action verbs. State what happens, not what the element is.
Anti-patterns:
Destructive actions: be explicit about what will be destroyed.
Help users fix the problem. Structure: what happened, then what to do.
Anti-patterns:
Empty isn't an error. It's an opportunity to guide action.
Anti-patterns:
Be specific. Generic labels force users to guess.
Anti-patterns:
Explain the non-obvious. Don't repeat what's already visible.
Anti-patterns:
Tooltips should explain why, when, or edge cases.
State the consequence clearly. Make the action button match the question.
Anti-patterns:
Same principles apply: clear, concise, human.
Additional considerations:
Pick one term and stick with it. Document choices if the project doesn't have a glossary.
Anti-patterns:
A mini-glossary keeps terms consistent:
place (not: location, spot, point)
adventure map (not: guide, collection)
curator (not: editor, creator, admin)
Avoid patterns that break in translation:
When reviewing copy in a feature or document: