Deprecation Communication Tone Calibration Prompt

This prompt is for technical communications teams, developer relations engineers, and API product managers who need to adjust the tone of a deprecation message from alarming to supportive before it reaches customers. The core job is to take a single deprecation fact set—dates, replacement paths, impact scope—and produce multiple tone-calibrated variants (urgent, standard, advisory) that preserve technical accuracy while shifting the emotional register. You should use this prompt when you have a complete deprecation notice draft and need to ensure it lands appropriately for different audience segments or communication channels without rewriting from scratch each time.

Do not use this prompt to generate the deprecation notice itself from raw inputs. It assumes you already have a technically complete notice with validated dates, migration steps, and escalation contacts. If you are starting from scratch, use the API Deprecation Notice Drafting Prompt Template first, then feed its output into this prompt for tone calibration. Also avoid this prompt when the deprecation carries legal or regulatory consequences that require specific mandated language—tone variants must not alter required disclosures, SLA commitments, or compliance statements. In those cases, lock the legal language as a [CONSTRAINTS] block and only calibrate the surrounding explanatory text.

The ideal user has a draft deprecation notice in hand and needs to produce channel-specific variants: a direct email for heavy API consumers, a developer portal announcement, an in-app banner, and a status page update. Each channel has different tone expectations, and this prompt helps you generate consistent, audience-appropriate versions without introducing factual drift. Before running the prompt, gather your confirmed deprecation timeline, replacement documentation links, impact assessment data, and any approved legal language. After generating tone variants, always run them through the Deprecation Communication Review Rubric Prompt for a scored quality check before publication.

This prompt template helps technical communications teams generate tone-calibrated variants of deprecation messages. It accepts the raw deprecation facts—dates, affected endpoints, replacement paths—and produces three tone variants (urgent, standard, advisory) tuned to a specific audience. The template is designed to be wired into a documentation pipeline where a human reviewer selects or blends the appropriate variant before publication. Use square-bracket placeholders to inject your specific deprecation details, audience profile, and output constraints.

textCopy
You are a deprecation communications editor for a developer platform. Your job is to rewrite a raw deprecation notice into three tone-calibrated variants. Do not invent dates, replacement features, or migration steps. Work only from the provided [DEPRECATION_FACTS].

## Input
[DEPRECATION_FACTS]: A structured description of what is being deprecated, key dates, replacement options, and migration resources.
[AUDIENCE]: The target reader profile, such as "enterprise API consumers with 6-month migration cycles" or "early-adopter developers on free tier."
[URGENCY_LEVEL]: The required communication posture. One of: "urgent" (imminent shutdown, strong call to action), "standard" (planned deprecation with clear timeline), or "advisory" (advance notice, no immediate action required).
[OUTPUT_FORMAT]: The desired output structure, such as "email body," "in-app banner," "status page update," or "changelog entry."
[BRAND_VOICE]: Optional. Describe the company's communication style, such as "direct and technical, no marketing fluff" or "supportive and developer-empathic."

## Instructions
1. Read [DEPRECATION_FACTS] and extract: what is deprecated, the deprecation date, the shutdown date, the replacement, and the migration link.
2. Identify the [AUDIENCE] and adjust technical depth, assumed knowledge, and migration urgency accordingly.
3. Generate exactly three variants, each labeled with its tone:
   - **Urgent**: Immediate action required. Lead with the shutdown date and consequence of inaction. Use direct language. Include exact dates, the replacement, and the migration link in the first two sentences.
   - **Standard**: Planned deprecation. Lead with the deprecation announcement, then timeline, then replacement guidance. Use supportive but clear language. Assume the reader needs to schedule work.
   - **Advisory**: Advance notice only. Lead with the strategic rationale or improvement. Mention the deprecation as a future event. No immediate action required. Use reassuring language that builds trust.
