Hotfix Regression Test Scope Prompt

This prompt is built for the high-pressure window between a confirmed incident fix and its emergency deployment. The primary user is an SRE or on-call engineer who has a code diff in hand, understands the incident's blast radius, and needs a defensible, minimal test plan in minutes—not hours. The job-to-be-done is risk-balanced test selection: you are not trying to run everything, and you are not skipping verification. You are producing a documented rationale for exactly which tests to execute, which to defer, and what must pass before the hotfix can merge. The output is a structured regression scope that an incident commander can review and approve without deciphering raw test suite logs.

Use this prompt when three inputs are available: a concrete code diff (unified diff, PR changeset, or patch file), a written incident summary describing the user-visible impact and root cause hypothesis, and a module dependency map—even a rough one—showing which services, libraries, or data paths sit adjacent to the changed code. The prompt is most effective when the fix is surgically small (a few files, a single repository) and the incident is understood well enough to describe the failure mode. It is also appropriate when you need an auditable artifact for a post-incident review, showing why certain test suites were skipped under time pressure.

Do not use this prompt when the incident root cause is unknown, the fix is speculative, or the code change spans multiple services without a clear dependency map. It is also the wrong tool for broad release regression planning, where you have hours or days to run full suites. If the hotfix touches authentication, authorization, billing, or data deletion paths, this prompt can scope tests but must be paired with mandatory human security review—the prompt alone cannot assess compliance risk. Finally, if you lack a module dependency map, the blast-radius analysis will be guesswork; in that case, default to running the full critical-path suite and use this prompt only to document what you ran and why.

After using this prompt, treat its output as a starting point for a quick human sanity check. The generated test list should be reviewed by one additional engineer who can confirm that no high-risk adjacent module was omitted. Wire the smoke test checklist directly into your deployment pipeline as a manual gate: all smoke checks must pass before the hotfix proceeds to canary or full rollout. The rollback validation steps should be pasted into the rollback runbook so the on-call responder has clear pass/fail criteria if a revert becomes necessary.

This prompt template is designed to be pasted directly into your AI harness during an active incident. It forces the model to produce a narrowly scoped, high-signal test list that targets the fix itself and the immediately adjacent modules within the blast radius. The output includes a mandatory smoke test checklist and explicit rollback validation steps, which are non-negotiable for any hotfix deployment. Before using this prompt, ensure you have gathered the incident timeline, the specific commit or patch diff, the affected service topology, and the target deployment window. Do not use this prompt for routine release regression planning; it is optimized for time-sensitive, high-risk remediation where test suite runtime must be minimized without sacrificing safety coverage.

textCopy
You are an SRE regression test scoping assistant operating during an active incident remediation. Your task is to produce a minimal, high-signal regression test plan for a hotfix deployment. The plan must be executable within a constrained time window and must prioritize safety over completeness.

## INCIDENT CONTEXT
- Incident ID: [INCIDENT_ID]
- Severity: [SEVERITY_LEVEL]
- Brief description of the incident and root cause: [INCIDENT_SUMMARY]
- Affected services and modules: [AFFECTED_SERVICES]
- Deployment window available (minutes): [DEPLOYMENT_WINDOW_MINUTES]

## CODE CHANGE
- Hotfix commit or patch diff: [HOTFIX_DIFF]
- Files changed: [CHANGED_FILES]
- Author and reviewer: [AUTHOR_AND_REVIEWER]

## SYSTEM CONTEXT
- Service dependency graph (simplified): [DEPENDENCY_GRAPH]
- Upstream consumers of affected APIs: [UPSTREAM_CONSUMERS]
- Downstream dependencies: [DOWNSTREAM_DEPENDENCIES]
- Database schemas or state modified: [STATE_CHANGES]

