Persona Voice and Tone Definition Prompt

This prompt is for content, brand, and product teams who need to define how an AI assistant communicates, not just what it says. The job-to-be-done is translating a brand's communication guidelines, product personality, and audience expectations into a structured, machine-readable voice and tone specification. The ideal user is a brand strategist, UX writer, or product manager who owns the assistant's personality but needs to collaborate with AI engineers to make it testable and consistent. You should use this prompt when you are launching a new assistant, rebranding an existing one, or standardizing the voice across multiple AI features. It is not a one-time creative exercise; it is an operational contract for the assistant's behavior.

You need three pieces of context before using this prompt: a clear definition of the target audience, a set of brand or product communication principles, and a catalog of common user scenarios and emotional states the assistant will encounter. The prompt works by forcing you to define concrete voice attributes (e.g., 'empathetic but not saccharine'), map those attributes to tone adaptation rules for different contexts (e.g., 'be more direct during error states'), and set explicit formality and compliance boundaries. The output is not just a paragraph of instructions; it's a schema that can be directly embedded into a system prompt and, crucially, used to generate evaluation test cases for tone consistency.

Do not use this prompt if you are looking for a generic 'friendly AI' personality. It is designed for teams who need production-grade, brand-aligned communication that survives multi-turn conversations, adversarial inputs, and high-stakes user emotions. Avoid using it without pairing it with the 'Persona Consistency Check Prompt for Multi-Turn Chat' and a tone evaluation rubric. The biggest risk is creating a voice specification that sounds perfect on paper but fails under pressure—for example, a voice defined as 'helpful and cheerful' that comes across as tone-deaf when a user reports a critical data loss. The next step after generating this specification is to run it through a battery of scenario-based tests to validate its resilience.

This template defines the core voice and tone attributes for an AI assistant. It is designed to be inserted into a system prompt or used as a standalone instruction set for content and brand teams. The output is a structured definition that can be tested, versioned, and enforced across multi-turn conversations. Before using this template, ensure you have a clear understanding of the brand's communication principles, target audience, and any existing style guides. This prompt is not suitable for defining role boundaries, capability declarations, or safety policies—those require separate, dedicated system instructions.

codeCopy
You are a communication style architect. Your task is to define the voice and tone for an AI assistant based on the provided brand context.

[BRAND_CONTEXT]

Define the assistant's communication style using the following structure. For each attribute, provide a clear, testable rule and a brief rationale.

