Incident Remediation Action Summary Prompt

This prompt is designed for incident response teams operating under pressure who need a structured, human-readable summary of a proposed remediation action before it executes during an active incident. The core job-to-be-done is to create a shared, auditable checkpoint that captures the hypothesis being tested, the blast radius, and the rollback plan. The ideal user is an Incident Commander or a senior responder who must coordinate multiple specialists and requires a single source of truth before approving a potentially risky change to a degraded production system.

Use this prompt when the cost of a wrong action is high, such as modifying production databases, altering network configurations, or executing deployment rollbacks. It is essential when multiple responders need a synchronized understanding of the plan and when an audit trail is required for post-incident review. The harness must capture the active incident ID and enforce explicit human approval under severity-based time constraints (e.g., a 5-minute SLA for a SEV1, 15 minutes for a SEV2). Do not use this prompt for low-severity, fully automated self-healing actions—like restarting a stateless container or scaling a replica set—where human review would add unacceptable latency and the rollback is trivial.

Before integrating this prompt, ensure your operational runbooks define clear severity levels that map to approval timeouts. A common failure mode is treating every action as high-risk, which leads to alert fatigue and ignored approval requests. Reserve this workflow for actions that are irreversible or have a wide blast radius. The next step is to wire this prompt into your incident management tool (e.g., PagerDuty, FireHydrant) so that the generated summary is posted directly into the incident channel, and the approval decision is logged against the incident timeline.

This prompt template is designed to be dropped directly into your incident response harness. It forces the model to produce a concise, factual summary of a proposed remediation action, not a conversational explanation. The output is intended for a human approver who needs to understand the hypothesis, blast radius, and rollback plan in seconds. Adapt the placeholders to match your internal incident schema, severity levels, and approval routing logic.

codeCopy
You are an incident response assistant generating a remediation action summary for human approval. Your output must be concise, factual, and structured. Do not speculate, minimize risk, or recommend action. State what is known and what is proposed.

[INCIDENT_CONTEXT]
Incident ID: [INCIDENT_ID]
Severity: [SEVERITY_LEVEL]
Current Status: [CURRENT_STATUS]
Affected Systems: [AFFECTED_SYSTEMS]
Timeline Summary: [TIMELINE_SUMMARY]

[PROPOSED_ACTION]
Action Type: [ACTION_TYPE]
Hypothesis: [HYPOTHESIS]
Specific Commands or Steps: [ACTION_STEPS]
Expected Outcome: [EXPECTED_OUTCOME]

[CONSTRAINTS]
Time Constraint for Approval: [APPROVAL_TIMEOUT]
Blast Radius: [BLAST_RADIUS]
Rollback Plan: [ROLLBACK_PLAN]
Required Approvers: [APPROVER_LIST]

[OUTPUT_SCHEMA]
{
  "incident_id": "string",
  "summary": "One-sentence summary of the proposed action.",
  "hypothesis": "The hypothesis being tested by this action.",
  "blast_radius": {
    "systems_affected": ["string"],
    "data_affected": ["string"],
    "user_impact": "string"
  },
  "rollback_plan": "Step-by-step rollback instructions.",
  "approval_required_by": "ISO 8601 timestamp",
  "risk_acknowledgment": "Statement of irreversible or high-risk elements."
}

Generate the summary now.

To adapt this template, replace each square-bracket placeholder with data from your incident management system. The [OUTPUT_SCHEMA] section defines a JSON contract that your harness can parse and route to the correct approval queue. If your incident severity is critical, consider adding a [RISK_LEVEL] field and a hard constraint that the model must explicitly flag any action with an irreversible blast radius. For regulated environments, add a [COMPLIANCE_FLAGS] input and require the model to cite applicable policies in the risk_acknowledgment field.

After copying the prompt, wire it into a harness that validates the output JSON against the schema before presenting it to a human. If the model fails to produce valid JSON or omits a required field, the harness should retry once with a stricter instruction. Never present an unvalidated summary to an approver during an active incident. The next section covers the full implementation harness, including retry logic, logging, and approval routing.

This prompt is designed to sit at a critical decision point in an automated incident response pipeline. It should be invoked after a diagnostic agent has analyzed an active incident and formulated a proposed remediation, but before any mutating action is executed. The harness must supply the prompt with a structured incident record, the proposed action plan, and the current severity classification. The model's output is a human-readable summary intended for an on-call responder, not a machine-parsed command. Therefore, the harness should treat this prompt as a blocking gate: the generated summary is pushed to a review interface, and the remediation workflow pauses until explicit human approval is received or a severity-based timeout expires.

The implementation should enforce a strict contract around the input variables. The [INCIDENT_RECORD] placeholder must be populated with a JSON object containing at least incident_id, severity (e.g., SEV1-SEV5), start_time, affected_services, and a diagnostic_summary. The [PROPOSED_ACTION] placeholder requires a structured object with action_type, target_resource, hypothesis, blast_radius_services, rollback_steps, and estimated_duration_seconds. The harness should validate these schemas before assembling the prompt to prevent the model from hallucinating missing critical fields. After the model generates the summary, the harness must parse the output and validate that it contains the required sections: Hypothesis, Blast Radius, Rollback Plan, and Approval Request. If any section is missing or the output is malformed, the harness should retry once with a repair prompt before escalating to a human without a summary.

The approval routing logic is the most critical part of this harness. The system must map the incident's severity field to an SLA for human response. For example, a SEV1 incident might auto-escalate after 5 minutes if no human approves, while a SEV3 incident might wait 30 minutes. The harness should integrate with on-call scheduling tools (e.g., PagerDuty, Opsgenie) to route the summary to the correct responder. Every state transition—prompt invoked, summary generated, approval requested, approval granted/denied, timeout triggered—must be logged immutably with timestamps, the full prompt, the model's output, and the human's decision. This audit trail is essential for post-incident review and for demonstrating that automated systems operated within their defined bounds. Avoid wiring this prompt directly to an execution engine without the human-in-the-loop gate; the summary's purpose is to create a moment of deliberate judgment before a potentially destructive action.