About
Generate UX microcopy in StyleSeed's Toss-inspired voice for buttons, empty states, errors, toasts, confirmations, and form guidance.
name: ux-copy description: "Generate UX microcopy in StyleSeed's Toss-inspired voice for buttons, empty states, errors, toasts, confirmations, and form guidance." category: design risk: safe source: community source_repo: bitjaru/styleseed source_type: community date_added: "2026-04-08" author: bitjaru tags: [ux, copywriting, microcopy, frontend, styleseed] tools: [claude, cursor, codex, gemini]
UX Copy
Overview
Part of StyleSeed, this skill generates concise product copy for common UI states. It follows the Toss-inspired tone: casual but polite, direct, active, and specific enough to help the user recover or proceed.
When to Use
- Use when you need button labels, helper text, toasts, empty states, or error messages
- Use when a feature has functional UI but weak or robotic wording
- Use when you want consistent product voice across a flow
- Use when confirmation dialogs or state feedback need better phrasing
Tone Rules
- casual but polite
- active voice over passive voice
- positive framing where it stays honest
- plain language instead of internal jargon
- concise wording where every word earns its place
Common Patterns
Buttons
Use a short action verb plus object when needed.
Empty States
Start with a friendly observation, then suggest the next action.
Errors
Explain what happened in user-facing language and what to do next. Do not surface raw internal error strings.
Toasts
Confirm the result quickly. Add an undo action for reversible destructive behavior.
Forms
Use clear labels, useful placeholders, specific helper text, and corrective error messages.
Confirmation Dialogs
State the action in plain language and explain the consequence if the decision is risky or irreversible.
Output
Return:
- The requested microcopy grouped by UI surface
- Notes on tone or localization considerations if relevant
- Any places where the UX likely needs a structural fix in addition to better copy
Best Practices
- Make the next action obvious
- Avoid generic labels like "Submit" or "OK" when the action can be named precisely
- Blame the system, not the user, when something fails
- Keep error and empty states useful even without visual context
Additional Resources
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.