# Style guides

A style guide tells Workover how your team writes, so you stop repeating it in every brief.

## Two levels

**Workspace** — how your company writes. Voice, spelling convention, the words you use for your own concepts, the things you never say. Applies everywhere.

**Project** — how *this* site writes, layered on top. A developer-docs project and a marketing blog belong to the same company and do not sound the same.

Where they disagree, the project wins. You do not have to repeat the workspace guide inside it.

## What to put in one

The things you correct over and over in review:

- **Voice.** “Plain, direct, second person. No exclamation marks. Contractions are fine.”
- **Spelling and conventions.** British or American. Oxford comma or not. How you write numbers, dates, units.
- **Your vocabulary.** What you call your own features, capitalised how. The words you refuse — “leverage”, “utilise”, “seamless”.
- **Structure.** “Lead with the problem, not a definition.” “Every how-to ends with a Related section.”
- **Claims.** What you may not say about performance, security, or competitors.

Concrete beats abstract. “Never say ‘simply’ or ‘just’ — it makes a reader who is stuck feel stupid” is followed. “Be friendly but professional” is not.

## Where it applies

Every AI draft and every AI revision in that scope. It does not rewrite what you have already written — a style guide is not a linter, and adding one does not change existing documents.

## Keeping it useful

Add to it from review. When you find yourself making the same correction twice, that correction belongs in the guide rather than in your head. A guide assembled this way is short and load-bearing; one written in a single sitting is long and mostly ignored.

## Related

- [Writing a good brief](/docs/writing-a-good-brief)
- [Drafting with AI](/docs/ai-drafting-overview)
- [Core concepts](/docs/core-concepts)