Building a Prompt Style Guide for Your Company

TL;DR: A prompt style guide is a one-to-two-page company standard for how people write AI prompts: one shared prompt structure, approved tone words, company-wide constraints, formatting defaults and data rules. Write it once, then put it into reusable pieces (templates, a saved context, variables) so people follow it without rereading it.

Ask five colleagues to get an AI assistant to write the same customer email and you'll get five different prompts and five different emails. One is formal, one uses a phrase legal banned last year, one invents a discount. None of them is wrong, exactly. There's just no standard.

A prompt style guide fixes that. It's not the same as your brand style guide, which governs finished writing. This one governs the instructions that produce the writing. If you already have a brand guide and want to turn it into something an AI can use, turning a style guide into a reusable context covers that conversion. This post is about the rules for writing prompts themselves.

What is a prompt style guide, and why does a company need one?

It's a short set of company conventions for prompts: structure, tone, constraints, formatting and data handling. A company needs one for the same reason it needs a brand guide. Without it, quality depends on whoever happened to write the prompt.

Anthropic's prompting guide makes the underlying point well: "Think of Claude as a brilliant but new employee who lacks context on your norms and workflows." Every prompt a colleague writes is a briefing for that new employee. If each person briefs differently, the work comes back different.

The guide also gives a simple test that works as a company rule: "Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too." A style guide is how you make that test pass by default.

The practical payoffs:

• Consistent output across people and teams.
• Faster onboarding. New starters copy the standard instead of inventing their own.
• Fewer risky prompts. Data rules live in one place instead of in people's memory.
• Shareable prompts. A prompt written to the standard can be picked up by anyone.

What sections belong in a prompt style guide?

Seven, and each should fit on a few lines.

1. Standard structure. The skeleton every prompt follows.
2. Tone vocabulary. The approved words for describing voice, and what each means.
3. Company-wide constraints. Banned phrases, claims that need approval, fact-handling rules.
4. Formatting defaults. Headings, lists, length, date and number formats.
5. Data rules. What must never be pasted into a prompt.
6. Naming and storage. How shared prompts are titled and where they live.
7. Ownership and review. Who maintains the guide and how often it changes.

Resist adding more. A prompt guide that runs to ten pages will be skimmed once and forgotten. Detail belongs in the reusable pieces described later.

What prompt structure should everyone use?

One skeleton, with labelled sections, used for every shared prompt. The exact labels matter less than everyone using the same ones.

Anthropic recommends structuring prompts with tags and advises: "Use consistent, descriptive tag names across your prompts." That translates directly into a company rule. Here's a skeleton you can adopt:

<role>
[Who the model should act as, in one sentence]
</role>

<context>
[Background the model needs: audience, product, situation]
</context>

<task>
[What to produce, in one or two sentences]
</task>

<constraints>
[Company-wide rules + task-specific rules]
</constraints>

<format>
[Length, structure, headings, bullet style]
</format>

<input>
[The material to work on: notes, a draft, data]
</input>

Plain headings (ROLE, CONTEXT, TASK and so on) work just as well if your team finds tags fussy. Pick one style and write it into the guide. Mixed styles are how a shared library becomes unreadable.

How do you standardise tone across a team?

Replace vague adjectives with a small, defined vocabulary. "Professional" means something different to every person who types it. A defined list does not.

Write down three to six tone words and one line each on what they mean for your company:

Then require prompts to use only these words when describing tone, ideally with an example sentence. Anthropic's guide notes that examples are "one of the most reliable ways to steer Claude's output format, tone, and structure." A single approved example paragraph per tone does more than a paragraph of adjectives.

For deeper guidance on the voice itself, building a brand-voice context walks through capturing it.

Which constraints should apply to every prompt?

The ones that protect the company. Task-specific constraints change prompt by prompt; these stay fixed.

A good company-wide set looks like this:

• Facts come from the input. The model must not invent prices, dates, names, statistics or quotes. Missing facts appear as a bracketed note to check.
• Banned phrases. The list legal, brand or leadership has ruled out.
• Claims needing approval. Guarantees, comparisons with named competitors, health or financial claims.
• No personal data in outputs unless the task requires it.
• Output language and spelling standard (for example, UK English).

Write these once, word for word, so they can be pasted or stored as a unit. Paraphrased versions drift.

A copy-paste prompt style guide template

Adapt this into your own document. It's deliberately short.

PROMPT STYLE GUIDE: [COMPANY NAME]
Owner: [NAME]   Last reviewed: [DATE]   Next review: [DATE]

1. STRUCTURE
Every shared prompt uses these sections, in this order:
ROLE / CONTEXT / TASK / CONSTRAINTS / FORMAT / INPUT

2. TONE
Describe tone only with these words: [Direct, Warm, Plain, Confident, Formal]
Definitions and example sentences: [LINK OR SECTION]

3. COMPANY-WIDE CONSTRAINTS (paste into every prompt, or switch on the saved context)
- Use only facts given in the input. Mark missing facts as [CHECK: ...].
- Never use: [BANNED PHRASES]
- Do not make [guarantees / competitor comparisons / health claims] without approval.
- Spelling: [UK / US] English. Dates: [FORMAT]. Currency: [FORMAT].

