Release Note Tone and Audience Adaptation Prompt Template

This prompt is designed for DevRel and product marketing teams who need to scale the communication of a single, validated release across three distinct audiences: developers, executives, and end users. The core job-to-be-done is to take a structured, accurate changelog—the single source of truth—and produce three audience-specific variants without introducing hallucinations, altering technical facts, or requiring a full rewrite for each channel. The ideal user is a technical writer, developer advocate, or product marketer who owns the release communication pipeline and needs to maintain consistency while adapting depth, terminology, and framing.

Use this prompt when you have a finalized, reviewed changelog and the primary bottleneck is the manual labor of re-contextualizing the same information. It is most effective when the source changelog already contains categorized entries (e.g., breaking changes, features, fixes) and links to relevant issues or documentation. The prompt should not be used as a substitute for writing the initial changelog from raw commit histories or PR descriptions; use a dedicated changelog generation prompt for that upstream task. It is also not a replacement for human review of the final audience-facing copy, especially for releases involving security patches, breaking changes, or regulatory implications.

Before running this prompt, ensure your input changelog is complete and accurate. The prompt will faithfully adapt what you provide, so errors in the source will propagate across all three variants. After generation, validate each output against the original changelog for technical precision, check that no new features or breaking changes were invented, and confirm that the tone and depth are appropriate for each audience. For high-risk releases, always route the executive and developer variants through a human approval step before publication.

This prompt template takes a structured changelog and produces three audience-specific release note variants while preserving technical accuracy. Paste this into your system prompt or user message, replace the square-bracket variables, and run against your categorized changelog entries. The template enforces tone boundaries, vocabulary constraints, and output structure for each audience.

textCopy
You are a release note adaptation assistant. Your task is to transform a structured changelog into three audience-specific release note variants: developer-facing, executive, and end-user.

## INPUT
[CHANGELOG_ENTRIES]

## AUDIENCE DEFINITIONS

### Developer-Facing
- Tone: Technical, precise, actionable
- Vocabulary: Use exact API names, method signatures, parameter changes, error codes, and migration steps
- Structure: Group by breaking changes, features, fixes, deprecations, and known issues
- Include: Code snippets, before/after comparisons, upgrade instructions, dependency version changes
- Exclude: Marketing language, business impact estimates, non-technical summaries

### Executive
- Tone: Strategic, concise, business-impact focused
- Vocabulary: Use product capability names, customer value terms, timeline implications, and risk language
- Structure: Lead with key highlights, then business impact by category, then required decisions
- Include: Timeline implications, resource requirements, customer-facing changes, competitive positioning notes
- Exclude: Code snippets, implementation details, internal tooling changes, minor bug fixes

### End-User
- Tone: Friendly, benefit-oriented, accessible
- Vocabulary: Use feature names, user actions, visible changes, and plain-language explanations
- Structure: Lead with what's new and improved, then fixes, then known issues with workarounds
- Include: How to access new features, what changed visually or behaviorally, workarounds for known issues
- Exclude: API details, infrastructure changes, internal refactoring, version numbers, code references

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Read all changelog entries completely before writing.
2. For each audience variant, select only the entries relevant to that audience.
3. Preserve all technical facts from the source entries. Do not invent features, timelines, or impact claims.
4. If a changelog entry lacks sufficient detail for a variant, mark it as [INSUFFICIENT_DETAIL] rather than fabricating content.
5. Maintain consistent terminology within each variant.
6. For the developer variant, preserve exact API names, version numbers, and error codes.
7. For the executive variant, translate technical changes into business outcomes without exaggerating.
8. For the end-user variant, describe visible changes without assuming technical knowledge.
9. If a breaking change exists, all three variants must mention it with audience-appropriate severity language.
10. Return all three variants in the specified output schema.

To adapt this template, replace [CHANGELOG_ENTRIES] with your structured changelog data containing categorized entries with impact levels, issue references, and contributor attribution. Replace [CONSTRAINTS] with any additional rules such as character limits, forbidden terms, or required disclaimers. Replace [OUTPUT_SCHEMA] with your expected JSON structure specifying the three variant fields and their sub-fields. Replace [EXAMPLES] with one or two few-shot demonstrations showing correct tone adaptation across audiences. Before deploying, validate that the output schema includes fields for each audience variant and that your eval harness checks tone consistency, technical accuracy preservation, and absence of fabricated claims.

This prompt is designed to be called programmatically after a single source changelog has been finalized. The application layer should first validate the [SOURCE_CHANGELOG] input for completeness—ensuring it contains categorized entries, issue references, and contributor credits—before invoking the model. Because this prompt generates three audience-specific variants simultaneously, the output must be parsed into a structured object (e.g., JSON with developer, executive, and end_user keys) rather than treated as free text. Use a model with strong instruction-following and structured output support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro, and set response_format to json_object where the API supports it to enforce schema compliance.

Implement a validation layer that checks each generated variant against the original source entries. For every changelog item in the source, confirm that the technical facts (version numbers, breaking changes, deprecation dates, CVE identifiers) appear accurately in all three variants. Use a secondary LLM call with the Changelog Entry Validation and QA Prompt Template from this pillar to score factual preservation on a 1–5 scale. If any variant scores below 4, trigger a retry with the failing variant's output and the specific validation errors injected into the [CONSTRAINTS] field. Cap retries at 3 attempts before escalating to a human reviewer. Log every attempt, the validation scores, and the final approved output for auditability.

For high-stakes releases—security patches, breaking API changes, or regulated industry updates—route all generated variants through a human approval queue before publication. Store the approved output as the canonical release note in your documentation platform and use the developer variant to auto-populate your changelog.yaml or GitHub Release. Avoid using this prompt for real-time or streaming generation; it is a batch processing step that should run after the changelog is locked. The next step is to integrate the output with your release announcement pipeline, using the Release Announcement Drafting Prompt Template to build public-facing communications from the approved variants.