Release Note Tone and Audience Adaptation Prompt

This prompt is for DevRel, product, and release management teams that need to adapt a single, technically accurate release note draft into multiple audience-specific variants. The core job is tone calibration and technical depth adjustment while preserving factual consistency across all outputs. Use this when you have a source draft grounded in actual commits or diffs and you need to produce separate versions for developers, executives, customers, and support teams without introducing contradictory claims or hallucinated features.

This prompt belongs in a workflow after the source release note has been generated and verified for factual accuracy, and before the variants are published to changelogs, email campaigns, or documentation portals. The required input is a single source release note that has already passed a factuality check against the underlying commits or diffs. Do not use this prompt to generate the initial release note from raw changes—use a commit-diff-to-release-note prompt for that upstream step. Do not use this prompt when the source draft itself contains unverified claims, as tone adaptation will propagate and potentially amplify inaccuracies across all audience variants.

The ideal user is a technical writer, DevRel engineer, or product manager who understands the release content well enough to review the output variants for factual drift. The prompt assumes you have already defined your audience personas and their technical depth expectations. If you lack a verified source draft or clear audience definitions, invest in those prerequisites before running this adaptation workflow. The next section provides the copy-ready prompt template you can adapt to your specific audience profiles and tone guidelines.

The following prompt template is designed to be copied directly into your AI harness or orchestration layer. It takes a single source draft of a release note and produces four audience-specific variants, each calibrated for tone, technical depth, and the information that audience cares about most. Replace every square-bracket placeholder with your actual data before sending the prompt to the model.

textCopy
You are a release communication specialist adapting a single release note for four distinct audiences.

Your input is a source release note draft and a set of audience profiles. Your output must be four complete release note variants, each written for its specific audience.

## INPUT

### Source Release Note Draft
[DRAFT]

### Release Metadata
- Version: [VERSION]
- Release Date: [RELEASE_DATE]
- Product Name: [PRODUCT_NAME]
- Risk Level: [RISK_LEVEL]

## AUDIENCE PROFILES

### 1. Developers
- Tone: Precise, technical, direct
- Depth: Full API changes, schema diffs, code snippets, migration steps
- Focus: Breaking changes, deprecations, new endpoints, performance characteristics
- Must include: Before/after code examples, minimum supported versions, upgrade instructions

### 2. Executives
- Tone: Strategic, concise, outcome-oriented
- Depth: High-level feature summaries, business impact, risk highlights
- Focus: Market positioning, customer value, competitive differentiation, timeline
- Must include: Key metrics affected, strategic rationale, customer-facing benefits

### 3. Customers
- Tone: Benefit-oriented, accessible, encouraging
- Depth: Feature descriptions in plain language, user-facing improvements
- Focus: What's new, what's improved, what problems are solved
- Must include: How to access new features, value to their workflow, upgrade guidance in non-technical terms

### 4. Support Teams
- Tone: Operational, diagnostic, structured
- Depth: Known issues, workarounds, troubleshooting steps, configuration changes
- Focus: Support ticket deflection, common failure modes, escalation criteria
- Must include: Reproduction conditions, workaround steps, affected configurations, target fix versions for known issues

## CONSTRAINTS
- Every claim in every variant must be grounded in the source draft. Do not invent features, fixes, or impacts not present in [DRAFT].
- If the source draft contains no information relevant to a section, write "No [section topic] included in this release" rather than fabricating content.
- Maintain factual consistency across all four variants. A breaking change described in the developer variant must not be omitted from the support variant.
- For [RISK_LEVEL] of "high" or "critical", include an explicit "Actions Required" section in every variant.
- Use the exact version number [VERSION] and release date [RELEASE_DATE] consistently across all variants.

## OUTPUT SCHEMA
Return a JSON object with four keys: "developer_variant", "executive_variant", "customer_variant", "support_variant". Each value is a string containing the full release note for that audience in Markdown format.

{
  "developer_variant": "## [PRODUCT_NAME] [VERSION] Release Notes for Developers\n\n**Release Date:** [RELEASE_DATE]\n\n...",
  "executive_variant": "## [PRODUCT_NAME] [VERSION] Executive Summary\n\n**Release Date:** [RELEASE_DATE]\n\n...",
  "customer_variant": "## What's New in [PRODUCT_NAME] [VERSION]\n\n...",
  "support_variant": "## [PRODUCT_NAME] [VERSION] Support Notes\n\n**Release Date:** [RELEASE_DATE]\n\n..."
}

To adapt this template for your workflow, replace [DRAFT] with the full text of your source release note, [VERSION] with the semantic version string, [RELEASE_DATE] with the ISO date, [PRODUCT_NAME] with your product identifier, and [RISK_LEVEL] with one of low, medium, high, or critical. The output schema enforces a parseable JSON structure that your application can validate before routing each variant to its destination. If your release process requires fewer audiences, remove the unused audience profiles and their corresponding output keys, but keep the remaining profiles intact to preserve tone calibration.

Before integrating this prompt into a production pipeline, validate the output against a schema check that confirms all four keys are present and non-empty. For high-risk releases, route the generated variants through a human review step where a release manager verifies factual consistency across audiences. Common failure modes include the model adding features not present in the source draft, softening breaking change language too much in the customer variant, or omitting known issues from the support variant. Build eval checks that compare claims across variants and flag any statement in one variant that has no corresponding evidence in the source draft.

This prompt is designed to be a transformation step in a release documentation pipeline, not a standalone generator. The primary input is a single, validated source-of-truth release note (the 'source draft'). This source draft should already be fact-checked and grounded against commits or merged PRs before it reaches this adaptation step. The harness should enforce that the source draft is complete and approved before invoking the model, preventing the adaptation prompt from propagating or softening factual errors. In a CI/CD pipeline, this step runs after a 'Release Note QA and Accuracy Verification Prompt' has passed, ensuring the source material is clean.

The implementation should call the model once per target audience variant defined in [AUDIENCE_PROFILES]. Each call receives the same [SOURCE_DRAFT] and [CONTEXT] but a different audience profile. The output schema for each call must be strictly validated: check that all required fields (audience_label, headline, summary, key_changes, breaking_changes_section, upgrade_notes) are present and non-empty. Implement a retry loop with a maximum of 2 retries for schema validation failures, using a stripped-down version of the prompt that only requests the missing fields. Log every variant generation attempt, including the model, latency, token usage, and validation status, to a structured log for observability. For high-risk releases, route the generated variants to a human review queue via a Slack notification or a ticketing system API call before they are published.

To maintain consistency across variants, implement a post-generation cross-check. After all audience variants are generated, run a lightweight consistency check prompt that compares the key_changes lists across all variants. This check should flag any change present in one variant but missing in another, which could indicate an accidental omission. If a discrepancy is found, log a warning and re-run the generation for the affected variant with an added [CONSTRAINT] to include the missing item. Avoid using this prompt for real-time, user-facing chat; it is a batch processing step. The model choice should favor reliability and instruction-following over raw creativity—a capable long-context model like claude-sonnet-4-20250514 or gpt-4o is appropriate. Do not use a model that is prone to hallucination or format drift for this structured, multi-output task.