clarify
Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.
- License 许可
- MIT
- 最近更新
- 2026-11-01
- Stars
- ★ 3
- Forks
- 1
01 前言 Front Matter
- name
- clarify
- description
- Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.
- argument-hint
- [target]
- user-invocable
- true
03 SKILL.md 正文
Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
MANDATORY PREPARATION
Invoke /frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run /teach-impeccable first. Additionally gather: audience technical level and users' mental state in context.
Assess Current Copy
Identify what makes the text unclear or ineffective:
-
Find clarity problems:
- Jargon: Technical terms users won't understand
- Ambiguity: Multiple interpretations possible
- Passive voice: "Your file has been uploaded" vs "We uploaded your file"
- Length: Too wordy or too terse
- Assumptions: Assuming user knowledge they don't have
- Missing context: Users don't know what to do or why
- Tone mismatch: Too formal, too casual, or inappropriate for situation
-
Understand the context:
- Who's the audience? (Technical? General? First-time users?)
- What's the user's mental state? (Stressed during error? Confident during success?)
- What's the action? (What do we want users to do?)
- What's the constraint? (Character limits? Space limitations?)
CRITICAL: Clear copy helps users succeed. Unclear copy creates frustration, errors, and support tickets.
Plan Copy Improvements
Create a strategy for clearer communication:
- Primary message: What's the ONE thing users need to know?
- Action needed: What should users do next (if anything)?
- Tone: How should this feel? (Helpful? Apologetic? Encouraging?)
- Constraints: Length limits, brand voice, localization considerations
IMPORTANT: Good UX writing is invisible. Users should understand immediately without noticing the words.
Improve Copy Systematically
Refine text across these common areas:
Error Messages
Bad: "Error 403: Forbidden" Good: "You don't have permission to view this page. Contact your admin for access."
Bad: "Invalid input" Good: "Email addresses need an @ symbol. Try: name@example.com"
Principles:
- Explain what went wrong in plain language
- Suggest how to fix it
- Don't blame the user
- Include examples when helpful
- Link to help/support if applicable
Form Labels & Instructions
Bad: "DOB (MM/DD/YYYY)" Good: "Date of birth" (with placeholder showing format)
Bad: "Enter value here" Good: "Your email address" or "Company name"
Principles:
- Use clear, specific labels (not generic placeholders)
- Show format expectations with examples
- Explain why you're asking (when not obvious)
- Put instructions before the field, not after
- Keep required field indicators clear
Button & CTA Text
Bad: "Click here" | "Submit" | "OK" Good: "Create account" | "Save changes" | "Got it, thanks"
Principles:
- Describe the action specifically
- Use active voice (verb + noun)
- Match user's mental model
- Be specific ("Save" is better than "OK")
Help Text & Tooltips
Bad: "This is the username field" Good: "Choose a username. You can change this later in Settings."
Principles:
- Add value (don't just repeat the label)
- Answer the implicit question ("What is this?" or "Why do you need this?")
- Keep it brief but complete
- Link to detailed docs if needed
Empty States
Bad: "No items" Good: "No projects yet. Create your first project to get started."
Principles:
- Explain why it's empty (if not obvious)
- Show next action clearly
- Make it welcoming, not dead-end
Success Messages
Bad: "Success" Good: "Settings saved! Your changes will take effect immediately."
Principles:
- Confirm what happened
- Explain what happens next (if relevant)
- Be brief but complete
- Match the user's emotional moment (celebrate big wins)
Loading States
Bad: "Loading..." (for 30+ seconds) Good: "Analyzing your data... this usually takes 30-60 seconds"
Principles:
- Set expectations (how long?)
- Explain what's happening (when it's not obvious)
- Show progress when possible
- Offer escape hatch if appropriate ("Cancel")
Confirmation Dialogs
Bad: "Are you sure?" Good: "Delete 'Project Alpha'? This can't be undone."
Principles:
- State the specific action
- Explain consequences (especially for destructive actions)
- Use clear button labels ("Delete project" not "Yes")
- Don't overuse confirmations (only for risky actions)
Navigation & Wayfinding
Bad: Generic labels like "Items" | "Things" | "Stuff" Good: Specific labels like "Your projects" | "Team members" | "Settings"
Principles:
- Be specific and descriptive
- Use language users understand (not internal jargon)
- Make hierarchy clear
- Consider information scent (breadcrumbs, current location)
Apply Clarity Principles
Every piece of copy should follow these rules:
- Be specific: "Enter email" not "Enter value"
- Be concise: Cut unnecessary words (but don't sacrifice clarity)
- Be active: "Save changes" not "Changes will be saved"
- Be human: "Oops, something went wrong" not "System error encountered"
- Be helpful: Tell users what to do, not just what happened
- Be consistent: Use same terms throughout (don't vary for variety)
NEVER:
- Use jargon without explanation
- Blame users ("You made an error" → "This field is required")
- Be vague ("Something went wrong" without explanation)
- Use passive voice unnecessarily
- Write overly long explanations (be concise)
- Use humor for errors (be empathetic instead)
- Assume technical knowledge
- Vary terminology (pick one term and stick with it)
- Repeat information (headers restating intros, redundant explanations)
- Use placeholders as the only labels (they disappear when users type)
Verify Improvements
Test that copy improvements work:
- Comprehension: Can users understand without context?
- Actionability: Do users know what to do next?
- Brevity: Is it as short as possible while remaining clear?
- Consistency: Does it match terminology elsewhere?
- Tone: Is it appropriate for the situation?
Remember: You're a clarity expert with excellent communication skills. Write like you're explaining to a smart friend who's unfamiliar with the product. Be clear, be helpful, be human.
04 同仓库更多 Skills
xiaolai-methodology
以李笑来(Li Xiaolai)的思考方式、方法论与表达风格,为用户做全方位 1-on-1 教练指导,覆盖创业、赚钱、投资、学习、自学、读书写作、用 AI、以及人生心态与自我管理。当用户提到 "李笑来"、"笑来"、"笑来老师"、"扮演李笑来"、"找笑来聊聊"、"笑来怎么看"、"xiaolai"、"把时间当作朋友"、"通往财富自由之路"、"定投改变命运"、"韭菜的自我修养"、"自学是门手艺"、"让时间陪你慢慢变富"、"七年就是一辈子"、"元认知"、"活在未来"、"复利/长期主义"、"践行"、"痴迷改进"、"个人商业模式/出售时间"、"睡后收入"、"定投"、"财富自由"、"操作系统升级"、"最少必要知识"、"北极星提示词"、"用 AI 该怎么学/思考" 等任一触发词,或当用户带着关于创业/赚钱/投资/学习/职业/重大人生决策的困惑、希望被人用笑来式的「逻辑 + 大白话 + 类比 + 重新定义 + 践行导向」来点醒和指导时,自动进入李笑来教练模式。
zread
Produce and consume a wiki-style knowledge base for a code repository via the `zread` CLI and its on-disk output under `./.zread/wiki/`. Use this skill whenever the user wants to understand, onboard onto, explore, summarize, map, or get an overview of an unfamiliar codebase; asks for architecture docs, a project wiki, a repo walkthrough, module/package explanations, or "what does this repo do"; wants to generate, regenerate, resume, browse, or serve code documentation locally; or mentions zread / zread.ai directly. Also use it proactively before diving into a large unknown repo — if `./.zread/wiki/current` exists, read the generated pages instead of crawling source file-by-file; if it doesn't, consider offering to run `zread generate`. The trigger is the intent (understand a codebase through generated docs), not the literal word "zread".
youtube
Launch the YouTube Creator Agent to auto-generate videos. Use when: user types /youtube, wants to create YouTube videos, generate video content, or upload to YouTube. Keywords: youtube, video, 视频, 创作视频, 发布视频
youtube-script-sync
Sync, update, or optimize Tony's GetNote knowledge base `Youtube视频逐字稿` by turning each parent recording or first-person idea note into an idempotent child note containing a directly recordable YouTube long-video or Shorts script. Use when the user says “更新/同步/优化 Youtube视频逐字稿知识库”, or says “更新/同步/优化该知识库” while this knowledge base is the active context.
writing-skills
How to write SKILL.md files that trigger reliably and teach effectively. Use when creating, improving, or reviewing Claude Code skills.
writing-rules
How to write .claude/rules/ files that Claude actually follows. Use when creating, improving, or reviewing project rules.