CI/CD Release Gate Decision Prompt

This prompt is designed for platform engineering and SRE teams who need an automated, evidence-backed go/no-go decision before promoting a build to production. Instead of relying on a human to manually scan dashboards, test reports, and incident channels, this prompt acts as a release gate judge. It ingests structured deployment signals—test pass rates, error budget status, recent incident data, and metric anomalies—and returns a binary decision with a detailed rationale. Use this when you want a consistent, auditable gate that runs inside your CI/CD pipeline and produces decisions faster than a human on-call rotation can review every canary deployment.

The ideal user is a platform engineer embedding this prompt into a deployment pipeline as a formal gate. Required context includes a structured payload of deployment signals: the target environment, the current error budget remaining, the pass rate of the test suite, any active P1/P2 incidents, and a summary of metric anomalies from the canary or staging phase. The prompt works best when these signals are programmatically assembled by the CI/CD system before inference, ensuring the model receives a consistent, machine-generated snapshot rather than free-text notes. The output is a strict JSON object containing a decision field (go or no_go), a confidence score, and a rationale array of evidence-backed reasons.

Do not use this prompt for real-time incident response where sub-second decisions are required; it is designed for pre-planned release windows where a few seconds of inference latency is acceptable. It is also not a replacement for a full incident commander's judgment during an active outage. Avoid using this prompt when the input signals are incomplete or when the deployment context involves novel failure modes not represented in the provided data. In regulated environments, the prompt's decision should be treated as a recommendation that requires human approval before the deployment proceeds, and every decision must be logged with the full input payload and model response for auditability.

The prompt below is designed to be copied directly into your gate evaluation step. It accepts structured inputs—test results, deployment metrics, and risk signals—and returns a binary decision with supporting rationale. Every input field uses a square-bracket placeholder that your application layer must populate before sending the request. The prompt enforces evidence grounding by requiring each signal to be cited in the decision explanation, which prevents the model from inventing risks or ignoring failures.

textCopy
You are a release gate evaluator for a CI/CD pipeline. Your job is to analyze deployment evidence and produce a binary go/no-go decision with clear rationale grounded in the provided data.

## INPUTS
- Test Results: [TEST_RESULTS]
- Deployment Metrics: [DEPLOYMENT_METRICS]
- Risk Signals: [RISK_SIGNALS]
- Previous Release Outcome: [PREVIOUS_RELEASE_OUTCOME]
- Rollback History: [ROLLBACK_HISTORY]
- Environment Context: [ENVIRONMENT_CONTEXT]

