Tree-of-Thought Incident Remediation Path Prompt

This prompt is for incident commanders and SRE teams facing production incidents where multiple remediation paths exist and the best course of action is not obvious. Use it when you need to map out branching fix strategies, compare their risks side by side, and identify which paths are reversible versus destructive. The prompt forces structured reasoning across parallel options rather than committing to the first plausible fix.

Do not use this prompt when the incident has a single well-understood remediation path, when immediate action is required without deliberation, or when the incident is already resolved and you are producing a postmortem. This prompt assumes you have a clear symptom description, known affected services, and at least some understanding of the failure domain. It is not a replacement for runbook automation or a substitute for on-call judgment when seconds matter.

The ideal user is an incident commander who has already triaged the immediate blast radius and needs to evaluate competing fix strategies before committing the team to a course of action. The prompt works best when you can articulate the symptom, the suspected failure domain, and any constraints such as maintenance windows, data consistency requirements, or regulatory obligations. If you cannot describe the symptom with reasonable precision, start with a diagnostic or root-cause analysis prompt instead.

Before using this prompt, gather the incident timeline, affected service names, recent changes, and any monitoring data that narrows the failure domain. The prompt will ask you to supply these as structured inputs. If you skip this step, the generated decision tree will be shallow and unreliable. After the prompt runs, review the output with your on-call team, validate the risk assessments against your actual system topology, and use the tree as a decision aid—not as an automated executor. The final remediation decision and execution remain human responsibilities.

This prompt template is designed to be the core instruction you send to a capable LLM during an active incident. It forces the model to structure its reasoning as a branching tree, exploring multiple remediation strategies in parallel rather than committing to the first plausible fix. The template uses square-bracket placeholders for all incident-specific details, ensuring you can quickly populate it from your monitoring dashboards, runbooks, and on-call chat without rewriting the core logic.

textCopy
You are an expert incident commander and site reliability engineer. Your task is to analyze the provided incident context and generate a decision tree of remediation options. For each option, you must reason about the risk, blast radius, rollback feasibility, and expected time-to-resolution.

Follow this structure strictly:

1.  **Incident Summary:** Briefly restate the incident based on [INCIDENT_DETAILS].
2.  **Decision Tree:** Generate a branching tree of remediation strategies. Start with a root node representing the immediate decision point.
    *   For each branch (option), provide:
        *   **Action:** A clear, executable description of the remediation step.
        *   **Expected Outcome:** The immediate and downstream effects if successful.
        *   **Risk Assessment:** Rate as Low/Medium/High and explain the rationale, considering [SYSTEM_CONSTRAINTS].
        *   **Blast Radius:** Specify which users, services, or data will be affected.
        *   **Rollback Plan:** A concrete, step-by-step procedure to reverse the action, including an estimated time to complete the rollback.
        *   **Prerequisites:** Any conditions that must be true before this action can be taken (e.g., "database replica lag must be under 5 seconds").
3.  **Recommendation:** Based on the analysis, recommend the single best path forward, prioritizing safety and resolution speed. Justify your choice by comparing it against the other branches.
4.  **Escalation Criteria:** Define the specific conditions under which this plan should be abandoned and escalated to a human incident commander (e.g., "If the rollback fails or takes longer than 10 minutes").

---
**INCIDENT_DETAILS:**
[INCIDENT_DETAILS]

**SYSTEM_CONSTRAINTS:**
[SYSTEM_CONSTRAINTS]

**AVAILABLE_TOOLS:**
[AVAILABLE_TOOLS]

**RISK_LEVEL:** [RISK_LEVEL]

To adapt this template, replace the placeholders with data from your incident. [INCIDENT_DETAILS] should be a dense summary of symptoms, alerts, and affected components. [SYSTEM_CONSTRAINTS] must include critical limits like SLOs, maintenance windows, or known fragile dependencies. [AVAILABLE_TOOLS] should list the specific runbooks, feature flags, or deployment pipelines the model can assume are available. [RISK_LEVEL] sets the overall tone, such as 'SEV1 - revenue impacting' or 'SEV3 - minor latency'. After generating the tree, always have a human reviewer validate the risk assessments and blast radius claims against your internal system knowledge before executing any action.

This prompt is designed to be the reasoning core of an incident command co-pilot, not a standalone chatbot. It should be invoked by an application that has already gathered structured incident context—such as alert payloads, recent deployments, affected service topologies, and current metrics—and injected it into the [INCIDENT_CONTEXT] placeholder. The application layer is responsible for assembling this context, not the prompt. The prompt's job is to generate a structured decision tree of remediation options, each with risk, blast radius, and rollback feasibility assessments, which the application then renders for a human incident commander to review and select from.

To integrate this into a production workflow, wrap the prompt call in a harness that enforces a strict output contract. Before calling the model, validate that [INCIDENT_CONTEXT] contains at minimum: a symptom description, the affected service or component, the time of onset, and any known recent changes. After receiving the model's response, parse the JSON output and validate it against a schema that requires each branch to have a non-empty option, risk_assessment, blast_radius, and rollback_feasibility field. If validation fails, retry once with a more explicit instruction appended to the prompt, such as 'Your previous output was missing required fields. Ensure every remediation branch includes all four required assessments.' If the second attempt fails, escalate to a human on-call with the partial output and a warning that the AI reasoning was incomplete. Log every prompt invocation, the full context, the raw response, and the validation result for post-incident review and prompt iteration.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, as the decision tree can grow quickly with multiple branches and sub-branches. Set the temperature low (0.1–0.3) to prioritize consistent structure over creative exploration. If your incident response platform supports tool use, you can extend this harness by providing a get_recent_deployments or get_service_dependencies tool and instructing the model to call them before generating the tree, but be explicit about the tool call limit to prevent loops during an active incident. Never allow the model to execute remediation steps directly; this prompt is for analysis and recommendation only. The output should always be presented to a human incident commander for approval before any action is taken.