Drift Remediation Plan Generation Prompt

This prompt is designed for platform engineers and SREs who have already completed drift detection and now face the critical task of planning a safe remediation. It is not a detection tool; it assumes you have a structured, accurate list of drifted resources, their desired versus actual states, and their dependencies. The job-to-be-done is transforming that raw drift report into an executable, ordered runbook that minimizes risk. The ideal user is an operator who understands the infrastructure but needs assistance sequencing complex, multi-resource changes where a naive, alphabetical fix order could cause an outage.

Use this prompt when you have a validated drift report from a tool like terraform plan, a Kubernetes manifest diff, or a custom reconciliation script. The input must include resource identifiers, property-level diffs, and explicit dependency relationships. Do not use this prompt if you are still investigating the root cause of drift, if the drift findings are incomplete or unverified, or if you are dealing with a live incident requiring immediate, manual intervention. This prompt is for planned maintenance windows, not active firefighting. It is also unsuitable for generating a single kubectl apply command; its value is in orchestrating a sequence of operations with pre-checks, validation gates, and rollback steps for each stage.

The output is a structured remediation runbook, not a script. You should wire this into a human approval workflow where the generated plan is reviewed before any automated execution. The prompt's primary failure mode is generating a plan that is logically ordered but violates an implicit dependency not captured in the input. To mitigate this, always provide a complete dependency graph in the [INPUT] and use the [CONSTRAINTS] field to specify immutable ordering rules, such as 'never restart a database before its read replicas.' After generating the plan, the next step is a human review against architectural diagrams, followed by a dry-run execution in a staging environment if available.

This prompt template generates an ordered remediation runbook from a set of confirmed drift findings. It is designed for platform engineers who need a safe, verifiable plan before executing changes. The template expects structured drift data as input and produces a plan with pre-checks, ordered steps, rollback instructions, and validation gates. Use this prompt when you have already detected and confirmed drift; do not use it for initial drift detection or root cause analysis.

textCopy
You are a platform engineering remediation planner. Your task is to generate a step-by-step remediation runbook from a set of confirmed infrastructure drift findings.

## INPUT DRIFT FINDINGS
[DRIFT_FINDINGS]

## ENVIRONMENT CONTEXT
[ENVIRONMENT_CONTEXT]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "plan_id": "string",
  "generated_at": "ISO8601 timestamp",
  "summary": "One-paragraph summary of the remediation scope and risk level",
  "pre_checks": [
    {
      "check_id": "string",
      "description": "What to verify before starting remediation",
      "command_or_query": "The exact command or API call to run",
      "expected_result": "What a passing check looks like",
      "blocking": true_or_false
    }
  ],
  "remediation_steps": [
    {
      "step_number": integer,
      "resource_id": "The affected resource identifier",
      "drift_description": "What drifted",
      "action": "The specific remediation action",
      "command_or_manifest": "The exact command, API call, or manifest change",
      "expected_outcome": "What success looks like after this step",
      "depends_on_step_numbers": [integers_or_empty_array],
      "blast_radius": "What other resources or services may be affected",
      "rollback_action": "How to undo this step if it fails"
    }
  ],
  "validation_gates": [
    {
      "gate_id": "string",
      "after_step_numbers": [integers],
      "description": "What to validate",
      "command_or_query": "The exact validation command",
      "pass_criteria": "What passing validation looks like",
      "on_failure": "halt_or_rollback_or_continue"
    }
  ],
  "rollback_plan": {
    "trigger_conditions": ["List of conditions that trigger full rollback"],
    "ordered_rollback_steps": [
      {
        "step_number": integer,
        "reverses_remediation_step": integer,
        "action": "The rollback action",
        "command": "The exact rollback command"
      }
    ]
  },
  "risk_assessment": {
    "overall_risk_level": "low_or_medium_or_high_or_critical",
    "risks": ["List of specific risks"],
    "mitigations": ["List of mitigations for each risk"]
  }
}

## RULES
1. Order remediation steps by dependency: resources that others depend on must be remediated first.
2. Do not schedule parallel remediation of resources that share a dependency.
3. Every step must include a rollback action. If rollback is impossible, flag it in the risk assessment.
4. Pre-checks must run before any remediation step. Blocking pre-checks must pass before proceeding.
5. Validation gates must be placed after every step that changes stateful infrastructure.
6. If a drift finding involves a secret or credential, include a verification step that does not expose the secret value.
7. Mark any step that requires human approval with a note in the action field.
8. If the blast radius includes production traffic, set the risk level to at least "high".

## EXAMPLE OUTPUT
[EXAMPLE_OUTPUT]

Adapt this template by replacing the square-bracket placeholders with your specific data. [DRIFT_FINDINGS] should contain the structured output from your drift detection step—typically a JSON array of resources, property diffs, and severity classifications. [ENVIRONMENT_CONTEXT] should describe the target environment, including whether it serves production traffic, its deployment tooling, and any maintenance windows. [CONSTRAINTS] should list operational constraints such as allowed change windows, approval requirements, and resources that must not be modified. [EXAMPLE_OUTPUT] should contain one or two representative examples of correct output to guide the model's format and level of detail. Before deploying this prompt, validate that the output JSON conforms to the schema and that step ordering respects real dependency relationships in your infrastructure graph.

This prompt is designed to be the final step in a drift detection pipeline, not a standalone chat interaction. It expects a structured drift report as input and produces a machine-readable remediation plan. The implementation harness must validate the input drift report against a known schema before invoking the model, because malformed or incomplete drift data will produce an unreliable plan. In production, this prompt should be triggered automatically after a drift detection run completes and passes a severity threshold, or manually by an on-call engineer reviewing a triaged alert.

Wire the prompt into a workflow engine or orchestration layer that first fetches the drift report from your detection system (e.g., a drift detection Lambda output, a Terraform plan JSON file, or a database record). Validate the input against a strict schema that includes required fields: resource_id, resource_type, drifted_properties, expected_state, actual_state, and severity. Reject inputs missing these fields before they reach the model. After invoking the model, parse the output against the expected remediation plan schema (ordered steps with step_id, action, target_resource, pre_check, rollback_action, and validation_gate). If parsing fails, retry once with a repair prompt that includes the raw output and the schema. Log both the input drift report and the generated plan for auditability. For high-severity drift involving stateful resources (databases, persistent volumes, IAM roles), route the generated plan to a human approval queue before any automated execution.

Model choice matters here: use a model with strong reasoning and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, with the response_format or tool-calling API set to enforce JSON output. Avoid smaller or older models that may reorder dependent steps incorrectly. The primary evaluation criteria for this prompt are dependency ordering correctness and rollback completeness. Build an eval harness that tests the prompt against a golden dataset of drift scenarios with known correct remediation sequences. Flag any output where a resource is modified before its dependencies are healthy, or where a destructive action lacks a corresponding rollback step. Do not use this prompt for real-time automated remediation without human-in-the-loop approval for any resource tagged with severity: critical or risk: high.