| name | content-style-guide |
| description | Bitwarden's product content style guide for end-user-facing GUI copy — voice, tone, AP-style-with-exceptions grammar, sentence case in UI, and accessibility-first language at a U.S. 7th-grade reading level. |
| when_to_use | Use when end-user-facing GUI strings are being authored or critiqued — button labels, error messages, toasts, modal copy, onboarding, empty states, form labels, helper text, link text. Triggers — "review this copy", "is this error message ok", "rewrite this button label", "check the wording", "what should this say". Composed by `design-review` at 60%/90% stages and by `figma-to-angular` (external, not bundled) during code generation. Not for developer-facing strings, code comments, design tokens, or marketing/long-form content. |
| allowed-tools | Skill |
Product Content Style Guide
This skill grounds GUI copy decisions in Bitwarden's product content style guide. Apply it to
end-user-facing strings only — button labels, error messages, toasts, modals, onboarding flows,
empty states, form labels, helper text, link text, and similar. Do not apply to design tokens,
code comments, internal/dev-facing strings, or marketing copy.
When in doubt about a specific case, ask before changing copy.
Voice and tone
Voice is constant. Tone flexes with context.
Product voice is approachable, encouraging, and transparent — consistent across platforms.
Tone conveys mood and depends on who you're talking to and what's happening. Security is serious
stuff. Users aren't looking for humor or fluff — they want to know their information is safe. So
Bitwarden's product tone is almost always serious and respectful.
Tone spectrums:
- Casual ↔ formal
- Enthusiastic ↔ matter-of-fact
Where common content types land on the tone map (axes: casual ↔ formal × matter-of-fact ↔ enthusiastic):
| Content type | Casual / Formal | Matter-of-fact / Enthusiastic |
|---|
| Success messages | Casual | Enthusiastic |
| Onboarding copy | Casual | Enthusiastic |
| Dialogs | Casual | Matter-of-fact |
| Empty states | Casual | Matter-of-fact (slightly) |
| Labels | Neutral | Matter-of-fact |
| Community | Formal | Enthusiastic |
| Confirmations | Formal | Matter-of-fact |
| Help articles | Formal (slightly) | Neutral |
| Warnings | Formal | Matter-of-fact |
| Error states | Formal | Matter-of-fact |
Examples
Error message — formal, matter-of-fact:
- Good: An error occurred. Please try again.
- Avoid: Uh oh! We goofed. Go ahead and refresh!
Onboarding message — casual, enthusiastic:
- Good: Hey there! 👋 Welcome to Bitwarden. We'll show you around!
- Avoid: This is your vault. Get started now.
Applying this skill
During explicit copy critique ("review this copy", "is this error message ok"):
- Identify the content type (error, onboarding, button, etc.) and the expected tone using the
tone map above.
- Check voice consistency (approachable, encouraging, transparent).
- Walk grammar and mechanics rules relevant to the snippet — see
references/grammar-mechanics.md.
- Walk accessibility rules relevant to the snippet — see
references/accessibility-rules.md.
- Return specific, actionable rewrites — not just "this is wrong."
Inside figma-to-angular runs (external skill in the clients repo, not bundled here):
When the Figma design includes copy strings, validate them against this guide before emitting
them into the Angular template. If a string clearly violates a rule (e.g., title-case button,
ampersand, "Click here" link), surface the issue and propose a compliant alternative — do not
silently rewrite. Ask the user which to use.
Inside design-review critiques:
If the stage is 60% or 90%, include content observations alongside visual feedback (90% is the
right stage for "nitty-gritty grammar, finalizing copy"). Skip content nitpicks at 30% — the
copy will change. Frame content feedback the same way as visual feedback: tied to user/product
goals, not personal taste.
Output format for copy critique
- Content type and expected tone — name what this string is and where it should land on
the tone spectrum.
- What's working — what to keep.
- Issues — each tied to a specific rule from this guide (cite the section name, including
the references file if the rule lives there).
- Proposed rewrite(s) — concrete alternatives the user can pick from.
Keep critique specific. "The button uses title case; sentence case per
references/grammar-mechanics.md (Capitalization)" beats "the capitalization is off."
Additional resources
The detailed rules live in two references files. Load them when the critique needs them — most
copy issues touch only one or two rules.
references/grammar-mechanics.md — Acronyms, ampersands, capitalization (sentence case,
product names, features, lowercase objects), dates and months, days of the week, e.g. / i.e.,
ellipsis, file sizes and formats, money, numbers, Oxford comma, times and time zones, versus.references/accessibility-rules.md — Reading level and directness, scannable layouts,
non-English and ESL considerations, spelling out acronyms, avoiding "easy" and "simple"
framings, text styling, spatial language, alt text, meaningful link text, gender-neutral
pronouns.
