Release Gate Architecture Design Prompt

This prompt is for release engineers and platform architects who are designing or reviewing automated promotion gates in a deployment pipeline. Use it when you need a structured design review that examines health check composition, metric threshold selection, dependency verification, exception handling, gate bypass risks, and signal independence. The prompt assumes you have a gate design document, a list of upstream service dependencies, and the metric definitions that the gate will evaluate. It is not a replacement for load testing or chaos engineering; it is a design-level review that catches structural weaknesses before the gate reaches production.

Run this prompt before committing the gate design to your pipeline configuration, and pair the output with a formal architecture decision record. The prompt requires three concrete inputs: a written description of the proposed gate logic, a dependency map showing which services the gate queries during evaluation, and the exact metric definitions (including source, aggregation window, and failure threshold) that the gate will use. Without these inputs, the review will produce generic advice rather than actionable findings. The prompt is most effective when the design is stable enough to be documented but not yet implemented in pipeline code—this is the window where structural changes are cheapest.

Do not use this prompt for runtime incident response, post-deployment debugging, or capacity planning. It does not evaluate whether your metrics thresholds are correctly calibrated for your traffic patterns, nor does it simulate failure scenarios under load. For those concerns, pair this design review with separate chaos engineering sessions and load test reports. The prompt also assumes a single gate design per invocation; if you are reviewing multiple interdependent gates, run the prompt once per gate and then review the outputs together for cross-gate interactions such as conflicting bypass conditions or shared dependency failures.

This prompt template is designed to be pasted directly into your AI workspace. It instructs the model to act as a release engineering architect and produce a rigorous, structured review of a proposed release gate design. The review focuses on health check composition, metric threshold selection, dependency verification, exception handling, and the critical risks of gate bypass and signal correlation.

textCopy
You are a senior release engineering architect. Your task is to perform a structured design review of an automated release gate architecture.

## GATE DESIGN SPECIFICATION
[GATE_DESIGN_DOCUMENT]

## REVIEW CRITERIA
Analyze the gate design against the following criteria. For each, provide a finding, a risk level (Low, Medium, High, Critical), and a concrete recommendation.

1.  **Health Check Composition:** Evaluate the selection of health checks (liveness, readiness, startup). Are they sufficient to detect a degraded service? Do they cover critical dependencies? Is there a risk of a "green but broken" state?
2.  **Metric Threshold Design:** Assess the chosen metrics (e.g., error rate, latency p95, saturation) and their thresholds. Are they leading indicators of failure? Are the thresholds sensitive enough to catch issues early but robust against transient spikes? Is there a statistical justification for the thresholds?
3.  **Dependency Verification:** Review how the gate verifies the health of critical downstream and upstream dependencies. Does it check for dependency availability, correct versioning, and functional correctness? How does it handle a degraded dependency?
4.  **Exception Handling:** Analyze the gate's behavior during failures. What happens if the gate itself fails, times out, or returns an error? Is the default behavior to halt or proceed? Is there a manual override process, and is it auditable?
5.  **Gate Bypass Risks:** Identify any paths, roles, or conditions that could allow a release to bypass the gate without full evaluation. This includes emergency deploy procedures, admin overrides, and pipeline misconfigurations.
6.  **Signal Independence:** Evaluate the correlation between the signals used. Are the health check, metrics, and dependency checks truly independent, or could a single root cause make them all fail or all pass simultaneously, creating a false sense of security?

## OUTPUT FORMAT
Produce a markdown report with the following sections:
- **Executive Summary:** A 3-4 sentence summary of the overall risk posture and the top 2-3 critical findings.
- **Detailed Findings:** A table with columns for `#`, `Criterion`, `Finding`, `Risk Level`, and `Recommendation`.
- **Risk Matrix:** A simple 2x2 matrix plotting `Likelihood` vs `Impact` for the top risks.
- **Action Plan:** A prioritized list of concrete actions to remediate the identified risks before production rollout.

## CONSTRAINTS
- Base all findings strictly on the provided [GATE_DESIGN_DOCUMENT]. Do not invent information.
- If the design document lacks sufficient detail for a criterion, state that explicitly and recommend what information is needed.
- Use precise, actionable language. Avoid vague terms like "improve monitoring."

To adapt this template, replace the [GATE_DESIGN_DOCUMENT] placeholder with the full text of your proposed gate architecture, including your pipeline configuration, health check definitions, metric queries, and operational runbooks. The output format is strictly defined to ensure the review is immediately actionable and can be attached to a release engineering decision record. Before deploying a gate based on this review, ensure a human release manager validates all Critical and High-risk findings and signs off on the action plan.

This prompt is designed to be called programmatically as part of a design review stage, not as a one-off chat interaction. The typical integration point is a CI/CD pipeline or a release engineering CLI tool where a proposed gate configuration (health checks, metric thresholds, dependency checks, exception rules) is submitted for architectural review before it is committed to the gate definition repository. The prompt expects a structured [GATE_DESIGN] input, which should be assembled from the gate specification file (e.g., a YAML or JSON config) and any relevant operational context such as the target service's SLO, incident history, and upstream/downstream dependency map.

Wire the prompt into an automated review step that runs on pull requests to the gate configuration repository. The application harness should: (1) extract the proposed gate definition and context from the PR diff and service catalog, (2) populate the [GATE_DESIGN], [SERVICE_CONTEXT], and [RISK_TOLERANCE] placeholders, (3) call the model with a low temperature (0.1–0.2) to maximize deterministic, review-focused output, (4) validate the response against the expected [OUTPUT_SCHEMA]—a JSON object containing findings, risk_score, bypass_risks, and recommendations—and retry once if validation fails, (5) post the structured findings as a PR comment and attach a machine-readable artifact for downstream gating. For high-risk services (e.g., payment systems, auth services), require a human reviewer to acknowledge the model's findings before the PR can merge. Log the full prompt, response, and validation result for auditability.

Common failure modes in the harness include: the model producing findings not grounded in the provided gate definition (mitigate by requiring citations to specific gate rules in the output schema), the model missing indirect bypass risks such as shared dependency failure (mitigate by including a dependency graph in [SERVICE_CONTEXT]), and schema validation failures where the model nests findings incorrectly (mitigate with a strict JSON schema validator and a single retry with the validation error message appended to the prompt). Do not use this prompt to make the final approval decision automatically for high-risk services; the output is a design review artifact, not an authorization. The next step after a successful review is to merge the gate definition and deploy it to a staging gate evaluation environment before production use.