Pre-Merge Test Gap Summary Prompt

This prompt is designed for a single, high-stakes job: producing a structured, evidence-backed go/no-go recommendation for a pre-merge gate in a CI/CD pipeline. It is not a general-purpose code reviewer or a conversational assistant. Its sole function is to synthesize multiple pre-existing quality signals—a code diff, test results, coverage data, and static analysis findings—into a human-readable report that a release manager or lead engineer can act on immediately. The ideal user is an engineering team that has already automated their test suite, coverage tooling, and static analysis, and now needs a consistent, auditable summary to prevent regressions from reaching the main branch.

The prompt assumes a specific input contract: you must provide structured data from your test runner, coverage tool, and static analyzer alongside the code diff. If any of these data sources are missing, incomplete, or untrusted, the output quality degrades sharply because the prompt cannot verify facts it does not receive. Do not use this prompt for real-time code completion, inline suggestions during development, or general code review without test context. It is also unsuitable when the underlying tools have not been run, as the prompt will hallucinate gaps rather than report them accurately. The prompt is a synthesis engine, not a replacement for your test infrastructure.

In production, this prompt should be wired into a merge gate that blocks pull requests when blocking gaps are detected. The output includes a blocking_gaps array where each entry must tie a specific unremediated risk to linked evidence from your tool outputs. If your workflow requires human approval for all merges regardless of the recommendation, use the advisory_gaps section to highlight items that need a reviewer's attention without blocking the pipeline. Before deploying, validate that every blocking gap in the output references a concrete file path, line range, or finding ID from your input data. A gap without evidence is a hallucination and must trigger a retry or human escalation.

This section provides the core prompt template for the Pre-Merge Test Gap Summary. It is designed to be pasted directly into your CI/CD pipeline configuration or LLM API call. The prompt instructs the model to synthesize multiple data sources—diff analysis, existing test results, coverage data, and static analysis findings—into a single structured report with a clear go/no-go recommendation. Every finding must be traceable to specific evidence, and blocking gaps must be tied to unremediated risks.

textCopy
You are a senior QA automation architect reviewing a pull request before merge. Your task is to produce a Pre-Merge Test Gap Summary report.

## INPUT DATA

### Code Diff
[DIFF]

### Existing Test Results
[TEST_RESULTS]

### Code Coverage Report
[COVERAGE_REPORT]

### Static Analysis Findings
[STATIC_ANALYSIS_FINDINGS]

### Change Context
- Repository: [REPOSITORY_NAME]
- Source Branch: [SOURCE_BRANCH]
- Target Branch: [TARGET_BRANCH]
- Changed Files: [CHANGED_FILES_LIST]
- Risk Level Threshold for Blocking: [RISK_LEVEL_THRESHOLD]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "merge_recommendation": "GO" | "NO_GO" | "CAUTION",
  "summary": "Brief narrative summary of test coverage status",
  "blocking_gaps": [
    {
      "gap_id": "string",
      "severity": "BLOCKING",
      "file_path": "string",
      "line_range": "start-end",
      "description": "What is untested and why it matters",
      "unremediated_risk": "Specific failure scenario that could reach production",
      "recommended_test_type": "unit | integration | e2e | contract | security | performance",
      "suggested_test_case": "Concrete test description with inputs and expected outcomes",
      "evidence_links": ["reference to diff hunk, coverage gap, or static analysis rule"]
    }
  ],
  "advisory_gaps": [
    {
      "gap_id": "string",
      "severity": "ADVISORY",
      "file_path": "string",
      "line_range": "start-end",
      "description": "What could benefit from additional testing",
      "risk_if_untested": "Potential but non-critical impact",
      "recommended_test_type": "unit | integration | e2e | contract | security | performance",
      "suggested_test_case": "Concrete test description",
      "evidence_links": ["references"]
    }
  ],
  "existing_coverage_notes": [
    {
      "gap_id": "string",
      "finding": "Description of a change that is adequately covered",
      "covering_tests": ["test names or file paths"],
      "confidence": "HIGH | MEDIUM | LOW"
    }
  ],
  "static_analysis_correlations": [
    {
      "static_finding_id": "string",
      "test_gap_relevance": "How this static finding relates to missing tests",
      "combined_risk": "Elevated risk when both conditions exist"
    }
  ]
}

