Content Design
It provides options for new copy, reviews existing copy, and ensures consistency with terminology and style guidelines.
Install
npx promptshop add content-designDetails
What This Skill Does
This skill helps design effective UI copy for Saa S products, focusing on clarity and user needs. It provides options for new copy, reviews existing copy, and ensures consistency with terminology and style guidelines. It's ideal for content designers working on complex software interfaces.
When to Use
- Draft new UI copy for a button or modal.
- Review existing UI copy for clarity and conciseness.
- Ensure UI copy adheres to terminology guidelines.
- Design empty state messages that guide users.
- Improve error messages to be more helpful.
- Write tooltips that provide necessary context.
Key Features
- Generates multiple copy options with rationales.
- Suggests i18n keys for new UI copy.
- Reviews copy against terminology and style guides.
- Prioritizes clarity and user needs.
- Provides concise and neutral copy.
- Flags inconsistencies in existing guidelines.
Manual Installation
Manual installation## How to work
Modes
When invoked, determine what the user needs:
Write — Draft new UI copy. Ask what surface (button, modal, tooltip, error, empty state, and so on) and what the user action or system state is. Deliver 1-3 options ranked by recommendation. For each option, include:
- The copy itself
- Which surface it targets (if ambiguous from context)
- Suggested i18n key (following the naming convention below)
- One-line rationale (which guideline it leans on)
Review — The user shares existing copy or points to a file. Check it against every rule below. Return a table:
| Location | Current copy | Issue | Suggested fix |
|---|
Group issues by severity: terminology violations first, then tone, then grammar and formatting. If the copy follows all guidelines, confirm with a brief summary of what was checked (e.g., "Checked against terminology glossary, tone guidelines, grammar rules, and UI patterns — no issues found.").
Audit — Scan a file or set of files (Vue components, i18n JSON) for violations. Use Grep and Glob to find patterns, then report.
Where copy lives in n8n
| Location | What's there |
|---|---|
| packages/frontend/@n8n/i18n/src/locales/en.json | All UI strings (i18n keys) |
| packages/frontend/editor-ui/src/*/.vue | Inline copy in Vue templates |
| packages/frontend/@n8n/design-system/src/*/.vue | Design system component defaults |
| packages/nodes-base/nodes/*/.ts | Node descriptions, parameter labels, placeholders |
| packages/@n8n/nodes-langchain/nodes/*/.ts | AI node descriptions and labels |
| packages/nodes-base/nodes/*/Description.ts | Node parameter display Name, description, action, placeholder fields (hardcoded, not i18n'd) |
| packages/@n8n/nodes-langchain/nodes/*/Description.ts | AI node parameter descriptions (hardcoded, not i18n'd) |
| packages/cli/src/*/.ts | Backend error messages in services/controllers that surface to users (hardcoded) |
When editing copy, prefer changing the i18n JSON (en.json) over hardcoded strings in Vue files. If you find hardcoded user-facing strings in Vue templates, flag them — they should use i18n.
i18n patterns (in order of preference):
i18n.base Text('key') — preferred, most common $t('key') / t('key') — Vue i18n plugin shorthand locale.base Text('key') — legacy pattern, still present in older code
i18n key naming convention
Keys use hierarchical dot-notation matching the feature area:
| Pattern | Example | When to use |
|---|---|---|
| generic.* | generic.cancel, generic.save | Universal labels used across many surfaces |
| feature Area.sub Area.element | settings.community Nodes.empty.title | Feature-scoped copy |
| _reusable Base Text.* | _reusable Base Text.credential | Shared constants referenced by other keys |
| _reusable Dynamic Text.* | _reusable Dynamic Text.simple Input | Shared text with dynamic fallbacks |
When suggesting new keys, follow the existing hierarchy. Browse nearby keys in en.json to match the nesting depth and naming style of the feature area.
Content guidelines
Language and grammar
- US English.
- Always.
- No exceptions. Do: "categorizing", "color", "analyze" Don't: "categorising", "colour", "analyse"
Active voice whenever possible. Do: "Administrators control user access to n8n Cloud." Don't: "User access to n8n Cloud is controlled by administrators."
Sentence case for all titles, headings, menu items, labels, and buttons. Only capitalize the first word and proper nouns. Do: "What triggers this workflow?", "Zoom in" Don't: "What Triggers This Workflow?", "Zoom In"
-
Periods.
-
A single sentence or fragment doesn't need one.
-
If there are. multiple sentences (including in tooltips), all of them need one. "Settings" — single label, no period "New workflow executions will show here." — multiple sentences need periods Not: "Settings."
-
Contractions.
-
Use them.
-
They keep the tone conversational. Do: can't, don't, it's, you'll, we're Don't: cannot, can not, it is, you will, we are
-
Oxford comma.
-
Always. Do: "Connect apps, databases, and APIs." Don't: "Connect apps, databases and APIs."
Abbreviations. Don't use internal abbreviations or jargon in customer-facing copy. Spell out unfamiliar terms on first use. Do: "Role-based access control (RBAC)" Don't: "RBAC" alone without introduction
Plural abbreviations: "APIs" not "API's".
- No Latin abbreviations.
- Use plain alternatives.
| Don't use | Use instead |
|---|---|
| e.g. | for example, such as |
| i.e. | that is, in other words |
| etc. | and so on |
| vs / versus | compared to, or |
| via | through, with, using |
| n.b. | note |
| ad hoc | unscheduled, temporary, bespoke |
| per se | necessarily, intrinsically |
- Dates.
- US format.
- Spell out months when space allows. Do: "Apr 2", "February 14, 2025" Don't: "2. Apr", "02/14/2025"
Times. 24-hour format with leading zero (technical audience). Do: 13:34, 07:52 Don't: 1:34 PM, 7:52
Numbers. Commas for thousands, period for decimals. Do: 23,456 and 346.65 Don't: 23456 and 346,65
Tone and voice
Write like a knowledgeable colleague, not a manual or a marketing page. Be technical when precision matters, but default to plain language.
Do:
- Be direct.
- Lead with the most important information. Use simple words: "use" not "utilize", "so" not "therefore", "but" not "however", "give" not "provide".
- Write short sentences.
- Break complex ideas into smaller pieces. Use humor sparingly and only in low-stakes contexts (tooltip