Diagnose CrashLoopBackOff and friends without the kubectl marathon
Give it a namespace or pod name and it runs the full kubectl diagnostic sequence for you — events, logs, describe, resource usage — then explains what's actually wrong in plain English. No more chaining five commands to find out you're missing an environment variable.
Create a skill called "Pod Doctor". When I give you a Kubernetes namespace and optionally a pod name, run this diagnostic sequence: 1. `kubectl get events --sort-by=.lastTimestamp -n <namespace>` 2. `kubectl get pods -n <namespace>` (or specific pod) 3. `kubectl describe pod <pod> -n <namespace>` for any unhealthy pods 4. `kubectl logs <pod> -n <namespace>` (and `--previous` if the pod restarted) 5. `kubectl top pod -n <namespace>` if metrics-server is available Correlate the findings and explain in plain English: - What's wrong (root cause) - Why it's happening (the mechanism) - How to fix it (exact YAML change or command) Common patterns to check: OOMKilled, CrashLoopBackOff, ImagePullBackOff, CreateContainerConfigError, pending pods (scheduling failures), probe failures, and resource quota exhaustion.
Pod Doctor runs the diagnostic sequence that experienced K8s engineers do
from muscle memory: get events, describe pod, check logs (current and
previous), inspect resource usage, and verify configs. Then it correlates
everything and tells you the problem.
Stack traces in, root cause out
Paste a wall of logs, a stack trace, or a cryptic error message and get a plain-English root-cause analysis plus a likely fix. Great for showing how OpenClaw handles messy technical input.
Prove it's DNS in 30 seconds instead of suspecting it for 3 hours
Systematic DNS debugging: checks resolution from multiple nameservers, validates record chains, detects dangling CNAMEs, verifies DNSSEC, and audits DMARC/SPF/DKIM for email deliverability. Because it's always DNS.
A playbook for "stops at the same frame" and "freeze mid-render" failures
Renders freeze at a consistent percentage or frame — often caused by a bad clip, a heavy effect, a Fusion comp issue, or "stop render on error" settings. This recipe classifies the failure pattern and gives you a structured triage plan instead of blind re-exports.
Fix a common Premiere playback-lag issue caused by audio input device settings
Severe playback lag and stutter in Premiere Pro that looks like a codec performance problem but is actually caused by audio hardware input settings. This recipe provides a quick decision tree to test and fix the issue — often resolved in under a minute by switching the default input to "No Input."