Production Deployment Approval Prompt for CI/CD Agents

This prompt is designed for release engineering teams running AI-assisted deployment pipelines where an LLM agent must generate a structured approval request before promoting a build to production. The ideal user is a platform engineer or release manager who has already automated the gathering of deployment evidence—such as commit diffs, test suite results, canary performance metrics, and service topology graphs—but needs a formal, human-readable gate document to block automatic promotion. The job-to-be-done is not executing the deployment; it is creating a consistent, auditable artifact that forces a human to review the evidence and explicitly sign off before any infrastructure is mutated.

Use this prompt when your CI/CD agent has the authority to collect and summarize deployment data but must not proceed without explicit human approval. The required context includes a structured input payload with fields like commit_diff_summary, test_pass_rate, canary_latency_p99, affected_services, and blast_radius_estimate. The prompt works best in regulated or high-reliability environments where a deployment gate is a compliance requirement, not just a best practice. For example, a fintech team might wire this prompt into a GitHub Actions workflow that runs after canary analysis, producing a markdown document that is posted to a Slack channel for the on-call release manager to approve with a reaction emoji.

Do not use this prompt for executing deployments, for low-risk feature flag toggles, or for environments where full CI/CD automation is already approved. It is also a poor fit when the input data is incomplete—if test results or canary metrics are missing, the prompt will either hallucinate a summary or produce a gate document that provides a false sense of security. The next step after reading this section is to review the prompt template and adapt the input schema to match your specific deployment evidence sources. If your pipeline lacks automated evidence collection, build that first; this prompt is the final human checkpoint, not a replacement for observability.

This prompt template is designed to be used as the system instruction for an AI agent operating within a CI/CD pipeline. Its job is to compile a deployment gate request by synthesizing data from your version control, testing, and observability tools. The prompt enforces a strict output schema, ensuring that every required gate—such as test pass/fail status, canary results, and affected service mapping—is explicitly addressed before a human approver sees the request. This prevents the agent from generating a vague summary and forces it to either present the required evidence or flag it as missing.

markdownCopy
You are a release engineering agent responsible for generating a production deployment approval request. Your output must be a single JSON object conforming to the schema below. Do not include any text outside the JSON object.

## Required Inputs
- [DEPLOYMENT_DIFF]: The full commit diff or changelog for the release.
- [TEST_RESULTS]: A structured summary of test suite outcomes, including pass/fail counts and links to failed test logs.
- [CANARY_RESULTS]: Metrics and error rates from the canary deployment phase, if applicable.
- [SERVICE_MAP]: A list of services affected by this deployment, including their criticality (e.g., 'critical', 'high', 'medium', 'low').
- [BLAST_RADIUS_ASSESSMENT]: A description of the potential blast radius, including dependent services and user-facing features.
- [APPROVAL_CHAIN]: The ordered list of individuals or roles required to approve this deployment.

## Output Schema
{
  "deployment_id": "string",
  "summary": "A concise, one-paragraph summary of the changes and their purpose.",
  "risk_level": "low | medium | high | critical",
  "gates": {
    "test_gate": {
      "status": "passed | failed | incomplete",
      "evidence": "Summary of test results. If failed, link to specific failures.",
      "blocker": true_or_false
    },
    "canary_gate": {
      "status": "passed | failed | not_applicable",
      "evidence": "Summary of canary metrics and error rates.",
      "blocker": true_or_false
    },
    "change_review_gate": {
      "status": "complete | incomplete",
      "evidence": "Summary of the diff, highlighting risky changes like database migrations or config updates.",
      "blocker": true_or_false
    }
  },
  "affected_services": [
    {
      "name": "string",
      "criticality": "critical | high | medium | low",
      "change_summary": "Brief description of the change impacting this service."
    }
  ],
  "blast_radius": "Detailed description of the potential impact if the deployment fails.",
  "approval_chain": ["list of required approvers"],
  "missing_information": ["List any required inputs that were not provided or could not be verified."]
}

## Instructions
1.  **Synthesize, Don't Just Copy:** Analyze the [DEPLOYMENT_DIFF] and [SERVICE_MAP] to generate the `summary` and `affected_services` fields. Do not paste raw diffs.
2.  **Enforce Gate Status:** For each gate, set `blocker` to `true` if the `status` is `failed` or `incomplete`. A deployment request with any `blocker: true` gate must be flagged as `risk_level: critical`.
3.  **Flag Missing Data:** If a required input like [CANARY_RESULTS] is empty or not provided, set its gate status to `incomplete` and add a clear description to the `missing_information` list.
4.  **Preserve the Approval Chain:** The `approval_chain` in your output must exactly match the provided [APPROVAL_CHAIN] input.

To adapt this template, replace the square-bracket placeholders with data fetched from your pipeline tools. For example, your harness should query your CI system's API for [TEST_RESULTS] and your monitoring dashboard for [CANARY_RESULTS] before assembling the final prompt. The most critical adaptation is the gates object; you should add or remove gate definitions to match your organization's specific deployment policies. After generating the request, a downstream validation step must check the JSON against the schema and reject any output where a blocker gate is true but the risk_level is not critical, as this indicates a failure in the model's reasoning.

This prompt is designed to operate as a blocking gate within a CI/CD pipeline, not as a passive notification. The harness must prevent deployment progression until a structured approval response is received and validated. The prompt's output is a machine-readable approval request that a release orchestrator (e.g., GitHub Actions, GitLab CI, Jenkins) can parse and route to the appropriate human approvers. The key integration points are: (1) collecting the required inputs from the pipeline context, (2) calling the LLM with the prompt template, (3) validating the output schema, and (4) enforcing the approval workflow based on the response.

To wire this in, start by mapping pipeline context to the prompt's placeholders. [COMMIT_DIFF] should be populated from git diff or the pull request diff. [TEST_RESULTS] should be a structured summary of test suite outcomes, including pass/fail counts and any flaky test annotations. [CANARY_RESULTS] requires metrics from your canary deployment—error rates, latency p95, and log anomaly counts. [AFFECTED_SERVICES] should be derived from a service catalog or dependency graph. [BLAST_RADIUS] can be a pre-computed risk score or a list of dependent systems. The orchestrator must assemble these into a single context block before invoking the model. Use a structured output API (e.g., OpenAI's response_format with a JSON schema, or a tool call with a strict schema) to ensure the model returns a valid deployment_approval_request object with fields like approval_required, risk_level, summary, blocking_conditions, and recommended_approvers.

After receiving the model's output, the harness must run validation checks before surfacing the request to humans. Validate that blocking_conditions is a non-empty array if risk_level is high or critical. Confirm that recommended_approvers maps to actual roles in your identity provider (e.g., matching a GitHub team or PagerDuty escalation policy). If the output fails schema validation, retry once with the error message appended to the prompt as a correction hint. If it fails again, escalate to the on-call release manager with the raw output and validation errors. For high-risk deployments, the harness should require explicit approval from at least two members of the recommended_approvers list before advancing the pipeline. Log the full prompt, model response, validation results, and approval decisions to an audit trail for post-deployment review and compliance.

Avoid wiring this prompt directly to an auto-merge or auto-deploy action. The harness must treat the model's output as a recommendation, not a decision. The approval request should be posted to a Slack channel, a deployment dashboard, or a ticket system where humans can review the diff, test results, and risk assessment before clicking 'Approve' or 'Reject'. The pipeline should poll for the decision with a timeout—if no human responds within the configured window, the deployment should be blocked by default. This design prevents silent failures where the model produces a low-risk assessment but the pipeline proceeds without human oversight.