Graceful Degradation Runbook Prompt

This prompt is designed for Site Reliability Engineers (SREs) and platform engineering teams who need to convert a degradation event in a multi-agent system into a structured, actionable operational runbook. The core job-to-be-done is accelerating the creation of a consistent, reviewable artifact that documents the failure, the response procedure, and the verification steps. Use it when an agent in your chain has failed, timed out, or produced degraded output, and you have a detailed incident record including the failure context, affected components, and available telemetry. It is not a replacement for your incident management process; it is a tool to produce a standardized runbook draft that your on-call team can review, approve, and execute.

The ideal user is an engineer who already understands the system architecture and the specific failure but needs to produce documentation that others can follow under pressure. The prompt requires a structured incident record as input, including the failed agent's role, the degradation trigger, the blast radius, and any partial results or error logs. Without this context, the generated runbook will be generic and unsafe. The prompt explicitly instructs the model to mark uncertainty, avoid fabricating recovery steps, and flag sections that require human completion. This makes it suitable for high-severity incidents where procedural errors could compound the original failure.

Do not use this prompt for real-time automated incident response. It is a documentation-generation tool, not a control-plane component. It should never be wired directly to a circuit breaker or retry controller. The output is a human-readable runbook that must be reviewed before execution. Avoid using it for low-severity events where a full runbook is overhead, or for incidents where the root cause is unknown and the prompt would force the model to speculate. In those cases, use a failure mode classification prompt first, then feed the classified incident into this runbook prompt. Always pair the output with a human approval step before the runbook is published to your incident response channel.

This prompt template is the core instruction set for generating a structured runbook from a degradation event. It is designed to be wired into an SRE automation pipeline where an event payload (alerts, logs, incident timeline) is provided as input. The prompt enforces a strict output schema, requires step-by-step procedural reasoning, and includes explicit placeholders for the incident context, risk level, and evaluation criteria. Use this template as the starting point for your runbook generation agent; pair it with the implementation harness to add validation, retries, and human approval gates before the runbook is published to your incident response platform.

textCopy
You are an SRE runbook authoring agent. Your task is to generate a clear, actionable operational runbook from a provided degradation event. The runbook must be safe to execute, ordered correctly, and complete enough for an on-call engineer to follow under pressure.

## INPUT
[INCIDENT_CONTEXT]

## CONSTRAINTS
- Do not invent steps, commands, or metrics not present in the input context.
- If information is missing for a required section, mark it explicitly as '[TO BE DETERMINED]' and explain what is needed.
- Order all procedural steps by dependency: verification before mitigation, rollback before close.
- Flag any step that requires human approval with '[APPROVAL REQUIRED]'.
- The risk level for this runbook is [RISK_LEVEL]. For 'high' risk, include a rollback plan for every state-changing step.

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "runbook_id": "string",
  "generated_at": "ISO 8601 timestamp",
  "degradation_trigger": {
    "summary": "string (one-sentence description of the event)",
    "alert_sources": ["string"],
    "severity": "critical|high|medium|low",
    "impact_scope": "string (affected services, users, or regions)"
  },
  "pre_remediation_checks": [
    {
      "step_number": "integer",
      "instruction": "string",
      "expected_result": "string",
      "on_failure": "string (next action if check fails)"
    }
  ],
  "response_procedures": [
    {
      "phase": "detection|containment|mitigation|recovery",
      "step_number": "integer",
      "instruction": "string",
      "owner_role": "string",
      "approval_required": "boolean",
      "rollback_step": "string or null"
    }
  ],
  "rollback_plan": {
    "trigger_condition": "string",
    "steps": [
      {
        "step_number": "integer",
        "instruction": "string",
        "verification": "string"
      }
    ]
  },
  "post_degradation_verification": [
    {
      "step_number": "integer",
      "check": "string",
      "pass_criteria": "string"
    }
  ],
  "missing_information": ["string (list of fields that could not be populated from input)"]
}

## EXAMPLES
[EXAMPLES]

## EVALUATION CRITERIA
After generating the runbook, self-evaluate against these checks:
1. Are all procedural steps ordered by dependency (verify before act)?
2. Does every state-changing step have a rollback instruction if risk is 'high'?
3. Are there no invented commands, metrics, or service names?
4. Is every 'TO BE DETERMINED' field accompanied by a description of what information is needed?
5. Is the runbook complete enough for an on-call engineer to execute without additional research?

If any check fails, revise the runbook before output.

To adapt this template for your environment, replace the square-bracket placeholders with your pipeline variables. [INCIDENT_CONTEXT] should receive a structured payload containing alerts, logs, and timeline data from your observability stack. [RISK_LEVEL] should be set by your incident classifier upstream. [EXAMPLES] should contain one or two few-shot examples of well-formed runbooks from past incidents in your infrastructure, formatted to match the output schema. If you are using a model with a small context window, truncate the examples to the most critical sections—pre-remediation checks and response procedures—and omit the full schema in the examples. Always validate the generated JSON against the schema before forwarding it to your runbook automation platform; a malformed runbook is worse than no runbook at all.

This prompt is designed to be called from an incident management platform (e.g., PagerDuty, ServiceNow, or a custom orchestrator) after a degradation event is declared. The application layer must assemble the [DEGRADATION_EVENT_LOG], [AFFECTED_SERVICES], and [CURRENT_INCIDENT_TIMELINE] from monitoring systems, not from free-text operator notes. The prompt expects structured input; feeding it raw, unformatted logs will produce unreliable runbooks. The output should be treated as a draft runbook that requires human approval before it is published to the team's runbook repository or executed in production.

Wire the prompt into a two-stage pipeline. Stage 1: Generation. Call the model with the prompt template, passing the assembled context. Set temperature low (0.1–0.3) to prioritize procedural consistency over creativity. Use a model with strong instruction-following and long-context handling, such as Claude 3.5 Sonnet or GPT-4o. Stage 2: Validation. Parse the generated JSON output and run automated checks before any human sees it: (a) verify the degradation_triggers array is non-empty and each trigger references a specific metric or alert from the input log; (b) confirm response_procedures are ordered and each step includes an owner and expected_duration; (c) check that rollback_instructions exist and reference the specific change or deployment that preceded the degradation; (d) ensure post_degradation_verification contains at least one quantitative check (e.g., 'error rate below 0.1% for 10 minutes'). If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] field. If the retry also fails, escalate to the on-call SRE with the partial output and validation failure summary.

Human review is mandatory before execution. The validated runbook must be surfaced in a review UI that highlights: (a) any step marked with requires_manual_approval: true, (b) rollback instructions that modify production infrastructure, and (c) verification steps that depend on metrics not currently available. Log every generation attempt, validation result, and review decision to the incident timeline for postmortem traceability. Do not automatically execute any runbook step that mutates infrastructure, even if the model marks it as safe. The prompt's [RISK_LEVEL] placeholder should be set by the incident commander, not inferred by the model, and must be high for any degradation affecting customer-facing services. Avoid wiring this prompt into a fully autonomous loop; the cost of a bad runbook executed without review exceeds the latency savings.