Release Readiness Assessment Prompt Template

This prompt is designed for release managers and SRE teams who need to synthesize multiple signals—code changes, test results, static analysis findings, dependency updates, and operational risk factors—into a structured release readiness assessment. The prompt produces a go/no-go recommendation backed by evidence, a readiness score, and a list of blocking findings. Use this prompt when you have a release candidate and need a consistent, auditable evaluation before deployment. This is not a replacement for human judgment or automated CI/CD gates; it is a decision-support tool that makes the evidence and reasoning explicit so that the release manager can review, challenge, and approve the recommendation.

The ideal user is a release manager, SRE, or platform engineer who already has access to structured release signals—such as CI/CD pipeline results, test coverage reports, static analysis output, dependency vulnerability scans, and change logs—and needs to convert those signals into a defensible go/no-go recommendation. The prompt assumes that the input data is already collected and normalized. It does not perform live data retrieval, execute tests, or query monitoring systems. If you need the model to fetch data from APIs or dashboards, pair this prompt with tool-use or RAG patterns that supply the required context before invocation.

Do not use this prompt when the release decision is fully automated by existing pipeline gates, when the available signals are too sparse to support a meaningful assessment, or when the decision requires real-time metric evaluation that the prompt cannot access. Also avoid using this prompt for incident-time rollback decisions—use the Rollback Trigger Evaluation Prompt instead. For post-release analysis, prefer the Release Readiness Retro Prompt. Always route the final go/no-go decision through a human approval step, especially for high-risk or regulated deployments, and retain the prompt output as part of the release audit trail.

This template is the core instruction set for evaluating a release candidate. It forces the model to act as a release manager, synthesizing multiple signals—code changes, test results, risk indicators—into a single, structured assessment. The prompt is designed to be copied directly into your application or evaluation harness. Every placeholder in square brackets must be replaced with real data from your release pipeline before the prompt is sent to the model. The output contract is strict JSON, which makes it suitable for automated gating in CI/CD systems, but the go/no-go recommendation should always be treated as advisory and routed through a human approval step for production deployments.

textCopy
You are a release readiness assessor. Your job is to evaluate a release candidate against provided evidence and produce a structured JSON assessment.

## INPUTS
- Release Candidate ID: [RELEASE_ID]
- Target Environment: [TARGET_ENVIRONMENT]
- Deployment Window: [DEPLOYMENT_WINDOW]
- Code Changes Summary: [CODE_CHANGES_SUMMARY]
- Test Results: [TEST_RESULTS]
- Static Analysis Findings: [STATIC_ANALYSIS_FINDINGS]
- Security Scan Results: [SECURITY_SCAN_RESULTS]
- Performance Benchmark Results: [PERFORMANCE_BENCHMARK_RESULTS]
- Dependency Changes: [DEPENDENCY_CHANGES]
- Configuration Changes: [CONFIGURATION_CHANGES]
- Known Issues and Risks: [KNOWN_ISSUES_AND_RISKS]
- Previous Release Outcome Context: [PREVIOUS_RELEASE_OUTCOME_CONTEXT]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return ONLY valid JSON matching this schema:
{
  "release_id": "string",
  "assessment_timestamp": "ISO 8601 string",
  "readiness_score": number (0-100),
  "recommendation": "GO" | "NO_GO" | "CONDITIONAL_GO",
  "confidence": "HIGH" | "MEDIUM" | "LOW",
  "blocking_findings": [
    {
      "id": "string",
      "severity": "BLOCKER",
      "category": "string",
      "description": "string",
      "evidence_reference": "string",
      "recommended_action": "string"
    }
  ],
  "conditional_requirements": [
    {
      "id": "string",
      "condition": "string",
      "verification_method": "string",
      "owner": "string"
    }
  ],
  "risk_summary": {
    "overall_risk_level": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
    "key_risk_areas": ["string"],
    "mitigating_factors": ["string"]
  },
  "signal_coverage": {
    "signals_evaluated": ["string"],
    "missing_signals": ["string"],
    "coverage_gaps_note": "string"
  },
  "evidence_links": [
    {
      "signal": "string",
      "source": "string",
      "summary": "string"
    }
  ],
  "rollback_trigger_conditions": ["string"],
  "human_approval_required": true,
  "assessor_notes": "string"
}

## INSTRUCTIONS
1. Review all provided inputs systematically.
2. Identify blocking findings that should prevent release under any circumstances.
3. Identify conditional requirements that must be satisfied before or immediately after deployment.
4. Calculate a readiness score based on signal strength, risk severity, and coverage completeness.
5. Explicitly note any missing signals that would improve the assessment.
6. If the recommendation is GO or CONDITIONAL_GO, define specific rollback trigger conditions.
7. Set human_approval_required to true if any finding is BLOCKER severity or confidence is LOW.
8. Do not fabricate evidence. If a signal is missing, note it in missing_signals.

To adapt this template, replace each placeholder with structured data from your release pipeline. The [CONSTRAINTS] placeholder is where you inject organization-specific policies—for example, 'No deployment during business hours for customer-facing services' or 'Security scan must pass with zero HIGH findings.' The output schema is intentionally detailed to force the model to justify its recommendation with evidence links. Before integrating this into an automated gate, run it against at least 20 historical releases where you know the outcome, and calibrate the readiness score threshold against your organization's risk tolerance. A common failure mode is the model producing a GO recommendation while listing multiple BLOCKER findings—add a post-processing validation rule that rejects any output where recommendation is GO and blocking_findings is non-empty.

This prompt is designed to be called programmatically from a release management dashboard, CI/CD pipeline stage, or internal platform tool. The harness is responsible for assembling the input data from your existing systems—version control, CI test results, static analysis output, incident history, and deployment manifests—into the structured context the prompt expects. Do not ask a human to copy-paste these inputs manually; the value comes from consistent, automated assembly of the evidence package before the LLM is invoked.

The implementation should follow a strict assemble → call → validate → present loop. First, gather the required inputs: the release candidate identifier, a list of merged PRs with risk labels, test suite results with pass/fail counts and flaky annotations, static analysis findings filtered above a severity threshold, dependency change summaries, and any open incidents or SLO burn data. Assemble these into a single structured context object matching the prompt's [RELEASE_EVIDENCE] placeholder. Call the LLM with a low temperature (0.0–0.2) to maximize deterministic, repeatable assessments. On response, validate the output against the expected JSON schema—check that readiness_score is an integer between 0–100, recommendation is one of the allowed enum values (GO, CONDITIONAL_GO, NO_GO), and every blocking_finding includes a required evidence_source field. If validation fails, retry once with the validation error appended to the prompt as a correction hint. If the retry also fails, escalate to a human release manager with the raw evidence and partial output.

For high-risk releases—those touching authentication, payment, data migration, or infrastructure provisioning—the harness must route the validated output to a human approval queue before any deployment action is taken. Log the full prompt, response, validation result, and reviewer decision to an audit trail. Include the release ID, timestamp, model version, and reviewer identity. This audit record is essential for post-incident review and compliance. Avoid wiring the LLM output directly to a deployment trigger without human-in-the-loop for any release above a defined risk threshold. The prompt provides a structured recommendation, not an autonomous decision.