## CONSTRAINTS
- [CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with exactly these fields:
{
  "decision": "go" | "no_go",
  "confidence": 0.0-1.0,
  "rationale": "string explaining the decision, citing specific evidence from inputs",
  "risk_summary": {
    "blocking_issues": ["list of issues that prevent release"],
    "warnings": ["list of concerns that do not block release but require attention"],
    "rollback_readiness": "ready" | "not_ready" | "not_applicable"
  },
  "evidence_citations": [
    {
      "signal": "name of the input signal cited",
      "value": "observed value",
      "threshold": "threshold that applies, or null",
      "impact": "how this signal influenced the decision"
    }
  ]
}

## DECISION RULES
1. If any test marked as [CRITICAL_TEST_TAG] has status "failed", decision must be "no_go".
2. If deployment metrics show [ERROR_RATE_METRIC] exceeding [ERROR_RATE_THRESHOLD], decision must be "no_go".
3. If risk signals contain any item with severity "critical" and status "unresolved", decision must be "no_go".
4. If rollback history shows a rollback within the last [ROLLBACK_WINDOW_HOURS] hours for the same service, flag as warning but do not block unless combined with other failures.
5. If all checks pass, decision must be "go" with confidence reflecting the margin by which thresholds were met.
6. When evidence is missing or incomplete for any required signal, set confidence to 0.0 and decision to "no_go" with rationale explaining what is missing.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Analyze the inputs against the decision rules and return only the JSON object. Do not include explanations outside the JSON.

To adapt this template, replace each square-bracket placeholder with values from your pipeline context. The [TEST_RESULTS] field should contain structured test output, ideally as a JSON array of test objects with name, status, and tags. The [CONSTRAINTS] field lets you inject environment-specific rules—for example, "staging deployments require QA sign-off before go decision" or "compliance-scanned artifacts only." The [EXAMPLES] field is critical for calibration: provide 2-4 few-shot examples showing both go and no-go decisions with the evidence that drove each outcome. The [RISK_LEVEL] field accepts "low", "medium", or "high" and should influence the strictness of threshold interpretation—at high risk, even warnings can escalate to blocking. After populating the template, run it against a golden dataset of known release outcomes before deploying to your pipeline to verify that the decision rules produce expected results across edge cases.

Before wiring this into production, validate that your application layer handles three failure modes: missing input fields (the prompt will return confidence 0.0 and no-go, but your harness should catch this before sending), malformed JSON in the response (add a retry with the error message fed back into the prompt), and threshold boundary cases where metrics sit exactly at the limit (test with values at, just below, and just above each threshold). For high-risk environments, route every no-go decision through a human approval step before blocking the pipeline, and log every decision with its full evidence payload for auditability.

The CI/CD Release Gate Decision Prompt is not a standalone script; it is a decision node inside a deployment orchestrator. The harness must collect structured evidence from the pipeline—test results, deployment metrics, risk signals—and package it into the prompt's [DEPLOYMENT_CONTEXT] and [EVIDENCE_BLOCK] placeholders. The model's output is a structured go/no-go decision that the harness must parse, validate, and act on. A malformed output or a hallucinated rollback reason must not trigger an unintended deployment. The harness is the safety boundary between the model's probabilistic output and the deterministic pipeline control plane.

Wire the prompt as a pre-deployment gate step in your CI/CD platform (GitHub Actions, GitLab CI, Jenkins, Argo Workflows). The harness should: (1) aggregate evidence from the current pipeline run—test pass rates, deployment diff size, canary analysis results, error budget status, recent incident history, and any [RISK_SIGNALS] such as database migrations or dependency changes; (2) render the prompt template with real values, ensuring [DEPLOYMENT_CONTEXT] includes the target environment, service name, version, and change summary; (3) call the model with a low temperature (0.0–0.2) and a structured output format (JSON with decision, confidence, rationale, conditions, and rollback_triggers fields); (4) validate the response against a JSON Schema that enforces decision as an enum of ["go", "no-go", "manual_review"] and requires confidence as a float between 0.0 and 1.0; (5) log the full prompt, response, and validation result to your observability platform for audit and false-positive tracking.

Build retry logic for transient failures only—model timeouts, 5xx errors, or schema validation failures. Do not retry on a no-go or manual_review decision hoping for a different answer; that defeats the gate's purpose. If the model returns manual_review, the harness should post a structured message to the on-call channel with the rationale, conditions, and a link to the deployment context. For go decisions with conditions (e.g., 'proceed only if error budget > 50%'), the harness must verify those conditions against live metrics before advancing the pipeline. For no-go decisions, the harness must block the deployment and surface the rollback triggers and rationale to the release engineer. Integrate with your feature flag system so that the gate decision can be overridden by an authorized human with an audit trail entry.

Track false-positive and false-negative rates over time by comparing gate decisions against actual deployment outcomes. If the gate blocks deployments that would have succeeded (false positive), you lose velocity. If it approves deployments that cause incidents (false negative), you lose reliability. Store each decision alongside the eventual outcome (deployment success, incident created, rollback executed) in a decision log. Use this log to tune the prompt's [RISK_TOLERANCE] parameter and to identify systematic errors—such as the model over-weighting test failure counts while ignoring flaky test history. The harness should expose a /health endpoint that reports recent decision distribution and anomaly flags so the platform team can detect gate drift before it causes a bad release.

Avoid wiring this prompt directly to an automatic rollback trigger on its first deployment. Run the gate in shadow mode for at least two release cycles, logging decisions without enforcing them, and compare against human release decisions. Only promote to enforcement mode when the gate's decisions align with human judgment above an agreed threshold (e.g., 95% agreement on no-go decisions, zero false-negative approvals). When you do enforce, always provide a manual override path with a required justification field that feeds back into the evaluation dataset for continuous improvement.