Release Go/No-Go Recommendation Prompt Template

This prompt is the final synthesis engine in a release quality pipeline. Its job is to consume pre-analyzed quality signals—aggregated test results, triaged defect lists, coverage gap reports, performance test interpretations, and operational risk assessments—and produce a single, defensible go/no-go recommendation memo. The ideal user is a QA manager, release coordinator, or engineering lead who already has structured inputs from specialized analysis prompts and needs to compress them into a decision document for stakeholders who were not in the room for every test review.

Do not use this prompt as a substitute for upstream analysis. If you feed it raw test logs, un-triaged bug lists, or uninterpreted performance metrics, it will produce a plausible-looking but poorly grounded recommendation. Each input signal should arrive pre-analyzed: defects should already be triaged by severity and blocking status, coverage gaps should be risk-ranked, and performance results should include SLA comparisons. The prompt's value is in weighing trade-offs across these signals, identifying conflicting evidence, and surfacing assumptions that the release team may have normalized without explicit discussion. It is a decision-support tool, not a primary analysis tool.

Before invoking this prompt, confirm you have collected outputs from the prerequisite analysis steps: a regression pass/fail synthesis, an open defect risk triage, a test coverage gap analysis, and any domain-specific assessments such as performance, security, or migration risk reports. If any of these inputs are missing, the prompt will generate a recommendation with explicit caveats, but the confidence and defensibility of that recommendation will be proportionally weaker. For high-risk releases in regulated environments, always route the final memo through human review and require explicit sign-off before the recommendation becomes a release decision.

This prompt template is designed for QA managers and release coordinators who need to produce a structured, evidence-backed release recommendation. It forces the model to ground every conclusion in the provided data, separate facts from assumptions, and flag missing information rather than filling gaps with speculation. Before using this prompt, gather your test results, defect lists, coverage reports, and any risk assessments into a single context block. The prompt works best when the input data is concrete and specific—vague inputs will produce vague recommendations.

textCopy
You are a senior release quality analyst. Your task is to evaluate the provided release evidence and produce a structured go/no-go recommendation. You must ground every conclusion in the evidence provided. If evidence is missing or insufficient for a conclusion, you must flag it explicitly rather than assume.

## INPUT DATA
[RELEASE_EVIDENCE]

## CONSTRAINTS
- Do not invent data, metrics, or defect details not present in the input.
- If a quality dimension lacks sufficient evidence, mark it as UNKNOWN with a note on what is missing.
- Distinguish between facts (directly observed in evidence) and assumptions (reasonable inferences you are making).
- If the evidence contains conflicting signals, describe the conflict rather than resolving it silently.
- For any recommendation to proceed, identify residual risks that will remain after release.

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "recommendation": "GO" | "NO_GO" | "CONDITIONAL_GO",
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "summary": "One-paragraph executive summary of the recommendation.",
  "evidence_assessment": {
    "test_results": {
      "status": "PASS" | "FAIL" | "PARTIAL" | "UNKNOWN",
      "key_findings": ["Finding 1", "Finding 2"],
      "missing_evidence": ["What we don't know about test results"]
    },
    "defect_analysis": {
      "open_critical": <count>,
      "open_high": <count>,
      "blockers_identified": ["Defect ID or description"],
      "regression_risk": "HIGH" | "MEDIUM" | "LOW" | "UNKNOWN"
    },
    "coverage_gaps": {
      "status": "ADEQUATE" | "INSUFFICIENT" | "UNKNOWN",
      "untested_areas": ["Area 1", "Area 2"],
      "risk_from_gaps": "Description of residual risk"
    },
    "operational_readiness": {
      "rollback_plan": "VERIFIED" | "UNVERIFIED" | "ABSENT",
      "monitoring_coverage": "ADEQUATE" | "INSUFFICIENT" | "UNKNOWN",
      "concerns": ["Concern 1"]
    }
  },
  "residual_risks": [
    {
      "risk": "Description",
      "likelihood": "HIGH" | "MEDIUM" | "LOW",
      "impact": "HIGH" | "MEDIUM" | "LOW",
      "mitigation": "What is in place or recommended"
    }
  ],
  "explicit_assumptions": [
    "Assumption 1: description and why it matters"
  ],
  "dissenting_signals": [
    "Any evidence that contradicts the primary recommendation"
  ],
  "conditions": [
    "If CONDITIONAL_GO, list specific conditions that must be met before proceeding"
  ]
}

