メニュー
Write, review, and improve UX copy -- error messages, button labels, empty states, tooltips, onboarding flows, and all interface microcopy. Use when writing or fixing user-facing text in a product. Outputs production-ready copy with rationale.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | ux-writing |
| description | Write, review, and improve UX copy -- error messages, button labels, empty states, tooltips, onboarding flows, and all interface microcopy. Use when writing or fixing user-facing text in a product. Outputs production-ready copy with rationale. |
| license | MIT |
| args | [{"name":"target","description":"The feature, component, or screen needing copy (optional)","required":false}] |
| user-invokable | true |
Write, review, and improve user-facing interface text so products are easier to understand and use.
STEP 1 — GATHER CONTEXT
Before writing, establish: product/feature, audience (technical? general? first-time?), platform (web/mobile/CLI/email), user's emotional state (mid-task? recovering from error? onboarding?), and constraints (character limits, brand voice, localization). If not provided and not inferable, ask.
Pick a tone: professional-friendly (clear, warm — SaaS default), casual-conversational (relaxed, personality-forward — consumer apps), or technical-precise (minimal, exact — dev tools/CLIs). Let the user override.
STEP 2 — DIAGNOSE (when improving existing copy)
Check for: jargon users won't know, ambiguity, passive voice, wordiness, missing next step, blame language ("You entered invalid..." vs "That doesn't look right..."), tone mismatch, and inconsistency (same concept called different things).
STEP 3 — WRITE OR REWRITE
For each piece of copy, output in this format:
| Location | Original (skip if new) | Improved | Rationale (one line) |
| -------- | ---------------------- | -------- | -------------------- |
When writing a multi-step flow, show the full sequence to verify narrative coherence.
Errors: Plain language + how to fix it + example if format matters. Never blame the user.
Form labels: Specific labels (not generic placeholders). Show format expectations. Explain why you're asking when non-obvious.
Buttons/CTAs: Verb + noun ("Create account", "Delete project"). Avoid "OK", "Submit", "Click here". For destructive actions, name the object.
Empty states: Explain why empty + clear next action. Inviting, not a dead end.
Success: Confirm what happened + what happens next. Match emotional weight.
Loading: Set time expectations. Explain what's happening. Offer cancel for long waits.
Confirmations: Name the action and object. Descriptive button labels ("Delete project" / "Keep project", not "Yes" / "No"). Only for irreversible actions.
Onboarding: One concept per step. Value before effort. Let users skip.
Permission requests: Explain the benefit. Ask in context, not on first load.
Transactional emails: Lead with the action. One CTA. Include fallback instructions.
Accessibility text: Describe function not appearance ("Search" not "Magnifying glass icon"). Concise aria-labels.
Pricing prompts: Lead with value not cost. Be specific about what they get. Respect current plan choice.
Before:
Error: Invalid input
[OK]
After:
That email address doesn't look right — check for typos and try again.
[Update email]
Rationale: Names the field, suggests a fix, uses a specific button label instead of "OK".
STEP 4 — CONSISTENCY CHECK
When reviewing multiple pieces: flag terms used inconsistently (delete vs remove, workspace vs project), inconsistent button patterns, and tone shifts between states. Recommend a single term to standardize on.
STEP 5 — VERIFY
Before delivering, confirm:
you are a wise and incredibly effective teacher. your goal is to make sure the human deeply understands the session.
Iterative deep planning with critiques and alternatives. Use when facing complex design decisions, architecture choices, or implementation strategies that require thorough analysis. Trigger for any request involving "how should I design", "what's the best approach", "help me plan", "architecture decision", "trade-offs between", or when a user is choosing between multiple technical approaches. Also trigger when a proposed plan needs critique or when the stakes of a wrong decision are high. Prefer this skill over a one-shot answer whenever the problem has meaningful complexity, multiple valid approaches, or non-obvious failure modes.
Generates a conventional commit (feat/fix/refactor/docs/chore) with a clear, lowercase message based on staged or unstaged changes.
Enforce the no-useEffect rule when writing or reviewing React code. ACTIVATE when writing React components, refactoring existing useEffect calls, reviewing PRs with useEffect, or when an agent adds useEffect "just in case." Provides the five replacement patterns and the useMountEffect escape hatch.
Animating Base UI components with Motion for React. Use this skill when implementing animations on Base UI components (Menu, Dialog, Popover, Tooltip, Switch, etc.) with the Motion library. Triggers on: motion animation, base-ui animate, animate dropdown, animate dialog, animate popover, exit animation, spring animation, render prop animation, AnimatePresence base-ui.
Reviews code for security (OWASP), performance, accessibility, and quality. Outputs findings by severity (Critical, Warning, Suggestion, Good) with a verdict. Use when reviewing code, diffs, or PRs.