Incident Troubleshooting
Purpose
You help recover service with discipline. First reduce user impact, then investigate. Keep evidence and timing clear so the team can learn without turning the incident into guesswork.
Operational context
- Read
references/workflow.md.
- Identify symptom, start time, impact, affected systems, recent changes, available observability, access limits, and change freeze constraints.
- Verify current documentation for recovery commands, platform limitations, and tool syntax before suggesting risky remediation.
Safe change sequence
- Stabilize and define the smallest safe mitigation.
- Establish blast radius and user impact.
- Build a timeline from alerts, deploys, logs, metrics, traces, events, and human reports.
- Form hypotheses and test the lowest-risk checks first.
- Recover service or prepare rollback with clear approval points.
- Capture root cause evidence, prevention actions, and follow-up owners.
Safety rules
- Use Context7 MCP for current cloud, Kubernetes, IaC, CI/CD, container, observability, security, network, API, CLI, provider, and configuration documentation whenever the task depends on external technology behavior.
Change record
Provide situation summary, immediate stabilization, hypotheses, checks/commands, recovery plan, prevention notes, risks, and assumptions.
Verification
- Do not make several risky changes at once.
- Prefer symptom mitigation before deep investigation.
- Mark workarounds as temporary.
- Keep evidence separate from hypotheses.
- Preserve data needed for post-incident review.
Handoff
Add the affected domain skill: kubernetes-operations, cloud-operations, cicd-automation, observability-operations, network-vpn-security, or another matching skill.
References
references/workflow.md for incident flow, stabilization, evidence capture, and recovery guidance.
1---2name: incident-troubleshooting3description: Use for incidents, outages, degradation, failed deployments, performance regressions, emergency diagnostics, stabilization, timelines, hypotheses, recovery plans, rollback, evidence capture, root cause notes, and prevention actions.4---56# Incident Troubleshooting78## Purpose910You help recover service with discipline. First reduce user impact, then investigate. Keep evidence and timing clear so the team can learn without turning the incident into guesswork.1112## Operational context13141. Read `references/workflow.md`.152. Identify symptom, start time, impact, affected systems, recent changes, available observability, access limits, and change freeze constraints.163. Verify current documentation for recovery commands, platform limitations, and tool syntax before suggesting risky remediation.1718## Safe change sequence19201. Stabilize and define the smallest safe mitigation.212. Establish blast radius and user impact.223. Build a timeline from alerts, deploys, logs, metrics, traces, events, and human reports.234. Form hypotheses and test the lowest-risk checks first.245. Recover service or prepare rollback with clear approval points.256. Capture root cause evidence, prevention actions, and follow-up owners.2627## Safety rules2829- Use Context7 MCP for current cloud, Kubernetes, IaC, CI/CD, container, observability, security, network, API, CLI, provider, and configuration documentation whenever the task depends on external technology behavior.3031## Change record3233Provide situation summary, immediate stabilization, hypotheses, checks/commands, recovery plan, prevention notes, risks, and assumptions.3435## Verification3637- Do not make several risky changes at once.38- Prefer symptom mitigation before deep investigation.39- Mark workarounds as temporary.40- Keep evidence separate from hypotheses.41- Preserve data needed for post-incident review.4243## Handoff4445Add the affected domain skill: `kubernetes-operations`, `cloud-operations`, `cicd-automation`, `observability-operations`, `network-vpn-security`, or another matching skill.4647## References4849- `references/workflow.md` for incident flow, stabilization, evidence capture, and recovery guidance.