clarify

Name: clarify
Author: heyhank-app

30stars13forks

How to install clarify?

heyhank-app/heyhank/clarify

$npx -y skills add heyhank-app/heyhank --skill clarify

Installs into the current project.

Summary

Improve unclear UX copy, error messages, microcopy, labels, and instructions. Makes interfaces easier to understand and use.

Files · 1

View on GitHub

SKILL.md

1	Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
2
3	## Assess Current Copy
4
5	Identify what makes the text unclear or ineffective:
6
7	1. Find clarity problems:
8	- Jargon: Technical terms users won't understand
9	- Ambiguity: Multiple interpretations possible
10	- Passive voice: "Your file has been uploaded" vs "We uploaded your file"
11	- Length: Too wordy or too terse
12	- Assumptions: Assuming user knowledge they don't have
13	- Missing context: Users don't know what to do or why
14	- Tone mismatch: Too formal, too casual, or inappropriate for situation
15
16	2. Understand the context:
17	- Who's the audience? (Technical? General? First-time users?)
18	- What's the user's mental state? (Stressed during error? Confident during success?)
19	- What's the action? (What do we want users to do?)
20	- What's the constraint? (Character limits? Space limitations?)
21
22	CRITICAL: Clear copy helps users succeed. Unclear copy creates frustration, errors, and support tickets.
23
24	## Plan Copy Improvements
25
26	Create a strategy for clearer communication:
27
28	- Primary message: What's the ONE thing users need to know?
29	- Action needed: What should users do next (if anything)?
30	- Tone: How should this feel? (Helpful? Apologetic? Encouraging?)
31	- Constraints: Length limits, brand voice, localization considerations
32
33	IMPORTANT: Good UX writing is invisible. Users should understand immediately without noticing the words.
34
35	## Improve Copy Systematically
36
37	Refine text across these common areas:
38
39	### Error Messages
40	Bad: "Error 403: Forbidden"
41	Good: "You don't have permission to view this page. Contact your admin for access."
42
43	Bad: "Invalid input"
44	Good: "Email addresses need an @ symbol. Try: name@example.com"
45
46	Principles:
47	- Explain what went wrong in plain language
48	- Suggest how to fix it
49	- Don't blame the user
50	- Include examples when helpful
51	- Link to help/support if applicable
52
53	### Form Labels & Instructions
54	Bad: "DOB (MM/DD/YYYY)"
55	Good: "Date of birth" (with placeholder showing format)
56
57	Bad: "Enter value here"
58	Good: "Your email address" or "Company name"
59
60	Principles:
61	- Use clear, specific labels (not generic placeholders)
62	- Show format expectations with examples
63	- Explain why you're asking (when not obvious)
64	- Put instructions before the field, not after
65	- Keep required field indicators clear
66
67	### Button & CTA Text
68	Bad: "Click here" \| "Submit" \| "OK"
69	Good: "Create account" \| "Save changes" \| "Got it, thanks"
70
71	Principles:
72	- Describe the action specifically
73	- Use active voice (verb + noun)
74	- Match user's mental model
75	- Be specific ("Save" is better than "OK")
76
77	### Help Text & Tooltips
78	Bad: "This is the username field"
79	Good: "Choose a username. You can change this later in Settings."
80
81	Principles:
82	- Add value (don't just repeat the label)
83	- Answer the implicit question ("What is this?" or "Why do you need this?")
84	- Keep it brief but complete
85	- Link to detailed docs if needed
86
87	### Empty States
88	Bad: "No items"
89	Good: "No projects yet. Create your first project to get started."
90
91	Principles:
92	- Explain why it's empty (if not obvious)
93	- Show next action clearly
94	- Make it welcoming, not dead-end
95
96	### Success Messages
97	Bad: "Success"
98	Good: "Settings saved! Your changes will take effect immediately."
99
100	Principles:
101	- Confirm what happened
102	- Explain what happens next (if relevant)
103	- Be brief but complete
104	- Match the user's emotional moment (celebrate big wins)
105
106	### Loading States
107	Bad: "Loading..." (for 30+ seconds)
108	Good: "Analyzing your data... this usually takes 30-60 seconds"
109
110	Principles:
111	- Set expectations (how long?)
112	- Explain what's happening (when it's not obvious)
113	- Show progress when possible
114	- Offer escape hatch if appropriate ("Cancel")
115
116	### Confirmation Dialogs
117	Bad: "Are you sure?"
118	Good: "Delete 'Project Alpha'? This can't be undone."
119
120	Principles:
121	- State the specific action
122	- Explain consequences (especially for destructive actions)
123	- Use clear button labels ("Delete project" not "Yes")
124	- Don't overuse confirmations (only for risky actions)
125
126	### Navigation & Wayfinding
127	Bad: Generic labels like "Items" \| "Things" \| "Stuff"
128	Good: Specific labels like "Your projects" \| "Team members" \| "Settings"
129
130	Principles:
131	- Be specific and descriptive
132	- Use language users understand (not internal jargon)
133	- Make hierarchy clear
134	- Consider information scent (breadcrumbs, current location)
135
136	## Apply Clarity Principles
137
138	Every piece of copy should follow these rules:
139
140	1. Be specific: "Enter email" not "Enter value"
141	2. **Be conc

People who liked this also viewed

6 picks

Type

lark-openapi-explorer飞书/Lark 原生 OpenAPI 探索：从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足，需要查找并调用原生飞书 OpenAPI 时使用。SkillsJul 2026378k16k
lark-skill-maker创建 lark-cli 的自定义 Skill。当用户需要把飞书 API 操作封装成可复用的 Skill（包装原子 API 或编排多步流程）时使用。SkillsJul 2026377k16k
azure-cost-optimizationOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026209k1.3k
vercel-react-native-skillsVercel's official collection of agent skillsSkillsJul 2026172k29k
mcp-builderGuide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate externaSkillsJul 202693k163k
gws-sharedgws CLI: Shared patterns for authentication, global flags, and output formatting.SkillsJul 202653k30k

clarify

30stars13forks

View on GitHub

How to install clarify?

heyhank-app/heyhank/clarify

$npx -y skills add heyhank-app/heyhank --skill clarify

Installs into the current project.

Summary

Improve unclear UX copy, error messages, microcopy, labels, and instructions. Makes interfaces easier to understand and use.

Files · 1

View on GitHub

SKILL.md

1	Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
2
3	## Assess Current Copy
4
5	Identify what makes the text unclear or ineffective:
6
7	1. Find clarity problems:
8	- Jargon: Technical terms users won't understand
9	- Ambiguity: Multiple interpretations possible
10	- Passive voice: "Your file has been uploaded" vs "We uploaded your file"
11	- Length: Too wordy or too terse
12	- Assumptions: Assuming user knowledge they don't have
13	- Missing context: Users don't know what to do or why
14	- Tone mismatch: Too formal, too casual, or inappropriate for situation
15
16	2. Understand the context:
17	- Who's the audience? (Technical? General? First-time users?)
18	- What's the user's mental state? (Stressed during error? Confident during success?)
19	- What's the action? (What do we want users to do?)
20	- What's the constraint? (Character limits? Space limitations?)
21
22	CRITICAL: Clear copy helps users succeed. Unclear copy creates frustration, errors, and support tickets.
23
24	## Plan Copy Improvements
25
26	Create a strategy for clearer communication:
27
28	- Primary message: What's the ONE thing users need to know?
29	- Action needed: What should users do next (if anything)?
30	- Tone: How should this feel? (Helpful? Apologetic? Encouraging?)
31	- Constraints: Length limits, brand voice, localization considerations
32
33	IMPORTANT: Good UX writing is invisible. Users should understand immediately without noticing the words.
34
35	## Improve Copy Systematically
36
37	Refine text across these common areas:
38
39	### Error Messages
40	Bad: "Error 403: Forbidden"
41	Good: "You don't have permission to view this page. Contact your admin for access."
42
43	Bad: "Invalid input"
44	Good: "Email addresses need an @ symbol. Try: name@example.com"
45
46	Principles:
47	- Explain what went wrong in plain language
48	- Suggest how to fix it
49	- Don't blame the user
50	- Include examples when helpful
51	- Link to help/support if applicable
52
53	### Form Labels & Instructions
54	Bad: "DOB (MM/DD/YYYY)"
55	Good: "Date of birth" (with placeholder showing format)
56
57	Bad: "Enter value here"
58	Good: "Your email address" or "Company name"
59
60	Principles:
61	- Use clear, specific labels (not generic placeholders)
62	- Show format expectations with examples
63	- Explain why you're asking (when not obvious)
64	- Put instructions before the field, not after
65	- Keep required field indicators clear
66
67	### Button & CTA Text
68	Bad: "Click here" \| "Submit" \| "OK"
69	Good: "Create account" \| "Save changes" \| "Got it, thanks"
70
71	Principles:
72	- Describe the action specifically
73	- Use active voice (verb + noun)
74	- Match user's mental model
75	- Be specific ("Save" is better than "OK")
76
77	### Help Text & Tooltips
78	Bad: "This is the username field"
79	Good: "Choose a username. You can change this later in Settings."
80
81	Principles:
82	- Add value (don't just repeat the label)
83	- Answer the implicit question ("What is this?" or "Why do you need this?")
84	- Keep it brief but complete
85	- Link to detailed docs if needed
86
87	### Empty States
88	Bad: "No items"
89	Good: "No projects yet. Create your first project to get started."
90
91	Principles:
92	- Explain why it's empty (if not obvious)
93	- Show next action clearly
94	- Make it welcoming, not dead-end
95
96	### Success Messages
97	Bad: "Success"
98	Good: "Settings saved! Your changes will take effect immediately."
99
100	Principles:
101	- Confirm what happened
102	- Explain what happens next (if relevant)
103	- Be brief but complete
104	- Match the user's emotional moment (celebrate big wins)
105
106	### Loading States
107	Bad: "Loading..." (for 30+ seconds)
108	Good: "Analyzing your data... this usually takes 30-60 seconds"
109
110	Principles:
111	- Set expectations (how long?)
112	- Explain what's happening (when it's not obvious)
113	- Show progress when possible
114	- Offer escape hatch if appropriate ("Cancel")
115
116	### Confirmation Dialogs
117	Bad: "Are you sure?"
118	Good: "Delete 'Project Alpha'? This can't be undone."
119
120	Principles:
121	- State the specific action
122	- Explain consequences (especially for destructive actions)
123	- Use clear button labels ("Delete project" not "Yes")
124	- Don't overuse confirmations (only for risky actions)
125
126	### Navigation & Wayfinding
127	Bad: Generic labels like "Items" \| "Things" \| "Stuff"
128	Good: Specific labels like "Your projects" \| "Team members" \| "Settings"
129
130	Principles:
131	- Be specific and descriptive
132	- Use language users understand (not internal jargon)
133	- Make hierarchy clear
134	- Consider information scent (breadcrumbs, current location)
135
136	## Apply Clarity Principles
137
138	Every piece of copy should follow these rules:
139
140	1. Be specific: "Enter email" not "Enter value"
141	2. **Be conc

People who liked this also viewed

6 picks

Type