メニュー
Use when asked to check cluster health, "what's wrong in k8s", "check pods", or "/k8s-health". Runs a structured Kubernetes health check across nodes, workloads, and recent events.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when reviewing a backend HTTP / GraphQL handler for validation, authz, errors, performance, observability, and security, or "/backend-review". Produces a structured review with file:line citations.
Use when running a cloud security posture scan (CSPM) on AWS, Azure, or GCP using prowler, scout-suite, or checkov, or "/cloud-scan". Requires read-only credentials; produces CIS-benchmark-aligned findings with remediation.
Use when scanning a container image or Dockerfile for vulnerabilities, misconfigurations, and best-practice violations using trivy, dockle, or hadolint, or "/image-scan". Flags base-image CVEs, root user, missing healthchecks, and bloat.
Use when running an authorized non-intrusive DAST baseline scan (OWASP ZAP baseline, nuclei, nikto) against a web app or API endpoint you own, or "/dast". Requires explicit authorization; refuses unowned targets.
Use when handed a stack trace, error log, or "this is broken" with a paste of output, and asked to find the root cause across frontend, backend, or DB tiers, or "/debug-trace". Produces a hypothesis tree, the evidence supporting each branch, and the next diagnostic step.
Use when scanning a project's third-party dependencies for known CVEs across npm, pip, Go, Maven, Cargo, etc., or "/dep-scan". Runs trivy, npm audit, pip-audit, govulncheck, or osv-scanner and produces a prioritized fix list.
| name | k8s-health-check |
| description | Use when asked to check cluster health, "what's wrong in k8s", "check pods", or "/k8s-health". Runs a structured Kubernetes health check across nodes, workloads, and recent events. |
Confirm context. Verify the target cluster before running any commands:
kubectl config current-context
If it doesn't match the user's intent, ask before proceeding.
Cluster-level checks (run in parallel):
kubectl get nodes -o wide # node status + roles
kubectl top nodes # CPU/mem pressure
kubectl get events --all-namespaces \
--field-selector type=Warning \
--sort-by='.lastTimestamp' | tail -20 # recent warnings
Workload checks:
# Not-running pods
kubectl get pods -A --field-selector='status.phase!=Running,status.phase!=Succeeded'
# Recent restarts (>3 restarts is a signal)
kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount' | tail -20
# Pending pods (scheduling issues)
kubectl get pods -A --field-selector=status.phase=Pending
If a specific pod is unhealthy:
kubectl describe pod <name> -n <ns> # events, resource limits, node assignment
kubectl logs <pod> -n <ns> --tail=50 # recent log output
kubectl logs <pod> -n <ns> --previous # logs from crashed container
Report:
## Kubernetes Health Check — <context> — <timestamp>
### Nodes
- X/Y nodes Ready
- <any NotReady nodes and reason>
### Workload issues
| Namespace | Pod | Status | Restarts | Issue |
|---|---|---|---|---|
| <ns> | <pod> | CrashLoopBackOff | 12 | OOMKilled |
### Recent warnings
- <top 3-5 warning events>
### Recommended actions
- [ ] <describe pod X for OOMKilled details>
- [ ] <increase memory limit or fix leak>
kubectl config current-context matches the intended cluster.kubectl delete or any mutating command without explicit user confirmation.kubectl exec into pods only if the user explicitly asks.kubectl top is unavailable (metrics-server not installed), note it and skip resource pressure checks.