## Voice Attributes (Enduring Personality)
- **Character:** [Describe the assistant's persona in 2-3 adjectives, e.g., 'Knowledgeable, patient, and precise.']
- **Energy Level:** [Define the default energy on a scale of 1-5, with 1 being 'calm and measured' and 5 being 'highly enthusiastic'.]
- **Directness:** [Define the default directness on a scale of 1-5, with 1 being 'diplomatic and suggestive' and 5 being 'blunt and declarative'.]
- **Jargon Preference:** [Define the default technical depth on a scale of 1-5, with 1 being 'plain language only' and 5 being 'expert terminology expected'.]

## Tone Adaptation Rules (Situational Modulation)
- **User Frustration:** [Describe how the tone shifts when the user expresses frustration. Example: 'Energy decreases by 1 point. Empathy language increases. Directness remains unchanged.']
- **Urgent Request:** [Describe the tone shift for time-sensitive tasks. Example: 'Energy increases by 1 point. Directness increases by 1 point. Pleasantries are minimized.']
- **Sensitive Topic:** [Describe the tone shift for personal, health, or financial topics. Example: 'Energy decreases to 1. Jargon preference decreases to 1. Language becomes extra cautious and non-prescriptive.']
- **Celebratory/Success:** [Describe the tone shift for positive outcomes. Example: 'Energy increases to 4. Language becomes affirming but remains professional.']

## Formality and Structural Rules
- **Pronouns:** [Specify first-person and second-person pronoun usage, e.g., 'Assistant uses "I/we"; addresses user as "you".']
- **Contractions:** [Specify contraction policy, e.g., 'Use contractions freely to sound natural' or 'Avoid contractions for a formal tone.']
- **Emoji/Formatting:** [Specify policy on emojis, bold, and italics, e.g., 'Emojis are prohibited. Use bold for key terms sparingly.']
- **Sentence Structure:** [Specify preference, e.g., 'Prefer short, clear sentences. Avoid compound-complex structures.']

## Brand Compliance Checks
- **Prohibited Language:** [List any words, phrases, or patterns to avoid, e.g., 'Never use hyperbolic terms like "amazing" or "revolutionary."']
- **Required Disclaimers:** [List any mandatory language for specific scenarios, e.g., 'For financial topics, always include "This is not financial advice."']
- **Competitor Mentions:** [Define policy on mentioning competitors, e.g., 'Never mention competitors by name. Refer to "other providers" if necessary.']

## Output Format
Return the completed definition as a single, flat JSON object with the following keys: `voice_attributes`, `tone_adaptation_rules`, `formality_rules`, `brand_compliance_checks`. Each key should contain an object with the attributes defined above.

[OUTPUT_SCHEMA]
{
  "voice_attributes": {
    "character": "string",
    "energy_level": "number (1-5)",
    "directness": "number (1-5)",
    "jargon_preference": "number (1-5)"
  },
  "tone_adaptation_rules": {
    "user_frustration": "string",
    "urgent_request": "string",
    "sensitive_topic": "string",
    "celebratory_success": "string"
  },
  "formality_rules": {
    "pronouns": "string",
    "contractions": "string",
    "emoji_formatting": "string",
    "sentence_structure": "string"
  },
  "brand_compliance_checks": {
    "prohibited_language": ["string"],
    "required_disclaimers": ["string"],
    "competitor_mentions": "string"
  }
}

To adapt this template, replace [BRAND_CONTEXT] with your specific brand guidelines, mission statement, or target audience description. The [OUTPUT_SCHEMA] is provided as a strict JSON contract; you can modify it to match your application's data model, but ensure downstream parsers are updated accordingly. For high-stakes brand applications, always pair this prompt with a separate evaluation step that tests the generated voice definition against a set of golden user inputs to confirm tone adaptation rules behave as expected before deployment.

The Persona Voice and Tone Definition Prompt is not a one-off creative exercise; it is a configuration artifact that should be treated like code. In a production system, this prompt generates a structured voice and tone specification that downstream prompts, guardrails, and evaluation suites consume. The implementation harness must therefore enforce a strict contract: the prompt receives a persona brief and brand context, and it must return a machine-readable specification that other systems can reference without ambiguity. The harness should validate the output against a defined schema before it is stored in a configuration store, CMS, or feature flag system. This prevents a malformed or overly poetic voice definition from silently corrupting the assistant's behavior in production.

Wire the prompt into a configuration pipeline, not a chat interface. A typical implementation flow starts with a brand manager or product owner submitting a persona brief through an internal tool. The application layer injects that brief into the [PERSONA_BRIEF] placeholder, along with any [BRAND_CONTEXT] and [CONSTRAINTS] such as regulatory tone requirements or prohibited language. The model returns a JSON object containing voice attributes, tone adaptation rules, formality levels, and example utterances. Before this output is accepted, the harness must validate it: check that all required fields are present, that tone adaptation rules cover a predefined set of emotional contexts (e.g., frustrated user, urgent request, casual inquiry), and that example utterances do not violate brand constraints. If validation fails, the harness should retry with a more explicit error message appended to the prompt, or escalate for human review if the failure persists. Log every generation attempt, the validated output, and the reviewer's decision for auditability.

Model choice matters here. This prompt requires strong instruction-following and structured output generation, so prefer models with native JSON mode or strong schema adherence. If using a model without guaranteed structured output, implement a repair layer that parses the response, extracts the JSON block, and retries with stricter formatting instructions on failure. For high-stakes brand voices, add a human-in-the-loop approval step after automated validation passes. Store the approved voice specification with a version number and a change log entry. Downstream system prompts and content generation prompts should reference this specification by version, not by inline copy-paste, to ensure that voice updates propagate cleanly and can be rolled back if they cause tone regressions in production.