Kubernetes Skill
KubeShark skill: the agent finds the failure mode first, then writes manifests, Helm and Kustomize to official practice with a rollback plan
- 465 ★ on the repository
- Last commit
- MIT
Minimal access
Why this level
- The skill is instructions and reference files, and it runs nothing and contacts nothing by itself
- The validation commands it suggests are run by the agent in your environment with your confirmation
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/kubernetes-skillDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewMinimal accessThe tool runs nothing and makes no network calls.
- The skill is instructions and reference files, and it runs nothing and contacts nothing by itself
- The validation commands it suggests are run by the agent in your environment with your confirmation
This is third-party code. Review the repository files before installing.
What it does
Kubernetes Skill, which the author calls KubeShark, gives Claude Code and Codex a working procedure for Kubernetes. Before writing a manifest the agent records the context: cluster version and distribution, namespace, environment criticality, workload type, deployment method, policy enforcement and cloud provider. Anything unknown must be stated as an assumption. The agent then picks one or more of six failure modes: insecure workload defaults, resource starvation, network exposure, privilege sprawl, fragile rollouts and API drift. For the chosen mode it loads only the relevant reference files. Conditional references for EKS, GKE, AKS, OpenShift, Argo CD and Flux, Prometheus Operator and OpenTelemetry load when signs of that platform appear. The skill ends with an output contract: assumptions and the cluster version floor, selected failure modes, tradeoffs, a validation plan and rollback notes. Validation covers kubectl apply --dry-run=server or kubectl diff, kubeconform, label, selector and port consistency, a Pod Security Standards profile check and a Kyverno or OPA Gatekeeper audit. The skill does not recommend applying changes to production without a reviewed diff.
Who it is for. For DevOps engineers and developers who ask Claude Code or Codex to write and review manifests, Helm charts and Kustomize overlays for real clusters.
Good fit when
- You need a Deployment with an Ingress and autoscaling that carries security contexts, resource limits and sound probes
- You want a finished deployment.yaml checked for excess privileges, missing NetworkPolicies and wildcard RBAC
- Manifests with pre-1.22 apiVersion values must move to current APIs
- You need a Helm chart for a PostgreSQL StatefulSet with backup CronJobs
- The cluster runs on EKS, GKE, AKS or OpenShift and the answer must account for platform specifics
Not a fit when
- You want to operate a live cluster from chat: the skill only prepares and reviews files and runs no cluster commands itself
- You need a general infrastructure set for Terraform, Docker and CI: the catalog has separate DevOps sets for that
- The task has nothing to do with Kubernetes: the skill triggers on manifests, Helm, Kustomize and cluster policies
Example request
/kubernetes-skill Review my deployment.yaml for security issues and add proper RBAC, NetworkPolicies and resource limitsLimitations
- The skill is instructions and reference files. It does not connect to a cluster or run kubectl itself: it offers checks as steps for you or the agent.
- Answer quality depends on whether you state the cluster version and platform. Otherwise the agent records assumptions.
- References draw on Kubernetes documentation, the NSA and CISA hardening guide, OWASP Kubernetes Top 10, Pod Security Standards and the CIS Kubernetes Benchmark. On conflict, official Kubernetes documentation wins.
- Codex has no global skills, so the skill is wired into each project through AGENTS.md.
How to disable. Delete ~/.claude/skills/kubernetes-skill or run /plugin uninstall kubernetes-skill if you installed through the marketplace. For Codex remove the .kubernetes-skill paragraph from AGENTS.md and delete the cloned folder.
FAQ
How do I install Kubernetes Skill in Claude Code?
Run npx skills add https://github.com/lukasniessen/kubernetes-skill --skill kubernetes-skill or clone the repository into ~/.claude/skills/kubernetes-skill: Claude Code finds skills in that folder without a restart. There is also a marketplace route: /plugin marketplace add LukasNiessen/kubernetes-skill, then /plugin install kubernetes-skill.
How do I connect KubeShark to Codex?
Clone the repository into the project root with git clone https://github.com/LukasNiessen/kubernetes-skill.git .kubernetes-skill and add a Kubernetes section to AGENTS.md pointing to .kubernetes-skill/SKILL.md and the references folder.
How does the skill differ from a Kubernetes MCP server?
An MCP server lets an agent work with a live cluster. The skill runs nothing in the cluster: it sets the order of reasoning and the references for writing and reviewing manifests, charts and policies.
Which platforms does the skill cover?
Conditional references exist for EKS, GKE, AKS and OpenShift, for the GitOps controllers Argo CD and Flux and for observability stacks: Prometheus Operator, OpenTelemetry, Loki and Grafana. They load when the request shows signs of the platform.
Why does the skill not load all documentation at once?
SKILL.md is short and holds only the procedure. Reference files load by the chosen failure mode so tokens are not spent on unrelated pages.
Discussion
No questions or reviews yet.
Related
Skills31 DevOps skills for Claude Code and Codex: config generators, validators and a Kubernetes debugger for Terraform, Helm, CI and Docker
A large base of DevOps, security, infrastructure and compliance skills for AI agents
The official Grafana skill set: PromQL, Loki, Tempo, Alloy, k6, dashboards and alerting for Claude Code, Cursor and Codex
Docker Skills
docker-skills
Official Docker skills for agents: Dockerfile and builds, Compose, Sandboxes, Docker Agent and a skill that confirms irreversible actions
Official HashiCorp skills for Terraform and Packer: HCL style, modules, tests, imports, Stacks, provider development and image builds
An MCP server and skills on top of Kubernetes network observability: an agent investigates incidents and queries cluster traffic through an eBPF-built index
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| Kubernetes Skill (this entry) | no | 465 | ||
| Kubernetes MCP Server | no | not required | 2,179 | an MCP server that works with resources, pods and logs of a live cluster through its API |
| cc-devops-skills | no | 326 | 31 skills for Terraform, Helm, CI and Docker instead of one Kubernetes procedure |
README in short
The README opens with the promise to remove AI hallucinations in Kubernetes: missing security contexts, deprecated APIs, wildcard permissions, absent limits and probes that cause cascading failures. Four install routes follow, then a comparison with working without the skill, an explanation of the failure-mode approach, a token strategy and the contents of the reference files. MIT license.
README badge
Original SKILL.md
--- name: kubernetes-skill description: "Prevent Kubernetes hallucinations by diagnosing and fixing failure modes: insecure workload defaults, resource starvation, network exposure, privilege sprawl, fragile rollouts, and API drift. Use when generating, reviewing, refactoring, or migrating manifests, Helm charts, Kustomize overlays, cluster policies, and platform-specific Kubernetes work for EKS, GKE, AKS, OpenShift, GitOps controllers, or observability stacks." --- # KubeShark: Failure-Mode Workflow for Kubernetes Run this workflow top to bottom. ## 1) Capture execution context Record before writing manifests: - cluster version (e.g. 1.30, 1.31) and distribution (EKS, GKE, AKS, k3s, vanilla) - target namespace and environment criticality (dev/staging/prod) - workload type (Deployment, StatefulSet, Job, CronJob, DaemonSet) - deployment method (raw YAML, Helm, Kustomize, operator-managed) - policy enforcement (Pod Security Admission level, Kyverno, OPA/Gatekeeper) - cloud provider and CNI (affects networking, storage classes, load balancers) - platform controllers/add-ons (GitOps, observability, ingress, service mesh, autoscaling) If unknown, state assumptions explicitly. ## 2) Diagnose likely failure mode(s) Select one or more based on user intent and risk: - insecure workload defaults: missing security contexts, PSS violations, host access - resource starvation: missing requests/limits, no PDB, scheduling chaos - network exposure: flat networking, missing policies, wrong Service types, DNS issues - privilege sprawl: overly permissive RBAC, leaked secrets, excess ServiceAccount rights - fragile rollouts: misconfigured probes, mutable tags, unsafe update strategies - API drift: wrong apiVersion, deprecated APIs, schema violations, tool-specific errors ## 3) Load only the relevant reference file(s) Primary failure-mode references: - `references/insecure-workload-defaults.md` - `references/resource-starvation.md` - `references/network-exposure.md` - `references/privilege-sprawl.md` - `references/fragile-rollouts.md` - `references/api-drift.md` Supplemental references (only when needed): - `references/deployment-patterns.md` - `references/stateful-patterns.md` - `references/job-patterns.md` - `references/daemonset-operator-patterns.md` - `references/security-hardening.md` - `references/observability.md` - `references/multi-tenancy.md` - `references/storage-and-state.md` - `references/helm-patterns.md` - `references/kustomize-patterns.md` - `references/validation-and-policy.md` - `references/examples-good.md`