General engineering
AuraScore 77/100

Academic Pipeline Deprecation and Migration Notice

Compose a broadcast email to researchers announcing an engineering pipeline sunset and migration path.

Use this template when deprecating legacy scientific compute, data processing, or simulation pipelines in a research environment. It delivers transition timelines, technical dependencies, and step-by-step migration support to minimize research disruption.

Template

Role: Lead Data Infrastructure Engineer managing high-performance scientific computing and research data environments.

Context

  • Legacy pipeline being decommissioned: {{legacy_pipeline_name}}
  • Final sunset and cut-off date: {{target_sunset_date}}
  • Successor infrastructure or tool: {{new_platform_name}}
  • Impacted scientific workflows: {{research_workloads_impacted}}
  • Dedicated migration documentation: {{migration_guide_url}}
  • Technical support escalation point: {{support_contact_channel}}

Task

Draft an informative and supportive deprecation notice email to researchers and academic staff using {{legacy_pipeline_name}}, outlining key milestones, why the change is occurring, and how to migrate to {{new_platform_name}}.

Method

  1. Create a clear broadcast subject line containing pipeline name, action required, and sunset date.
  2. Announce the planned decommissioning of {{legacy_pipeline_name}} and state the upgrade rationale.
  3. Outline the key technical improvements offered by {{new_platform_name}} (e.g., speed, reproducibility, scalability).
  4. Itemize the phased sunset schedule from feature freeze to final compute cluster shutdown on {{target_sunset_date}}.
  5. Explain specific impacts on active workflows within {{research_workloads_impacted}}.
  6. Direct researchers to {{migration_guide_url}} for code migration scripts and containerized templates.
  7. Detail hands-on support windows, office hours, and contact instructions via {{support_contact_channel}}.

Constraints

  • MUST clearly specify the exact date when compute jobs on {{legacy_pipeline_name}} will be terminated.
  • MUST NOT use overly aggressive administrative tone; maintain an enabling, researcher-focused perspective.
  • Keep total length between 300 and 450 words.
  • Ensure documentation links and office hour details are prominent.

Output format

  • Subject: NOTICE: Transitioning from {{legacy_pipeline_name}} to {{new_platform_name}} [Timeline & Action Required]
  • Executive Announcement (1 paragraph)
  • Phased Deprecation Timeline (bulleted chronological list)
  • Benefits of {{new_platform_name}} (3 short bullet points)
  • Migration Instructions & Documentation (bulleted with link placeholder)
  • Support Channels & Office Hours (1 concise closing section)

Self-review

  • Is {{target_sunset_date}} explicitly stated for both freeze and termination phases?
  • Does the email provide immediate, actionable paths to {{migration_guide_url}}?
  • Are affected workloads in {{research_workloads_impacted}} addressed directly?
AuraScore breakdown
77/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering8/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-general
research-productivity-operations
data-engineering
research-infrastructure
migration