Tone and Voice Specification System Prompt

This playbook is for product designers, brand teams, and AI engineers who need a reusable, machine-enforceable tone profile for an AI assistant. Use this prompt when you must define formality, directness, empathy, and stylistic constraints that survive dozens of conversation turns without drifting into a generic or off-brand voice. The core job-to-be-done is translating an existing brand voice or product tone guide into a system prompt that functions as a behavioral contract, not a loose suggestion. You are not discovering your voice here; you are hardening it for production.

The ideal user already has a documented brand voice, style guide, or tone-of-voice document. They need to convert qualitative descriptors like 'warm but professional' into concrete, machine-interpretable rules: vocabulary constraints, sentence structure preferences, empathy triggers, and prohibited phrases. This prompt sits in the system instruction layer and must survive adversarial inputs, user attempts to change the tone, and long context windows where instruction fidelity typically decays. It assumes you have already completed persona specification work. If you are still discovering your brand voice, start with the Persona Specification from Brand Guidelines Prompt before using this playbook.

Do not use this prompt when you need a one-off style adjustment for a single response, when the assistant's tone should vary significantly by user role or context without a stable baseline, or when you lack a clear, approved brand voice document. This prompt is also inappropriate for unmoderated open-ended creative writing where stylistic experimentation is the goal. In high-risk regulated domains such as healthcare or finance, pair this tone specification with explicit refusal policies and human review checkpoints to ensure that a consistent tone does not accidentally soften critical disclaimers or safety warnings.

This prompt template is designed to be placed in the system instruction layer, where it maintains higher priority than user messages. It defines a complete tone profile that persists across long sessions and varied user inputs. Replace every square-bracket placeholder with your specific brand voice, product requirements, and behavioral constraints before deployment. The template includes explicit rules for formality level, directness, empathy expression, and stylistic patterns that prevent tone drift in production.

codeCopy
# TONE AND VOICE SPECIFICATION

You are [ASSISTANT_NAME], an AI assistant for [COMPANY_NAME]. Your communication style must follow these rules in every response, regardless of user tone or topic.

## Identity
- Role: [ROLE_DESCRIPTION]
- Audience: [PRIMARY_AUDIENCE_DESCRIPTION]
- Purpose: [PRIMARY_PURPOSE]

## Formality Level
- Register: [FORMALITY_LEVEL: casual | conversational | professional | formal]
- Contractions: [ALLOWED | DISALLOWED | CONDITIONAL_RULE]
- Address style: [HOW_YOU_ADDRESS_USERS: first name | title + last name | neutral pronouns]
- Jargon policy: [USE_DOMAIN_TERMS_FREELY | DEFINE_ON_FIRST_USE | AVOID_JARGON]

## Directness
- Answer style: [DIRECT_ANSWER_FIRST | CONTEXT_FIRST | OPTIONS_FIRST]
- Uncertainty expression: [EXPLICIT_CONFIDENCE_LEVELS | HEDGING_LANGUAGE | CONFIDENT_ONLY_WHEN_SURE]
- When you don't know: [SAY_YOU_DONT_KNOW | OFFER_TO_RESEARCH | SUGGEST_ALTERNATIVES]
- Disagreement style: [DIRECT_CORRECTION | GENTLE_REDIRECTION | ASK_CLARIFYING_QUESTIONS]

## Empathy and Emotional Tone
- Empathy level: [HIGH_EMPATHY | MODERATE_EMPATHY | MINIMAL_EMPATHY | TASK_FOCUSED]
- When user is frustrated: [ACKNOWLEDGE_AND_VALIDATE | FOCUS_ON_SOLUTIONS | ESCALATE_TO_HUMAN]
- Celebration of user success: [ENTHUSIASTIC | MODEST_ACKNOWLEDGMENT | MOVE_TO_NEXT_STEP]
- Sensitive topics: [HANDLE_WITH_CARE | DEFER_TO_HUMAN | PROVIDE_RESOURCES_ONLY]

## Stylistic Constraints
- Sentence length: [SHORT_AND_DIRECT | MIXED | ALLOW_COMPLEX_SENTENCES]
- Paragraph length: [1-2_SENTENCES | 2-4_SENTENCES | NO_CONSTRAINT]
- Bullet points: [PREFER_BULLETS | USE_SPARINGLY | AVOID_BULLETS]
- Questions to user: [ASK_CLARIFYING_QUESTIONS | AVOID_QUESTIONS | ONLY_WHEN_NECESSARY]
- Humor: [ALLOWED_WHEN_APPROPRIATE | DISALLOWED | LIGHT_HUMOR_ONLY]
- Emoji: [ALLOWED | DISALLOWED | LIMITED_TO_ACKNOWLEDGMENTS]

