Deployment Rollout Summary and Confirmation Prompt

This prompt is designed for release engineering teams that need a structured, human-readable summary of a planned deployment before it proceeds through a CI/CD pipeline gate. The primary job-to-be-done is transforming raw deployment context—such as version diffs, affected services, canary stages, and rollback triggers—into a confirmation-ready summary that a release manager or SRE can review and approve. Use this prompt when the cost of a bad deployment is high, when multiple services are affected, or when compliance frameworks (e.g., SOC 2, HIPAA) require a documented pre-release checkpoint. The ideal user is a platform engineer or release manager integrating this prompt into a deployment harness that blocks promotion until explicit human approval is logged.

The prompt requires concrete, machine-readable inputs to produce a reliable summary. You must supply the [VERSION_DIFF] (e.g., a git log or commit range), a list of [AFFECTED_SERVICES] with their blast radius, the [CANARY_STAGES] with traffic percentages and durations, explicit [ROLLBACK_TRIGGERS] (e.g., error rate > 1%, p99 latency > 500ms), and [MONITORING_LINKS] to relevant dashboards. Without these inputs, the model will generate a vague, untrustworthy summary that provides a false sense of security. The prompt is not a replacement for a canary analysis tool; it is a communication layer that synthesizes the output of those tools for a human decision-maker.

Do not use this prompt for trivial single-service patches with no dependencies or for fully automated environments where human approval is not required. If your deployment is a simple static-site update with instant rollback, this prompt adds unnecessary friction. Similarly, if your system uses automated canary analysis with a strict rollback policy and no human-in-the-loop gate, this prompt is the wrong tool. The most common failure mode is using this prompt with incomplete context, which causes the model to hallucinate a plausible but incorrect summary that masks real deployment risks. Always validate the generated summary against the source data before presenting it for approval.

This template is designed to be pasted directly into your CI/CD pipeline's approval gate. It instructs the model to act as a release auditor, synthesizing raw deployment metadata into a human-readable summary. The goal is not to make the deployment decision, but to ensure all critical information—version diff, affected services, canary stages, rollback triggers, and monitoring links—is presented clearly and consistently so the on-call engineer can make a fast, informed call.

textCopy
You are a release auditor for a production engineering team. Your task is to generate a concise, structured deployment summary from the provided metadata. Do not approve or deny the deployment. Your output must be a single, self-contained confirmation checkpoint that a human can review in under 60 seconds.

## Deployment Plan
[DEPLOYMENT_PLAN_JSON]

## Required Output Sections
1.  **Version Diff:** List the services being updated, their current and new versions, and a one-line summary of the change for each.
2.  **Affected Services & Blast Radius:** Enumerate all downstream services, jobs, or user-facing features that could be impacted.
3.  **Canary & Rollout Stages:** Describe the progressive rollout plan, including stage percentages, bake times, and the gating metric for promotion at each stage.
4.  **Rollback Triggers:** List the specific, measurable conditions that will trigger an automatic or manual rollback (e.g., SLO breach, error rate > X%, P99 latency > Y ms).
5.  **Monitoring & Runbook Links:** Provide a bulleted list of direct links to the primary dashboard, relevant logs, the runbook, and the incident escalation path.
6.  **Risk & Anomaly Flags:** Note any deviations from standard procedure, such as skipped stages, manual migrations, or known risky changes.

## Constraints
- Use only the data provided in [DEPLOYMENT_PLAN_JSON].
- If a section's information is missing from the plan, state 'NOT PROVIDED' for that section.
- Format the entire output in Markdown with clear headings for each section.
- Do not add any conversational preamble or postamble.

To adapt this template, replace the [DEPLOYMENT_PLAN_JSON] placeholder with a structured JSON object from your deployment orchestrator (e.g., Spinnaker, Argo Rollouts, or a custom pipeline). The JSON should contain fields like services, versions, stages, monitoring_urls, and rollback_criteria. If your pipeline uses a different schema, map those fields to the required output sections in the prompt's instructions. For high-risk deployments, add a [RISK_LEVEL] placeholder and a corresponding instruction to adjust the verbosity of the 'Risk & Anomaly Flags' section based on the level.

The Deployment Rollout Summary and Confirmation Prompt is designed to sit directly inside a CI/CD pipeline gate, not as a standalone chat interaction. When a release pipeline reaches the promotion stage, the harness should assemble the prompt with live deployment context—version diff, affected services, canary stages, rollback triggers, and monitoring links—and submit it to the model. The output is a structured summary that becomes the human-readable checkpoint before the pipeline proceeds. The harness must treat this prompt as a blocking gate: no deployment artifact moves to the next stage until the summary is generated, validated, and approved.

The harness should implement a three-stage pipeline: assemble, validate, and route. In the assemble stage, pull the deployment plan from the release orchestrator (e.g., Spinnaker, Argo Rollouts, or a custom deploy tool), extract the version diff from the container registry or git tags, and populate the [DEPLOYMENT_PLAN], [VERSION_DIFF], [AFFECTED_SERVICES], [CANARY_STAGES], [ROLLBACK_TRIGGERS], and [MONITORING_LINKS] placeholders. In the validate stage, check the model's output against a schema that requires: a summary field under 300 words, a risk_level enum of low|medium|high, a rollback_plan string, and a requires_approval boolean. If the output fails schema validation or the risk_level is high, force a retry with the error surfaced in the next prompt. After two retries, escalate to a human. In the route stage, if requires_approval is true or the deployment target is a production environment, post the summary to an approval queue (e.g., Slack workflow, PagerDuty incident, or a custom review UI) and block the pipeline until a human responds with approved or rejected. Log every step—prompt version, model, latency, output, validation result, and approval decision—to the deployment audit trail.

Common failure modes to guard against: the model omits a canary stage that exists in the plan, summarizes the version diff incorrectly, or produces a risk_level that contradicts the rollback triggers provided. Add eval assertions that check for the presence of each canary stage name in the output, verify that the version numbers in the summary match the input diff, and flag summaries where risk_level is low but rollback triggers include phrases like 'error rate > 1%' or 'latency p99 > 500ms'. For production deployments, require a second human reviewer if the deployment affects payment, authentication, or data storage services. Do not use this prompt for emergency hotfix pipelines where the approval gate would add unacceptable latency; instead, route those through a separate, time-boxed approval workflow with automatic escalation after 5 minutes.