Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/scitix/siclaw/pod-crash-debugnpx skills add scitix/siclaw --skill pod-crash-debuggit clone --depth 1 https://github.com/scitix/siclawWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/scitix/siclaw/pod-crash-debug)<a href="https://agentmods.dev/skills/scitix/siclaw/pod-crash-debug"><img src="https://agentmods.dev/badge/skills/scitix/siclaw/pod-crash-debug.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00040 | $0.01294 |
| Opus 5 | $0.00020 | $0.00647 |
| Sonnet 5 | $0.00008 | $0.00259 |
| Haiku 4.5 | $0.00004 | $0.00129 |
Grade A, and why
pod-crash-debug scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 142 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pod Crash Failure Diagnosis
When a pod is stuck in CrashLoopBackOff, Error, OOMKilled, or RunContainerError, follow this flow to identify the root cause.
Scope: This skill is for diagnosis only. Once you identify the root cause, report it to the user and stop. Do NOT attempt to fix the application code or modify resource limits — that should be left to the user.
Diagnostic Flow
1. Read the pod and its surroundings — one call
k8s_inspect(kind: "pod", name: "<pod>", namespace: "<ns>")
This returns, in a single call, everything the first two steps of this flow used to take three or four: the phase, the per-container readiness and restart count, the last termination reason and exit code, the pod's recent events, the state of the node it runs on, and its owner's replica counts.
What to read:
last: OOMKilled exit 137→ memory limit; go to §"OOMKilled" below.last: Error exit <n>→ the application exited; step 2 (previous logs) is the next move.waiting: <reason>→ it never started.ImagePullBackOff/ErrImagePullbelong to theimage-pull-debugskill,CreateContainerConfigErrorto a missing ConfigMap or Secret.- The
nodesection — a node that isReady=False, cordoned, or underMemoryPressureexplains a crash that has nothing to do with the pod. - The final
status:line.partial (node: forbidden)means that section is missing, not empty, so do not conclude the node is healthy; an empty events section means the pod genuinely has none.
Reach for kubectl describe pod <pod> -n <ns> only when you need something the summary does not
carry — volume mounts, the full probe configuration, or the complete event history.
2. Get previous container logs
kubectl logs <pod> -n <ns> --previous --tail=200
If the pod has multiple containers, specify the crashing container:
kubectl logs <pod> -n <ns> -c <container> --previous --tail=200
If --previous fails with "previous terminated container not found", try current logs:
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 142 lines · 40 tokens per session scan A f5740e5448cd
pod-crash-debug is a skill published in the GitHub repository scitix/siclaw (232 stars, last pushed today), licensed Apache-2.0. It adds 40 tokens to every session and 1,294 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
k8s-deployment-rollout
Kubernetes Deployment 发布失败、滚动更新卡住的完整诊断-修复-验证 Skill.
k8s-pod-crashloop
Pod CrashLoopBackOff / OOMKilled 诊断与修复：Pod CrashLoopBackOff 和 OOMKilled 是 Kubernetes 工作负载中最常见的问题类型。本 Skill 覆盖从症状识别到修复验证的完整闭环。.
devops-deployment
Use when setting up CI/CD pipelines, containerizing applications, deploying to Kubernetes, or writing infrastructure as code. DevOps & Deployment covers GitHub Actions, Docker, Helm, and Terraform patterns.
k8s-incident-triage
Read-only Kubernetes incident triage using kubectl. Accepts natural language or structured input. Produces root-cause hypotheses, evidence, and next-step commands.
kubernetes-expert
Expert-level Kubernetes cluster management, deployment strategies, networking, and production operations. Use when the user mentions containers, orchestration, devops, or cloud native, or when the task involves Kubernetes Architecture, Pods, Deployments, or Services.
lucas-runbook
Lucas runbook-driven troubleshooting for Kubernetes issues. Use when investigating pod errors, crashes, restarts, or any Kubernetes problem. Automatically search runbooks before taking action.