메뉴
Reviews and writes text for clarity, tone, and consistency. Use when writing UI copy, documentation, handbook content, or error messages.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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: