DevOps / SRE Engineer

Start here

Widely used and core to this role

• GitHub Copilot(opens in new tab)

  · AI coding assistant

  Drafting Terraform, Kubernetes manifests, pipeline files and scripts in the IDE, with changes reviewed in a pull request.

• Checkov(opens in new tab)

  · Security

  Scanning Terraform, CloudFormation, Kubernetes and Helm files for misconfigurations in CI, including AI-generated ones.^[7]

• OpenTelemetry(opens in new tab)

  · Observability

  Vendor-neutral traces, metrics and logs, including GenAI conventions for token counts, model names and LLM call durations.^[8]

Also worth a look

Depends on your team and stack

Written from the changes above. Read and adapt one before you use it.

• Incident postmortem draftDrafts a blameless incident postmortem from logs and notes, flagging unsupported claimsincident-postmortem-draftView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named incident-postmortem-draft. When to use it: Drafts a blameless incident postmortem from chat logs, alerts, metrics, deploy history and responder notes, building an evidence-linked timeline, contributing factors and proposed action items, and marking every claim that lacks evidence. Use after an outage or incident when asked to write a postmortem, incident report, incident review, incident retrospective or timeline, or to check an AI-drafted postmortem against the evidence.

  ---
  name: incident-postmortem-draft
  description: Drafts a blameless incident postmortem from chat logs, alerts, metrics, deploy history and responder notes, building an evidence-linked timeline, contributing factors and proposed action items, and marking every claim that lacks evidence. Use after an outage or incident when asked to write a postmortem, incident report, incident review, incident retrospective or timeline, or to check an AI-drafted postmortem against the evidence.
  metadata:
    title: "Incident postmortem draft"
    summary: "Drafts a blameless incident postmortem from logs and notes, flagging unsupported claims"
  ---
  
  # Incident Postmortem Draft
  
  Draft a blameless postmortem in which every statement is tied to evidence, so responders can correct it before it is shared.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The incident ID, severity, affected services and the time window, with time zone.
  - Incident channel or chat export, pager and alert history.
  - Relevant metrics, dashboards or log excerpts (exported, not live access unless allowed).
  - Deploy, configuration and feature flag change history for the window.
  - Responder notes and the names or roles of people involved.
  - The team's postmortem template, if one exists.
  - Rules on what incident data may be shared and with whom.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Normalise all timestamps to one time zone and say which one.
  2. Build the timeline from sources, one event per row: detection, alerts, key observations, hypotheses, decisions, mitigations, recovery and all-clear. Link every row to its source.
  3. Mark gaps: periods with no evidence, conflicting timestamps and events mentioned by only one person.
  4. Separate what happened from what people believed at the time. Record hypotheses that were tested and ruled out; they matter for learning.
  5. Describe impact with evidence: who was affected, what they experienced, for how long. Leave numbers blank if the data is not provided, rather than estimating.
  6. Identify contributing factors, not a single root cause: technical conditions, recent changes, detection gaps, missing or unclear runbooks, tooling problems, and coordination issues.
  7. Note what went well, including what helped detection and recovery.
  8. If an AI tool or agent took part in investigation or mitigation, record what it suggested, what humans approved and whether the suggestion was correct.
  9. Propose action items that address contributing factors. Each should be specific and checkable. Leave owners and due dates for the team to assign.
  10. Write in blameless language: describe actions and the context that made them reasonable, never fault individuals.
  11. Review your own draft against the evidence one more time, and label every sentence that is not directly supported as "Unverified".
  12. Do not file tickets, post the document or notify anyone. Produce the draft only.
  
  ## Output format
  
  ```markdown
  # Postmortem (DRAFT): <incident title>
  
  - **Incident ID:** <id> | **Severity:** <level> | **Status:** Draft for responder review
  - **Time zone:** <tz> | **Duration:** <start> to <end>
  
  ## Summary
  
  <3–5 sentences>
  
  ## Impact
  
  <who, what, how long, with evidence references>
  
  ## Timeline
  
  | Time | Event | Source | Confidence            |
  | ---- | ----- | ------ | --------------------- |
  |      |       |        | Verified / Unverified |
  
  ## Evidence gaps and conflicts
  
  - <item>
  
  ## Contributing factors
  
  - <factor> — evidence: <reference>
  
  ## Hypotheses ruled out
  
  - <hypothesis> — how it was ruled out
  
  ## AI and automation involvement
  
  - <what was suggested, what was approved, whether it was correct, or "none">
  
  ## What went well
  
  - <item>
  
  ## Proposed action items
  
  | #   | Action | Addresses factor | Type (prevent / detect / mitigate / process) | Owner (TBD) |
  | --- | ------ | ---------------- | -------------------------------------------- | ----------- |
  
  ## Assumptions and open questions
  
  - <assumption or question, and which responder can confirm>
  ```
  
  ## Watch out for
  
  - A postmortem can have the right shape and still be wrong, with no obvious test for correctness. Evidence links are the check.
  - Filling gaps with plausible events. If no source shows it, it is a gap.
  - Picking a single root cause when several factors combined.
  - Hindsight wording ("should have known", "failed to") that assigns blame.
  - Mixing time zones from different tools.
  - Personal data, customer details or secrets copied from logs into the draft. Never reproduce secrets, tokens, credentials or personal data in the output; refer to them by location and type, and tell the user to rotate anything exposed.
  - Action items that are vague ("improve monitoring") or that only target the last person to act.
  
  ## Before you finish
  
  - [ ] Every timeline row has a source and a confidence label.
  - [ ] Unsupported sentences are marked "Unverified".
  - [ ] Gaps and conflicting evidence are listed.
  - [ ] Language is blameless throughout.
  - [ ] No personal data or secrets are included.
  - [ ] Nothing was posted, filed or sent.
  - [ ] Clearly flag your assumptions, every unverified statement, and the conclusions and action item owners that responders must review and decide.
  