## EVALUATION CRITERIA
- A GO recommendation requires: passing test results, zero open critical defects, adequate coverage, and verified rollback plan.
- A NO_GO recommendation is required if: any critical blocker is present, coverage is insufficient for changed paths, or operational readiness is absent.
- A CONDITIONAL_GO applies when: concerns exist but can be mitigated before or during rollout with specific monitoring and abort criteria.
- Confidence is HIGH only when all quality dimensions have sufficient evidence. Reduce confidence when evidence is partial or assumptions are required.

To adapt this prompt for your release process, replace the [RELEASE_EVENTS] placeholder with a structured summary of your test results, defect lists, coverage reports, and operational readiness artifacts. If your organization uses different quality dimensions or thresholds, adjust the evaluation criteria section to match your release policy. For high-risk releases, always route the model output through a human review step before communicating the recommendation to stakeholders. The structured JSON output is designed to be machine-readable for integration into release dashboards or automated gate checks, but the human-readable summary field should be the primary artifact for decision meetings.

The Release Go/No-Go Recommendation Prompt is not a standalone decision-maker—it is a synthesis engine that must be embedded in a controlled harness. The harness is responsible for gathering the required inputs (test results, defect counts, coverage reports, incident history, and risk signals), assembling the prompt with validated data, invoking the model, validating the output structure, and routing the recommendation for human review. Because a go/no-go decision carries significant business risk, the harness must enforce evidence grounding, detect unsupported conclusions, and prevent the model from making decisions without sufficient data. The prompt itself includes explicit instructions to flag missing evidence, but the harness should independently verify that each claim in the output references a provided input source.

The implementation should follow a validate-assemble-invoke-validate-review pipeline. First, validate that all required input slots are populated and that data freshness meets your release window requirements (e.g., test results from the last 24 hours, defect counts from the current milestone). Second, assemble the prompt by injecting validated data into the [TEST_RESULTS], [DEFECT_SUMMARY], [COVERAGE_REPORT], [INCIDENT_HISTORY], and [RISK_SIGNALS] placeholders. Third, invoke the model with a low temperature (0.0–0.2) to maximize consistency, and configure a structured output mode if your provider supports it—this reduces post-generation repair. Fourth, validate the output against the expected schema: confirm the recommendation field is one of GO, NO_GO, or CONDITIONAL_GO, that every risk claim has a corresponding evidence reference, and that residual risks are explicitly listed. Fifth, route the validated output to a human release coordinator for final approval. Log every step—inputs, raw model response, validation results, and human decision—for auditability and post-release review.

Retry and fallback logic is critical. If the model returns a malformed output or fails schema validation, retry once with a repair prompt that includes the validation error and the original context. If the second attempt also fails, escalate to a human with the partial output and a note that automated synthesis was incomplete. For high-risk releases, consider running the prompt against two different models (e.g., Claude and GPT-4) and flagging any divergence in recommendation for human investigation. Tool use and RAG are generally unnecessary for this prompt because all evidence should be pre-assembled by the harness—the model is synthesizing, not retrieving. However, if your release data lives in multiple systems (test management, defect tracker, incident database), build a pre-processing step that queries those systems, normalizes the data, and populates the prompt placeholders before invocation. Avoid giving the model direct tool access to query production systems during a release decision; the evidence set should be frozen at the time of assessment to prevent inconsistent or stale data from entering the synthesis.

Human review is mandatory for any output where the recommendation is NO_GO or CONDITIONAL_GO, and strongly recommended even for GO recommendations on high-risk releases. The harness should present the structured output alongside a summary of the evidence that was provided to the model, so the reviewer can spot-check claims. Implement a review queue that requires explicit approval, rejection, or modification of the recommendation before it becomes the official release decision. The harness should also track decision outcomes over time: compare the model's recommendation against actual post-release quality metrics to calibrate confidence and identify systematic biases in the synthesis. Do not close the feedback loop by automatically fine-tuning on outcomes without human review of the root cause—model errors may stem from input quality, not prompt design.