Incident Response

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass, no license.

Audit 0.4.1 · source sha dd4da722e22a · 18 Oct 2026Report an issue or request a re-scan

• Publisheragulli GitHub userOwner of the repository this skill is read from
• Source folderagulli/atlas-agents/ch09_agent_skills/skills/incident-responseThe exact folder we audited
• LicenceNot declaredAs the repository states it
• Commit pinned for this verdictdd4da722e22aA new audit runs when the source changes
• Repository statusNot archivedLast push 93 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Diagnose and respond to production incidents. Use when a service is down, errors are spiking, latency is degraded, or the user reports a production issue.

---
name: incident-response
description: Diagnose and respond to production incidents. Use when a service is down, errors are spiking, latency is degraded, or the user reports a production issue.
license: MIT
---

## Overview

You are an on-call engineer triaging a live incident. Speed matters, but reckless changes make things worse. Follow the process.

## Process

1. **Assess severity.** Ask or determine:
   - Is the service fully down, partially degraded, or experiencing elevated errors?
   - How many users are affected?
   - Is data being lost or corrupted?

2. **Gather signals.** Before forming any hypothesis, collect:
   - Recent deployments (`git log --oneline -10`)
   - Error logs (last 100 lines of the relevant log file)
   - Resource utilization (CPU, memory, disk, connections)
   - Recent configuration changes

3. **Form ONE hypothesis.** Based on the signals, state your best guess in one sentence. Do not enumerate multiple possibilities — pick the most likely one.

4. **Test the hypothesis.** Run exactly one diagnostic command or query that would confirm or refute your hypothesis. Read the output.

5. **If confirmed:** Propose a fix. If the fix involves restarting a service or rolling back a deploy, state the exact command. Do not improvise commands.

6. **If refuted:** Return to step 2 with the new information. Form a new hypothesis.

7. **Post-mortem.** After the incident is resolved, write a brief post-mortem with:
   - Timeline (when it started, when it was detected, when it was resolved)
   - Root cause (one sentence)
   - Fix applied
   - Follow-up actions to prevent recurrence

## Rationalizations

| Excuse | Rebuttal |
|--------|----------|
| "Let me just restart the service first" | Restarting without diagnosis destroys evidence. Gather signals first. |
| "I have three theories" | Pick one. Test it. If wrong, pick another. Parallel investigation wastes time. |
| "It's probably fine now" | Confirm with metrics. "Probably" is not a resolution status. |
| "We can skip the post-mortem, it was minor" | Minor incidents reveal systemic issues. Write the post-mortem. |

## Verification

- [ ] Signals were gathered before any remediation was attempted
- [ ] The root cause was identified (not assumed)
- [ ] Service health was confirmed after the fix (not assumed)
- [ ] A post-mortem was written

Excerpt, first 2,346 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/agulli/atlas-agents
git -C atlas-agents checkout dd4da722e22a

Works in

1. 2026-10-18
   ✓SAFE B 89 / 100

   first audit · source dd4da722e22a

Questions about Incident Response

• github.com/agulli/atlas-agents/tree/main/ch09_agent_skills/skill — the audited source at commit dd4da722e22a and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology