Write clear, specific app microcopy — button labels, empty states, error messages, onboarding text, form labels and helper text, tooltips, and confirmation/success messages.
SkillScore100Maintained
Automatic
◆Writing & Editing pack
Last verified 8/3/2026
What it changes
Passed 22 of 22 test cases with the skill, and 21 of 22 without it.
Without skill95%
With skill100%
Checks it passed that the model alone missed
Provides explicit date formatting guidance such as YYYY-MM-DD.
1 fixed21 passed either way0 still failing0 broke
Pass-rate lift
+5 pp
Tokens
+61%
Agent turns
0%
Response time
-26%
Model gemini-3.6-flashMeasured 8/3/2026v122 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
Draft form field helper microcopy for a date filter input control in a data export dialog.
What was checked, without and with the skill
Checked
Without skill
With skill
Provides explicit date formatting guidance such as YYYY-MM-DD.
Missed
Passed
case-19 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md65 linessingle file
Write Product Text Skill
Purpose
Write app microcopy that is clear, specific, and useful — helping users understand what happened, what to do next, and what an action will do.
When to Use
Implementing UI that needs labels, messages, or copy not explicitly provided.
Writing or improving error messages, empty states, confirmations, or onboarding text.
Reviewing existing copy that is vague, generic, or unclear.
When Not to Use
Marketing pages, blog posts, or long-form content (different skill/process).
The exact copy has already been specified by the user/design and just needs to be implemented as-is.
Required Inputs
The context: what screen/state/action this text supports.
The user's goal at that moment.
Any existing tone/voice conventions in the app (check existing copy for tone).
Assumptions
Existing copy style/tone in the app should be matched unless asked to change it.
Copy should describe the actual behavior — never describe a state or action that isn't real.
Step-by-Step Workflow
Identify the context: what screen, what state (empty, error, loading, success, confirmation), what action.
Identify the user's question at this moment: e.g. "what went wrong?", "what happens if I click this?", "is this empty because there's no data, or because of a filter?"
Draft copy that answers that question directly:
Buttons: describe the action (e.g. "Save changes", "Delete project", not "Submit" or "OK" for consequential actions).
Empty states: explain why it's empty and what to do next (e.g. "No projects yet — create your first project to get started.").
Error messages: state what went wrong and, if possible, what to do (e.g. "Couldn't save changes. Check your connection and try again.").
Confirmations: state what was completed and any relevant next step (e.g. "Project deleted.").
Form helper text: reduce confusion before the user makes a mistake (e.g. format hints, requirements).
Onboarding: short, action-oriented, focused on the immediate next step.
Match existing tone/voice: check similar existing copy in the app for formality, terminology, and phrasing patterns.
Keep it concise: remove filler words; one clear sentence is usually better than two vague ones.
Avoid generic AI-sounding phrasing (e.g. "Oops! Something went wrong!", "Great job!", "Let's get started!") unless this matches the app's established voice.
Rules and Best Practices
Button labels describe the action, especially for consequential actions (delete, remove, cancel subscription).
Error messages should never be vague placeholders like "An error occurred" when a more specific message is reasonably available.