4. FORMATTING DEFAULTS
- Lead with the answer. Short paragraphs. Bullets for lists of 3+.
- Default length: [e.g. under 200 words unless the task says otherwise]

5. DATA RULES: never paste
- Customer personal data, payment details, passwords or access codes
- [Unreleased financials / client names / other]

6. NAMING AND STORAGE
- Shared prompts live in: [LIBRARY]
- Name format: [Team] - [Task] - [Output], e.g. "Support - Refund reply - Email"

7. CHANGES
Suggest changes to [OWNER]. The guide is reviewed [monthly / quarterly].

How do Contexts turn the guide into something people actually use?

By storing the fixed parts once, so nobody retypes them. A guide that relies on people remembering seven sections will be followed on good days only. A saved context holding the tone definitions and company-wide constraints can be switched on in a second.

In Prompt Architects, this is Personal Context, available on Pro and up. You save the text once, then switch on Personal Context and pick the one you want when you write a prompt. Two points to be precise about:

• It's applied manually, not automatically. Nothing injects your rules into every prompt behind the scenes. Someone has to switch the context on. That's a feature for flexibility and a limit for enforcement, and your guide should say "switch on the company context" as a step.
• Each context holds up to 5,000 characters. That's plenty for tone definitions and constraints, but not for a full brand manual. Keep the context to the rules; link the long document elsewhere.

A sensible split is one context for company-wide constraints and tone, plus separate contexts for audiences or products that only some prompts need.

How do variables keep company facts consistent?

By storing short facts once and inserting them everywhere. In Prompt Architects, a global variable uses the syntax {{variable_id}} with a lowercase, underscored name, such as {{company_name}} or {{support_email}}. The value is filled in when you copy the prompt. Change the value once and every prompt using it picks up the change.

Variables are for short values. A paragraph of tone guidance belongs in a context, not a variable. Your style guide can list the approved variable names so everyone uses the same ones; reusable prompt variables for dev teams shows the same idea applied to engineering context.

What does a prompt look like before and after the guide?

The difference is easiest to see side by side. Here's a typical unguided prompt from a support team:

write a nice reply to this customer who is angry about a late refund, be professional
[PASTE EMAIL]

And the same request written to the guide:

ROLE: Support specialist at [COMPANY NAME].
CONTEXT: The customer's refund is [N] days later than our stated timeline. Cause: [REASON FROM TICKET].
TASK: Draft a reply that apologises once, explains the delay and gives the new date.
CONSTRAINTS: Company context ON. Use only facts from the ticket. No compensation offers. Mark missing facts as [CHECK: ...].
FORMAT: Tone: Direct, Warm. Under 120 words. No bullet points.
INPUT: [PASTE EMAIL AND TICKET NOTES]

The second version takes a few seconds longer to fill in, and most of it is already in the template. What it removes is the guesswork: the model knows the facts, the limits and the length, and any colleague reading the prompt knows exactly what was asked.

Where should each part of the guide live?

How do you roll the guide out and keep it current?

Start with the prompts people already use most, not a blank page. Take your ten most-reused prompts, rewrite them to the new structure, and put them in the shared library. People adopt standards through the templates they copy far more than through documents they're sent.

Then keep it alive:

1. Name one owner. A guide owned by everyone is maintained by no one.
2. Review on a schedule. Monthly for the first quarter, then quarterly.
3. Fix prompts in place. When you find a shared prompt that breaks the guide, update it rather than emailing the author.
4. Record changes. A short change log at the top of the guide is enough. For shared prompts themselves, version control for team prompts without Git covers practical options.
5. Collect examples. Good outputs become the example paragraphs in your tone section.

For marketing teams specifically, the marketing team prompt playbook shows how a shared library keeps campaigns consistent. If your first standardised prompts are recurring ones like daily updates, using AI in standups and status reporting is a good place to start. And if you need budget for a shared tool to hold all this, how to pitch an AI tool to your boss has a template.

Where does Prompt Architects fit?

As the place the reusable parts live. Pro ($4.99 a month at the time of writing, September 17, 2026, during a launch promotion) saves up to 50 prompts and includes Personal Context. Advanced ($9.99 a month) removes the prompt library cap. Team ($10 a month plus $3.50 per member, 2 to 20 teammates) shares one prompt library across the team, which is what makes a style guide practical at company scale. The Free plan gives 5 prompt enhancements a day according to our FAQ, but it can't save prompts or use Personal Context, so it won't hold a style guide. Current numbers are on pricing.

To be clear about the limit: we don't audit prompts against your guide or block non-compliant ones. The guide still needs an owner and a review habit. What we remove is the friction of following it.

A short guide, one shared structure, a small tone vocabulary and fixed constraints, all stored somewhere people can switch on in a click. That's a prompt style guide that actually gets used.

Sources, read September 17, 2026: Anthropic, Prompting best practices · Prompt Architects pricing · Prompt Architects FAQ