## CONSTRAINTS

1. Every blocking gap MUST reference a specific diff hunk, uncovered code path, or static analysis rule. Do not flag generic concerns.
2. Blocking gaps MUST describe a concrete, unremediated risk that could cause a production failure.
3. Advisory gaps are for improvements, not critical risks. Do not inflate advisory gaps to blocking.
4. If a changed code path is covered by existing tests, list it in existing_coverage_notes with the test names.
5. Correlate static analysis findings with test gaps where the combination elevates risk beyond either alone.
6. Recommend NO_GO if any blocking gap exists. Recommend CAUTION if advisory gaps accumulate significant risk. Recommend GO only if all critical paths are tested.
7. Do not fabricate test results or coverage data. Work only from the provided inputs.
8. If inputs are insufficient to assess a gap, note the confidence as LOW and explain what data is missing.

## EXAMPLES

[FEW_SHOT_EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with structured data from your toolchain. The [DIFF] should contain the unified diff of the pull request. [TEST_RESULTS] should include pass/fail status and test names from your CI run. [COVERAGE_REPORT] should provide line-level or branch-level coverage data. [STATIC_ANALYSIS_FINDINGS] should include rule IDs, file locations, and descriptions. The [FEW_SHOT_EXAMPLES] placeholder is critical for calibration—provide 2-3 examples of correctly classified blocking vs. advisory gaps from your team's historical reviews. The [RISK_LEVEL] placeholder should contain your organization's risk tolerance policy, such as 'Blocking gaps require immediate test addition before merge; advisory gaps may be addressed in the next sprint.' Always validate the model's output against the schema before surfacing it in your merge gate. If the output contains blocking gaps without specific evidence links, reject the response and retry with stricter instructions.

The Pre-Merge Test Gap Summary Prompt is designed to operate as a merge gate decision point within a CI/CD pipeline, not as an ad-hoc developer tool. It consumes structured inputs from upstream pipeline stages—diff analysis, test run results, coverage reports, and static analysis findings—and produces a structured go/no-go recommendation. The harness must treat this prompt as a deterministic evaluation step: given the same inputs, the output structure and blocking gap criteria should be consistent enough to automate merge decisions for low-risk changes while escalating ambiguous or high-risk cases for human review.

Pipeline integration requires a pre-processing stage that assembles the [DIFF_ANALYSIS], [TEST_RESULTS], [COVERAGE_DATA], and [STATIC_ANALYSIS_FINDINGS] into the prompt's input slots. Each input must include file paths, line ranges, and severity or coverage percentages to enable traceable gap identification. The harness should validate the output schema before acting on the recommendation: check that blocking_gaps is a list, each gap has a risk_description and evidence_links array, and every blocking gap references a specific unremediated risk. If the output fails schema validation, retry once with the same inputs and a stricter [OUTPUT_SCHEMA] constraint. After two failures, fail the pipeline open with a human review flag—never silently pass a merge gate on malformed output. For model choice, use a model with strong structured output adherence (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to minimize variance in gap classification.

Logging and audit are critical because this prompt influences merge decisions. Log the full prompt input, raw model output, parsed recommendation, and any schema validation errors to an immutable audit store. Include the pipeline run ID, commit SHA, and timestamp. For human review escalation, configure the harness to route any merge request where recommendation is BLOCKED or REVIEW_REQUIRED to a review queue with the full gap summary attached. Do not use this prompt as the sole gate for security-sensitive or infrastructure changes—always require a human co-signer for changes touching authentication, authorization, data migrations, or infrastructure-as-code. The harness should also track false positive/negative rates over time by comparing blocking gap decisions against post-merge incidents, feeding that data back into prompt calibration and risk threshold tuning.