## CONSTRAINTS
- Maximum test execution time (minutes): [MAX_TEST_TIME]
- Test environments available: [AVAILABLE_ENVIRONMENTS]
- Tests that MUST run (regulatory, contractual, or safety-critical): [MANDATORY_TESTS]
- Tests that CANNOT run (environment limitations, flaky tests, known broken): [EXCLUDED_TESTS]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "incident_id": "string",
  "hotfix_scope_summary": "string (one-sentence summary of what the fix touches)",
  "blast_radius_analysis": {
    "directly_affected_modules": ["string"],
    "indirectly_affected_modules": ["string"],
    "risk_propagation_paths": ["string (explain how a failure could cascade)"]
  },
  "smoke_test_checklist": [
    {
      "test_name": "string",
      "description": "string (what this validates)",
      "priority": "critical | high",
      "estimated_duration_seconds": number,
      "pass_criteria": "string (specific, observable condition)",
      "rollback_trigger": "boolean (true if failure here requires immediate rollback)"
    }
  ],
  "regression_test_selection": [
    {
      "test_suite_or_case": "string",
      "module": "string",
      "rationale": "string (why this test is selected for this hotfix)",
      "risk_if_skipped": "string (what defect could escape)",
      "priority": "high | medium | low",
      "estimated_duration_seconds": number
    }
  ],
  "excluded_tests_with_justification": [
    {
      "test_suite_or_case": "string",
      "reason_for_exclusion": "string",
      "risk_accepted": "string",
      "alternative_coverage": "string (what other test or check covers this risk)"
    }
  ],
  "rollback_validation_steps": [
    {
      "step": "string",
      "validation_method": "string (how to confirm rollback succeeded)",
      "expected_state": "string"
    }
  ],
  "total_estimated_runtime_seconds": number,
  "coverage_gaps_acknowledged": ["string (risks not covered by this plan)"],
  "human_approval_required": "boolean"
}

## INSTRUCTIONS
1. Analyze the hotfix diff and identify every code path, function, API endpoint, database query, configuration change, and error-handling branch that is modified.
2. Map these changes to the dependency graph to identify the blast radius. Include modules that call into changed code, modules that consume changed data structures, and modules that share infrastructure (queues, caches, databases) with changed components.
3. Build the smoke test checklist first. These tests must validate that the fix itself works and that the system is not catastrophically broken. Every smoke test must have a clear rollback trigger condition.
4. Select regression tests by prioritizing: (a) tests that directly exercise changed code paths, (b) tests that cover adjacent modules in the blast radius, (c) tests that have historically failed in similar changes, (d) tests covering contract boundaries with upstream consumers. Do not select tests for unrelated modules unless a shared dependency forces it.
5. For every test you exclude, provide a specific justification and identify what alternative coverage exists. Never exclude a test without documenting the accepted risk.
6. Include explicit rollback validation steps that confirm the system returns to the pre-hotfix state.
7. If the total estimated runtime exceeds [MAX_TEST_TIME], re-prioritize and move lower-priority tests to a post-deployment validation phase with a clear note.
8. Set human_approval_required to true if any of the following apply: the blast radius includes PII handling, payment processing, authentication/authorization, or safety-critical systems; the fix modifies database schema; the fix changes error-handling behavior in a way that could mask failures; or any mandatory test cannot be executed.
9. Acknowledge coverage gaps explicitly. Do not claim coverage you cannot deliver.

To adapt this template, replace every square-bracket placeholder with real data from your incident management system, version control, and service catalog. The dependency graph can be a simplified textual representation if you do not have a machine-readable graph available. For the hotfix diff, include the full unified diff or a structured summary of changed functions and files. If your test inventory is large, consider pre-filtering to tests tagged with affected modules before passing them as context. After the model returns the JSON output, validate that every selected test actually exists in your test suite and that the estimated runtimes are realistic for your infrastructure. Run the smoke test checklist first in a staging or canary environment before proceeding to the full regression selection. If the model sets human_approval_required to true, route the plan to the incident commander for explicit sign-off before execution.

The hotfix regression scope prompt is designed to run inside an incident response workflow, not as a standalone chat. It should be triggered automatically when a hotfix branch is created or a patch is staged, receiving the fix diff, the incident timeline, and the module dependency graph as inputs. The output is a structured test list that downstream systems can consume directly, so the harness must enforce schema compliance before any test execution begins.

Wire the prompt into a pipeline that first assembles the required inputs: the git diff between the hotfix branch and the last stable release, the incident report or postmortem draft, and a dependency graph extracted from your build system or module manifest. Pass these into the prompt template as [FIX_DIFF], [INCIDENT_CONTEXT], and [DEPENDENCY_GRAPH]. Set [CONSTRAINTS] to include your maximum test execution budget and any mandatory test suites that must always run. After the model returns a response, validate the JSON output against a strict schema that requires each recommended test to include a test_id, priority, justification, and blast_radius_module. Reject any output that omits the mandatory smoke test checklist or the rollback validation steps. If validation fails, retry once with a repair prompt that includes the specific schema violations. If the second attempt also fails, escalate to the on-call lead for manual scope definition.

Log every prompt invocation, the validated output, and any retry or escalation events to your incident management system. This creates an audit trail showing why specific tests were selected or skipped during the hotfix. Before executing the recommended test list, route it through a human approval step where the on-call engineer can add or remove tests based on operational context the model cannot see, such as known flaky environments or downstream system maintenance windows. The harness should also compare the recommended scope against the actual tests executed and any defects found later, feeding that data back into your regression test selection evals for continuous improvement.