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/yindia/rootcause/k8s-deploynpx skills add yindia/rootcause --skill k8s-deploygit clone --depth 1 https://github.com/yindia/rootcauseWrote 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/yindia/rootcause/k8s-deploy)<a href="https://agentmods.dev/skills/yindia/rootcause/k8s-deploy"><img src="https://agentmods.dev/badge/skills/yindia/rootcause/k8s-deploy.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.00000 | $0.02865 |
| Opus 5 | $0.00000 | $0.01432 |
| Sonnet 5 | $0.00000 | $0.00573 |
| Haiku 4.5 | $0.00000 | $0.00286 |
Grade A, and why
k8s-deploy 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 4d 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 — 444 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: k8s-deploy
Safe Kubernetes deployment workflows using RootCause MCP tools only.
This skill enforces one deployment principle: preflight first, then deploy, then verify evidence.
Never run write operations without safety checks.
Scope
Use this skill for:
- rollout-based deployment changes on Deployments
- image updates and rollout restarts
- Helm release installation and upgrades
- replica scaling as part of release cutover
- post-deploy health verification and rollback signals
Do not use this skill for:
- deep incident forensics (use
k8s-incident) - cluster capacity planning (use
k8s-diagnostics) - generalized CRUD exploration (use
k8s-core)
Canonical Pattern
Safe deployment pattern:
- Preflight
- Deploy
- Verify
- Decide continue or roll back
The default path is RollingUpdate for Deployments.
For trade-off guidance, read references/STRATEGIES.md.
Required Tool Order
Before every write path:
k8s.safe_mutation_preflight- Deploy tool (
k8s.applyorhelm.installorhelm.upgradeork8s.rolloutork8s.scale) k8s.rolloutwithaction: "status"k8s.events_timelinefor warningsk8s.resource_usagefor saturation signals
Triggers
Activate when user asks for:
- deploy
- release
- rollout
- restart deployment
- helm install
- helm upgrade
- scale replicas
- canary preparation
- blue-green handoff planning
Safety Contract
- Every write call must set
confirm: true - Preflight must be run before every write call
- Restarts must run
k8s.restart_safety_checkfirst - If preflight fails, stop and report blockers
- If rollout status is not healthy, do not chain more writes
Tool Map
| Stage | RootCause Tool | Why |
|---|---|---|
| Preflight | k8s.safe_mutation_preflight |
catch policy, quota, disruption, and ownership blockers |
| Restart risk gate | k8s.restart_safety_check |
avoid unsafe rolling restarts |
| Quality gate | k8s.best_practice |
identify resilience gaps before release |
| Raw manifest deploy | k8s.apply |
server-side apply with ownership tracking |
| Rollout monitor | k8s.rollout |
verify progression to healthy state |
| Scale control | k8s.scale |
controlled replica changes |
| Release diff | helm.diff_release |
preview changes before Helm mutation |
| Helm install | helm.install |
first release creation |
| Helm upgrade | helm.upgrade |
release update path |
| Helm status | helm.status |
release health and notes |
| Timeline verification | k8s.events_timeline |
warning sequence after deploy |
| Runtime pressure | k8s.resource_usage |
CPU/memory stress after rollout |
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 4d ago First seen · 444 lines · 0 tokens per session scan A 7501c8378f08
k8s-deploy is a skill published in the GitHub repository yindia/rootcause (42 stars, last pushed 3mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,865 tokens. 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
bazel-k8s-expert
Expert knowledge for deploying Quarkus/Java applications to Kubernetes using Bazel. Covers rulesk8s, Helm, Kustomize, ConfigMaps, Secrets, and health probes.
upgrade-cluster
Use when upgrading or hardening an existing kube-hetzner cluster, including module version bumps, provider lockfile refreshes, k3s/RKE2 channel/version upgrades, immutable node replacement, system-upgrade-controller changes, or live cluster rollout validation.
dependabot-batch
Use when reviewing Radar's weekly Dependabot PRs and replacing the safe, 72-hour-soaked updates with one changelog-vetted, tested PR.
test-radar
Use when building and testing Radar changes with the repository's real-instance smoke-test workflow.
visual-test
Use when visually testing Radar UI changes against a real Kubernetes cluster with Playwright screenshots.
nvca-self-managed-install
Install or validate the NVCA Operator chart against a self-managed NVCF control plane from the native monorepo. Use when the control plane comes from deploy/stacks/self-managed and NVCA must be installed with stack-derived image repository settings.