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/statefulset-debugnpx skills add scitix/siclaw --skill statefulset-debuggit clone --depth 1 https://github.com/scitix/siclawWhat 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.00056 | $0.03042 |
| Opus 5 | $0.00028 | $0.01521 |
| Sonnet 5 | $0.00011 | $0.00608 |
| Haiku 4.5 | $0.00006 | $0.00304 |
Grade A, and why
statefulset-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 3d 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 — 281 lines — stays where its author put it; the contents beside it link to each section on GitHub.
StatefulSet Rollout & Scaling Failure Diagnosis
When a StatefulSet rollout is stuck, pods are not updating, or scaling is not progressing, 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 modify the StatefulSet, delete pods, or change PVCs — that should be left to the user.
When to use: A StatefulSet is not progressing — pods are not updating to the new version, scaling up/down is stuck, or specific ordinal pods are not becoming ready.
Not for Deployments: Deployment rollouts have different semantics (parallel, unordered). Use deployment-rollout-debug for Deployments.
Key Concepts
StatefulSets differ fundamentally from Deployments:
- Fixed pod identity — pods have stable names with ordinal suffixes (pod-0, pod-1, ...)
- Ordered operations — updates go in reverse order (N-1 → 0), scaling up goes in forward order (0 → N-1)
- Per-pod PVCs — each pod gets its own PersistentVolumeClaim via
volumeClaimTemplates - Blocking progression — in OrderedReady mode (default), if pod at ordinal K is not Ready, all pods with ordinal < K will NOT be updated
Diagnostic Flow
1. Get StatefulSet overview
kubectl get statefulset <name> -n <ns> -o wide
Compare the columns:
- READY — pods that are running and ready
- REPLICAS — desired replica count (from
spec.replicas) - UP-TO-DATE — pods running the current version (matching
currentRevision==updateRevision)
If READY < REPLICAS or there is no UP-TO-DATE column showing full count, the rollout or scaling is incomplete.
2. Describe the StatefulSet
kubectl describe statefulset <name> -n <ns>
Focus on:
- Update Strategy —
RollingUpdateorOnDelete - Partition — if set, only pods with ordinal ≥ partition are updated
- maxUnavailable — if set (Kubernetes 1.24+), allows multiple pods to be updated simultaneously instead of one-at-a-time
- Current Revision / Update Revision — if different, an update is in progress
- Events — look for errors or warnings
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.
- 3d ago First seen · 281 lines · 56 tokens per session scan A 5323497ab06f
statefulset-debug is a skill published in the GitHub repository scitix/siclaw (230 stars, last pushed 4d ago), licensed Apache-2.0. It adds 56 tokens to every session and 3,042 once invoked, about $0.0003 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 覆盖从症状识别到修复验证的完整闭环。.
k8s-pod-rightsizer
Analyze Kubernetes workload metrics and produce policy-constrained CPU/memory rightsizing recommendations with optional patch generation and rollback-safe apply.
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.
k8s-service-connectivity
Service 连通性问题通常由 Endpoints 缺失、Selector 不匹配、[[networkpolicy|NetworkPolicy]] 阻断或 kube-proxy 异常引起。.
k8s-node-notready
Kubernetes 节点 NotReady 状态的完整诊断-修复-验证工单处理 Skill.