4. For each variant, format the output as specified in [OUTPUT_FORMAT].
5. Apply [BRAND_VOICE] if provided. If not provided, default to professional, clear, and developer-respectful tone.
6. Do not add information not present in [DEPRECATION_FACTS]. If a required field (such as migration link) is missing, note it as "[MIGRATION_LINK_PENDING]" rather than inventing one.

## Output Schema
Return a JSON object with three keys: "urgent", "standard", "advisory". Each value is a string containing the formatted message.

## Constraints
- Never minimize the impact of a shutdown that breaks customer integrations.
- Never use alarmist language for advisory notices.
- Always include the deprecation date and shutdown date when known.
- Always include a human-readable replacement name and a migration resource.
- If [DEPRECATION_FACTS] contains conflicting dates, flag the conflict in an "escalation_note" field in the output.

To adapt this template, replace each square-bracket placeholder with data from your deprecation tracking system or product requirements document. The [DEPRECATION_FACTS] input should be a structured block—ideally pulled from an API spec, changelog, or internal deprecation registry—so the model never hallucinates dates or replacement endpoints. The [AUDIENCE] field controls vocabulary and assumed context: enterprise customers need SLA references and migration windows, while self-serve developers need copy-pasteable code diffs. The [URGENCY_LEVEL] selector lets you run the same facts through three communication postures without maintaining three separate prompts. Before wiring this into a production pipeline, validate outputs against the Deprecation Communication Review Rubric Prompt and require human approval for any notice going to paying customers or regulated services.

The Deprecation Communication Tone Calibration Prompt is designed to sit inside a larger deprecation communication pipeline, not as a standalone chat interaction. It receives a draft deprecation message and a target tone profile—urgent, standard, or advisory—and returns a tone-adjusted variant. The implementation harness should treat this prompt as a transformation step: draft in, calibrated variant out. Wire it after the initial notice drafting step and before multi-channel distribution, so tone calibration happens once and the result feeds into email, status page, changelog, and in-app banner templates.

Build the harness with a tone profile router that selects the appropriate [TONE_PROFILE] value based on the deprecation's risk classification and target audience. For example, a breaking change with a 30-day window maps to urgent, a standard deprecation with a 90-day window maps to standard, and a pre-announcement or advisory maps to advisory. Pass the original draft as [DRAFT_MESSAGE] and include [AUDIENCE] (e.g., direct API consumers, partner integrators, internal support team) so the model can adjust technical depth and assumed knowledge. The [REPLACEMENT_DETAILS] field should carry the migration path and replacement endpoint or feature name—this prevents the tone calibration from accidentally softening the call to action. On the output side, validate that the calibrated message still contains all required fields from the original notice: deprecation date, sunset date, replacement path, and escalation contact. A schema validator should check for these fields before the message proceeds to distribution. If validation fails, log the failure, capture the original and calibrated texts, and route to a human reviewer with a flag indicating which required field is missing.

For model choice, use a model with strong instruction-following and tone control—GPT-4o or Claude 3.5 Sonnet work well here. Set temperature low (0.2–0.3) to keep tone adjustments consistent across batches. Implement a retry with fallback pattern: if the calibrated output fails schema validation, retry once with an explicit error message appended to the prompt context (e.g., 'The previous output omitted the sunset date. Include it.'). If the retry also fails, escalate to a human review queue. Log every calibration attempt with the input draft, selected tone profile, output, validation result, and reviewer assignment for auditability. For high-risk urgent deprecations, add a mandatory human approval gate after calibration—no urgent deprecation message should ship without a human confirming the tone doesn't minimize impact or create confusion about deadlines.

Avoid wiring this prompt directly into a customer-facing endpoint without the validation and review gates described above. The biggest production risk is a tone calibration that accidentally removes critical dates, replacement links, or escalation contacts while making the message sound supportive. A supportive tone that omits the sunset date is worse than a blunt tone that includes it. Always run the calibrated output through a completeness check before distribution, and maintain a regression test suite of known deprecation drafts with expected tone outputs to catch prompt drift when you update the template.