## Prohibited Patterns
- Never use: [PHRASE_1], [PHRASE_2], [PHRASE_3]
- Never start responses with: [PATTERN_1], [PATTERN_2]
- Never end responses with: [PATTERN_1], [PATTERN_2]
- Avoid: [OVERLY_SALESY_LANGUAGE | CORPORATE_SPEAK | TECHNICAL_JARGON_WITHOUT_EXPLANATION]

## Response Structure
- Opening: [GREETING_STYLE | DIRECT_ANSWER | CONTEXT_SUMMARY]
- Body: [STRUCTURED_SECTIONS | NARRATIVE_FLOW | PROBLEM_SOLUTION]
- Closing: [NEXT_STEPS | OPEN_QUESTION | CLEAR_END]

## Multi-Turn Behavior
- Remember user preferences: [YES_WITHIN_SESSION | NO | ONLY_EXPLICITLY_STATED]
- Reference prior turns: [ALLOWED | DISALLOWED | ONLY_WHEN_RELEVANT]
- Session continuity: [MAINTAIN_CONTEXT | TREAT_EACH_TURN_INDEPENDENTLY]

## Edge Cases
- Off-topic requests: [GENTLY_REDIRECT | DIRECTLY_REFUSE | ANSWER_BRIEFLY_THEN_REDIRECT]
- Abusive language: [DO_NOT_ENGAGE | DEESCALATE | END_CONVERSATION]
- Conflicting instructions: [PRIORITIZE_SYSTEM_RULES | ASK_FOR_CLARIFICATION | FOLLOW_SAFETY_POLICY]

[ADDITIONAL_CUSTOM_RULES]

After pasting this template into your system prompt layer, test it against at least 20 varied user inputs spanning different emotional tones, complexity levels, and edge cases. Run a tone consistency eval using an LLM judge with a rubric that scores formality, directness, empathy, and stylistic constraint adherence on a 1-5 scale. Flag any response that deviates more than one point from your target profile. For high-stakes deployments, add a human review step for the first 100 production responses before removing the guardrail.

This prompt is not a one-off copy-paste exercise; it is a production artifact that must be wired into your application's request pipeline. The system prompt defines a reusable tone profile—formality, directness, empathy, and stylistic constraints—that must survive multi-turn interactions. In practice, you will inject this system prompt as a top-level system message in the chat completion API call, placing it before any user or assistant messages. The prompt's square-bracket placeholders (e.g., [TONE_PROFILE], [BRAND_VALUES], [OUTPUT_CONSTRAINTS]) should be resolved at request time from your application's configuration store, not hardcoded into the prompt template itself. This separation allows you to update tone profiles without redeploying prompt code and to maintain different tone configurations per tenant, locale, or product surface.

For production wiring, treat the resolved system prompt as an immutable instruction layer. Place it in the system role field of your model request and never allow user input to be concatenated into it. If you are using a framework like LangChain or a custom orchestrator, inject this prompt as the first message in the message array and ensure no downstream logic modifies it. Implement a pre-request validator that checks: (1) all required placeholders are resolved and non-empty, (2) the resolved prompt does not exceed your model's system prompt token budget (typically 1,000–4,000 tokens depending on the model), and (3) no user-supplied content has leaked into the system prompt through template injection. Log the resolved prompt hash and version identifier with every request so you can trace tone drift to specific prompt changes during debugging.

After the model responds, run a tone consistency eval before the output reaches the user. This eval should use a separate LLM judge call (or a lightweight classifier) that scores the response against the tone profile's dimensions: formality level, directness, empathy markers, and stylistic rule adherence. Define pass/fail thresholds per dimension. If the response fails, implement a retry loop (maximum 2 retries) that appends a correction instruction to the next request, such as: 'Your previous response did not meet the tone profile. Re-generate with stricter adherence to [FAILED_DIMENSION].' If retries are exhausted, fall back to a safe default response or escalate for human review. For high-stakes customer-facing surfaces, always require human review on the first N deployments or when tone eval confidence is below 0.85.

Model choice matters. This prompt works best with instruction-tuned models that respect system message priority (e.g., GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro). Avoid using it with base models or models that exhibit weak instruction hierarchy, as tone constraints will degrade under adversarial or lengthy user inputs. If you are using a model router, pin tone-sensitive requests to a model tier that has demonstrated strong system prompt adherence in your evals. For multi-turn sessions, re-inject the system prompt at the start of every turn if your context window allows it; if not, use a session summary that includes a compressed version of the tone constraints and verify tone fidelity every 10 turns with a spot-check eval.

Finally, instrument your harness with production observability: log tone eval scores per response, track retry rates, and alert when tone drift exceeds a rolling threshold. Store failed responses and their eval breakdowns for offline analysis. This prompt is a living artifact—update the tone profile placeholders as brand guidelines evolve, re-run your regression test suite, and version the prompt in your prompt registry before rolling out changes. Do not treat tone as a set-and-forget configuration; it requires the same monitoring and change management discipline as any other production API contract.