• Infrastructure change reviewReviews an infrastructure code change for security risks, blast radius and rollbackiac-change-reviewView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named iac-change-review. When to use it: Reviews an infrastructure-as-code change, such as Terraform, CloudFormation, Kubernetes manifests, Helm charts or pipeline files, for security misconfigurations, blast radius, drift from the live environment, destructive operations and rollback, whether a person or an AI wrote it. Use when reviewing an infrastructure pull request, an AI-generated IaC change, a plan output before apply, or when asked "is this infrastructure change safe".

  ---
  name: iac-change-review
  description: Reviews an infrastructure-as-code change, such as Terraform, CloudFormation, Kubernetes manifests, Helm charts or pipeline files, for security misconfigurations, blast radius, drift from the live environment, destructive operations and rollback, whether a person or an AI wrote it. Use when reviewing an infrastructure pull request, an AI-generated IaC change, a plan output before apply, or when asked "is this infrastructure change safe".
  metadata:
    title: "Infrastructure change review"
    summary: "Reviews an infrastructure code change for security risks, blast radius and rollback"
  ---
  
  # IaC Change Review
  
  Review an infrastructure-as-code change for security and operational risk, and draft findings before anyone applies it.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The diff or pull request, and the environment(s) it targets.
  - The plan or dry-run output, produced by the team's pipeline or a person with access.
  - Results from the team's IaC security scanners and policy checks, if they ran.
  - The purpose of the change and the ticket or request behind it.
  - Relevant state: current resources, recent drift, ongoing migrations or maintenance windows.
  - Organisation rules for network exposure, encryption, tagging, identity and cost.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Restate the intended change in one or two sentences. Flag changes in the diff that go beyond it.
  2. Read the plan or dry-run output, not just the code. List every resource to be created, changed, replaced or destroyed. Treat replacements and destroys as high attention.
  3. Check that the plan matches the diff. Unexpected changes can mean drift between code and the live environment, a provider or module version change, or state problems. Flag them; do not try to fix state.
  4. Run a security pass on every changed resource, even when the code is well formed:
     - network exposure: open ingress, public endpoints, public storage;
     - identity and access: wildcard permissions, broad roles, long-lived keys;
     - encryption at rest and in transit, and key management;
     - logging, auditing and backups turned off or reduced;
     - secrets in code, variables, outputs or state.
  5. Compare the scanner results with your own findings. Note findings the scanner missed and scanner findings that were suppressed, with the reason given.
  6. Assess blast radius: which services, environments and teams depend on the changed resources.
  7. Check data safety: databases, volumes, queues and buckets that could lose data on replace or destroy, and whether deletion protection is set.
  8. Check timing and state: whether the change is safe given the current system state, such as in-flight deploys, configuration pushes, migrations or peak traffic.
  9. Check rollback: how to reverse the change, and whether any part cannot be reversed.
  10. Check versions and dependencies: pinned providers, modules, images and charts from expected sources.
  11. Do not run apply, deploy, delete or any command that changes infrastructure or state. Read-only commands such as format checks or validation are fine if allowed.
  12. Draft the review with a recommendation.
  
  ## Output format
  
  ```markdown
  ## IaC review: <PR or change title>
  
  - **Target environment(s):** <env>
  - **Recommendation:** Approve / Approve with changes / Block / Needs plan output
  - **Irreversible operations present:** Yes / No
  
  ### Planned operations
  
  | Resource | Operation (create / update / replace / destroy) | Expected from diff? | Data at risk? |
  | -------- | ----------------------------------------------- | ------------------- | ------------- |
  
  ### Security findings
  
  | #   | Severity            | Resource | Issue | Scanner caught it?    | Suggested fix |
  | --- | ------------------- | -------- | ----- | --------------------- | ------------- |
  | 1   | High / Medium / Low |          |       | Yes / No / Suppressed |               |
  
  ### Drift and unexpected changes
  
  - <item, or "none found">
  
  ### Blast radius
  
  - <dependent services and environments>
  
  ### State and timing check
  
  - <current conditions that make this change safe or unsafe now>
  
  ### Rollback plan
  
  - <steps, and what cannot be rolled back>
  
  ### Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Code that is syntactically valid and still insecure. Passing validation is not a security review.
  - Relying on prompting or on the author's description; check every resource yourself and still require automated scanning.
  - Replacements hidden behind small attribute changes that force a resource to be recreated.
  - A change that is safe in one system state and unsafe in another, such as during a migration or configuration push.
  - Scanner suppressions added in the same change without explanation.
  - Reviewing code without the plan output. Say clearly that the review is incomplete.
  - Secrets exposed through outputs, logs or state rather than source code.
  - Never reproduce secrets, tokens, credentials or personal data in the output; refer to them by location and type, and tell the user to rotate anything exposed. Do not copy plan or state excerpts that contain sensitive values; mask them.
  
  ## Before you finish
  
  - [ ] Every replace and destroy is listed with its data risk.
  - [ ] The security pass covers every changed resource.
  - [ ] Scanner results are compared with your findings, including suppressions.
  - [ ] Current system state and timing were considered.
  - [ ] No apply, deploy or state-changing command was run.
  - [ ] No secret, token, credential or personal data value appears in the output; plan or state excerpts with sensitive values are masked, and anything exposed is flagged for rotation.
  - [ ] Clearly flag your assumptions, whether plan output was available, and the approval and timing decisions a human must make.
  

• Mitigation safety checkChecks if a proposed incident action, like a rollback, is safe in the current system statemitigation-safety-checkView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named mitigation-safety-check. When to use it: Checks whether a proposed operational action during an incident, such as a rollback, restart, failover, scale change, config change or traffic shift, is safe given the current system state, and checks an AI investigation's suggested cause against the evidence before any action is recommended. Use during an incident or on-call when an agent or person proposes a mitigation, when asked "is it safe to roll back", or when verifying an AI-suggested root cause.

  ---
  name: mitigation-safety-check
  description: Checks whether a proposed operational action during an incident, such as a rollback, restart, failover, scale change, config change or traffic shift, is safe given the current system state, and checks an AI investigation's suggested cause against the evidence before any action is recommended. Use during an incident or on-call when an agent or person proposes a mitigation, when asked "is it safe to roll back", or when verifying an AI-suggested root cause.
  metadata:
    title: "Mitigation safety check"
    summary: "Checks if a proposed incident action, like a rollback, is safe in the current system state"
  ---
  
  # Mitigation Safety Check
  
  Check a proposed mitigation against the current system state and the evidence, and give the incident lead a clear, reasoned recommendation to approve or reject.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The proposed action, exactly as it would be run, and who or what proposed it.
  - The suspected cause and the evidence behind it (alerts, logs, traces, metrics, recent changes).
  - The affected service, environment and region.
  - Current state: in-progress deploys, configuration pushes, migrations, failovers, maintenance, traffic level.
  - The relevant runbook or playbook, if one exists.
  - Who is the incident lead and who can approve actions.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Restate the proposed action and the problem it is meant to solve in one or two sentences.
  2. Check the suspected cause against the evidence. For each piece of supporting evidence, open the underlying signal (log lines, metric, trace, change record) and confirm it says what the suggestion claims. Note evidence that contradicts the hypothesis and alternative causes that fit the same signals.
  3. Check timing: did the suspected trigger happen before the symptoms began, in the affected scope only?
  4. Classify the action as read-only, reversible or destructive, and say why.
  5. Check current system state before judging safety. An action that is normally safe can be unsafe right now. Look for in-progress configuration pushes, deploys, schema or data migrations, ongoing failovers, dependent services under stress, and caches or queues that would be disrupted.
  6. Check dependencies: what else the action touches, such as shared databases, other services on the same cluster, or clients that expect the current version.
  7. Check data safety: whether the action can lose, duplicate or corrupt data, or break compatibility with data written since the last change.
  8. Check the runbook. Note where the proposal matches it, departs from it, or where the runbook looks out of date.
  9. Define how success and failure will be recognised: which signals should improve, within what time, and what indicates the action made things worse.
  10. Write the rollback or abort plan for the action itself.
  11. Consider a safer alternative, such as a smaller scope, a single region or instance first, or a read-only diagnostic step.
  12. Do not run the action or any command that changes the system. Only read-only queries, if allowed. The decision belongs to the incident lead.
  
  ## Output format
  
  ```markdown
  ## Mitigation safety check
  
  - **Proposed action:** <exact action>
  - **Proposed by:** <person / agent / tool>
  - **Action class:** Read-only / Reversible / Destructive
  - **Recommendation:** Proceed / Proceed with conditions / Do not proceed / Need more information
  - **Confidence:** High / Medium / Low
  
  ### Cause check
  
  | Claim | Evidence checked | Supports / Contradicts / Unclear |
  | ----- | ---------------- | -------------------------------- |
  
  - Alternative causes still possible: <list>
  
  ### Current state check
  
  | Condition                         | Present? | Effect on safety |
  | --------------------------------- | -------- | ---------------- |
  | Deploy or config push in progress |          |                  |
  | Migration in progress             |          |                  |
  | Failover or maintenance under way |          |                  |
  | Dependent services degraded       |          |                  |
  
  ### Risks of acting
  
  - <item>
  
  ### Success and failure signals
  
  - Expect: <signal and time window>
  - Abort if: <signal>
  
  ### Rollback or abort plan
  
  1. <step>
  
  ### Safer alternative
  
  - <option, or "none identified">
  
  ### Needs human decision
  
  - <item>
  
  ### Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - An action that is safe in one state and unsafe in another, such as a rollback during a configuration push.
  - AI-suggested causes that sound convincing but rest on a correlation or a misread signal. Check the underlying data, not the summary.
  - Confirmation bias: looking only for evidence that supports the first hypothesis.
  - Stale state information. Note when each state check was made.
  - Actions scoped wider than needed, such as all regions instead of one.
  - Pressure to act fast. A short, clear "need more information" is better than a guess.
  - Never reproduce secrets, tokens, credentials or personal data from logs, traces or configs in the output; refer to them by location and type, and tell the user to rotate anything exposed.
  
  ## Before you finish
  
  - [ ] Every claimed piece of evidence was checked against its source.
  - [ ] Current system state was checked, with the time of each check noted.
  - [ ] The action is classified, and rollback and abort signals are defined.
  - [ ] You ran no command that changes the system.
  - [ ] Clearly flag your assumptions, your confidence, anything you could not verify, and that the incident lead must approve or reject the action.