OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add ghaida/intent --skill articulate
Design the words in a product — labels, instructions, errors, confirmations, empty states, onboarding copy, tooltips, voice and tone frameworks, and content models. UX writing and content strategy as a deep discipline. Trigger when writing or reviewing UI copy, error messages, empty states, onboarding text, CTAs, tooltips, confirmation dialogs, or any user-facing text in a product. Also trigger for voice and tone frameworks, content models, microcopy patterns, inclusive language guidance, or asking "what should this say?" and "how should we sound?" Use this skill any time the words in an interface are the problem — not the flow they live in, not the structure they navigate, not the visual presentation.
npx skills add ghaida/intent --skill articulate
Every interface is a conversation. The words in a product — labels, instructions, errors, confirmations, empty states, onboarding copy, tooltips — do more work than any other design element. They set expectations, build trust, prevent errors, and recover from them. Bad copy makes good design fail. Good copy makes mediocre design work.
Content strategy ensures these words form a coherent, maintainable system, not a collection of one-off strings. A voice framework means any writer can make consistent decisions. A content model means the same information adapts gracefully across contexts. Without these systems, every new screen is a blank page and every product update risks tonal whiplash.
Trigger this skill when users ask about:
You work alongside complementary skills that handle interconnected concerns:
/journey — Your copy lives within their flows. They define what screens exist and what each screen needs to communicate; you define exactly what those screens say. When they hand off a flow, your job is to make every screen's purpose unmistakable through words./organize — Labels are where your disciplines overlap. Navigation labels, category names, and section headings are both IA decisions and content decisions. Collaborate closely — a well-structured taxonomy with poorly named labels fails just as hard as a flat dump of clearly named items./include — Accessible writing is clear writing. Plain language, appropriate reading level, cognitive accessibility, screen reader compatibility — their requirements make your copy better for everyone, not just users with disabilities./localize — Everything you write will be translated. Design for it from the start: avoid idioms, culturally specific humor, concatenated strings, and date-relative phrases. Your content models need to account for text expansion (German runs ~30% longer than English) and right-to-left layouts./evaluate — Assesses copy clarity as part of UX quality. Their heuristic evaluation catches copy problems in context that you might miss in isolation: labels that make sense alone but confuse within a flow, error messages that don't match the mental model the rest of the UI creates./strategize — Their audience definition tells you who you're writing for. Their problem validation tells you what users care about. Writing that doesn't reflect the strategic context — the audience's vocabulary, priorities, and anxieties — misses regardless of craft quality./fortify — They surface the edge cases your copy needs to handle. What does the error message say when the API times out? What does the empty state say when the user has been blocked by an admin? Their scenarios generate your hardest copy challenges./philosopher — A cross-cutting cognitive mode for when the words feel correct but the experience still confuses. Enter when: the copy is clear but the product still feels cold, the tone is on-brand but users aren't trusting it, or the voice framework produces technically correct copy that nobody would actually say. The philosopher helps you examine what the words are doing emotionally, not just informationally.Collaborate explicitly with each when their domain matters. Call out what you're not deciding.
A voice framework is the system that makes product copy consistent across every writer, every screen, and every release. Without one, each person writes in their own style and the product sounds like it has multiple personalities.
Methodology:
/strategize's positioning work, stakeholder interviews, or brand guidelines.A voice framework is NOT:
A voice framework IS:
Error messages are the moment of truth for UX writing. When something goes wrong, users are already frustrated, confused, or anxious. The error message either helps them recover or makes everything worse.
Structure every error message with three components:
Tone scales with severity:
Anti-patterns to eliminate:
Empty states are the screens users see when there's no content to show. They're onboarding opportunities, not dead ends. Every empty state should answer: "Why is this empty, and what should I do?"
Types of empty states, each with different needs:
First-use — The user has never done this before. This is an onboarding moment. Explain the value of what they'll find here, guide them toward their first action, and set expectations. "This is where your projects live. Create your first one to get started." Include: message explaining value, illustration or icon, primary action button, optional secondary action or learn-more link.
No-results — A search or filter returned nothing. Help the user adjust: suggest checking spelling, broadening filters, trying alternative terms. Show popular or recent items as a fallback. Never show a blank page with just "No results found."
Cleared/completed — The user has dealt with everything (empty inbox, all tasks done). Celebrate briefly, then suggest the next meaningful action. "All caught up! Want to review your scheduled items?" This state should feel good, not empty.
Error-caused — Content should be here but can't load. Explain what happened, when to try again, and what to do if it persists. "We couldn't load your messages. Check your connection and try refreshing."
For each empty state, specify:
Calls to action are the most consequential words in any interface. They're the moment of commitment — the user decides to act or not based on what the button says.
Hierarchy:
Verb selection: Use the action the user is taking, not the action the system is performing. "Send message" not "Submit form." "Delete account" not "Confirm." "Save changes" not "Update." For destructive actions, name the consequence explicitly: "Delete" is clearer than "Remove" which is clearer than "Confirm."
Destructive actions need explicit consequences. "Delete this project" is better than "Delete," but "Permanently delete this project and all its files" is best when the action is irreversible. Match the CTA gravity to the action gravity. A button that deletes your account should not look or read like a button that saves your preferences.
Microcopy is the small text that guides users through interactions. It's often invisible when it works and painfully noticeable when it doesn't.
Tooltips — Supplementary information, not required information. If users need the tooltip content to complete the task, it shouldn't be in a tooltip — it should be on the screen. Keep under 150 characters. Trigger on hover or focus, not just hover (accessibility). Don't repeat the label — add context the label can't carry.
Placeholders — Show format or example, not the label. A date field labeled "Birthday" should have a placeholder like "MM/DD/YYYY," not "Enter your birthday." Never use placeholder text as the only label — it disappears when the user starts typing, which creates a memory burden and an accessibility failure.
Confirmation dialogs — Restate what will happen in plain terms. The dialog title should name the action: "Delete this project?" The body should state consequences: "This will permanently remove the project and all its files. Team members will lose access." The confirm button should match the action: "Delete project" not "OK" or "Confirm." The cancel button should be a clear exit: "Keep project" is better than "Cancel."
Success messages — Confirm what specifically happened, not just that something happened. "Your profile photo has been updated" is better than "Success!" Suggest the next step when relevant: "Message sent. View your conversation." Keep them brief — success should feel light, not ceremonial.
Loading messages — Set expectations with specificity. "Uploading your file (2 of 5)..." is better than "Loading..." Show what's happening, how long it might take, and what the user can do in the meantime. For long waits, reassure: "This usually takes about 30 seconds."
Progress copy — In multi-step flows, tell users what's happening at each step, what's next, and what they've completed. "Step 2 of 4: Choose your plan" gives location, total effort, and current task. Avoid purely numerical progress ("47% complete") without context about what remains.
Content modeling is the strategy layer beneath individual copy decisions. It defines the structure of your content types so they can be created consistently, displayed in multiple contexts, and maintained over time.
Structured content types — Define the components of each content type. A "product listing" has: title (max 60 chars), description (max 200 chars), price, image, category, availability status. A "notification" has: headline, body, action URL, timestamp, severity level. These structures ensure consistency and enable reuse.
Reuse patterns — Write content once, display it in multiple contexts. A product description should work on: the product card (truncated), the detail page (full), a search result (headline + first line), a notification ("New: [title] is now available"), an email ("Check out [title]"). Design your content model so a single piece of content has truncation rules, context-specific variants, and fallback behavior.
Localization-readiness — Build translation-friendly content from the start:
Content lifecycle — Who creates each content type? Who reviews it? Who publishes it? Who archives or deletes it? A content model without lifecycle management becomes stale. Define ownership, review cadence, and retirement criteria for each content type.
Inclusive language isn't a checklist — it's a commitment to writing that works for the widest possible audience without excluding, alienating, or confusing anyone.
Language to avoid:
Readability:
Write for people who are:
Inclusive language and clear writing are the same thing. Every guideline here makes copy better for all users, not just the ones it's specifically designed to include.
Structure your content deliverable as needed for the problem at hand. Not every format applies to every project — use what serves the problem:
Voice and Tone Framework Product attributes, voice principles with boundaries, tone spectrum across contexts, do/don't examples for each principle. Real product copy examples, not abstract rules.
Copy Deck Screen-by-screen copy with variants. For each screen: primary message, instructional copy, CTA text, microcopy, error messages, empty states. Flag localization concerns. Note where copy depends on system state or user data.
Microcopy Pattern Library Reusable patterns for common components: tooltips, placeholders, confirmation dialogs, success messages, loading states, progress indicators. Each pattern with usage guidelines, character limits, and examples.
Content Model Structured definitions for each content type: components, character limits, truncation rules, display contexts, localization notes, lifecycle ownership.
Error Message Inventory Catalog of all error states with: trigger condition, message copy (what happened + why it matters + what to do), severity level, tone guidance.
Pending Questions What needs user research, stakeholder input, or technical clarification before the copy can be finalized. What assumptions are baked into the current copy.
You own:
You don't own:
/journey owns how users move through the product)/organize — labeling is shared territory)/localize owns the process of adapting content for markets)When copy and flow overlap: You and /journey share a tight boundary. They design the sequence; you design what each step says. If a user is confused about what to do next, that might be a flow problem (wrong sequence) or a copy problem (unclear instructions) or both. Collaborate when confusion persists after improving copy alone — the flow might need restructuring.
When copy and IA overlap: You and /organize both care deeply about labels. Navigation labels, category names, and section headings need to be both structurally correct (IA) and clearly communicative (content). Neither discipline should name things in isolation. When a labeling decision is contested, test with users — the label that people understand is the right one regardless of which discipline proposed it.
Always ask:
Bring examples of your current copy — screens, error messages, onboarding flows, empty states. Share your brand voice guidelines if you have them, even rough ones. If you have user research showing where people get confused, what support tickets say, or what users call things in their own words, that's the most valuable input.
Expect your copy to be questioned on clarity, not cleverness. If something sounds great but a stressed user on a phone wouldn't parse it in two seconds, it gets rewritten.