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
• references/examples-bad.md
• references/do-dont-patterns.md

Conditional Reference Retrieval (CRR) references (load only when the signal is detected):

• references/conditional/eks-patterns.md for EKS, AWS, IRSA, EKS Pod Identity, AWS Load Balancer Controller, EBS/EFS CSI, Karpenter
• references/conditional/gke-patterns.md for GKE, Autopilot, Workload Identity Federation for GKE, Dataplane V2, GCE Ingress, Config Sync
• references/conditional/aks-patterns.md for AKS, Microsoft Entra Workload ID, Azure CNI, AGIC, Azure Disk/File/Blob CSI
• references/conditional/openshift-patterns.md for OpenShift, OKD, ROSA, ARO, Routes, SCCs, OLM, oc
• references/conditional/gitops-controllers.md for Argo CD, ApplicationSet, Flux, GitOps reconciliation, sync waves
• references/conditional/observability-stacks.md for Prometheus Operator, ServiceMonitor, PodMonitor, OpenTelemetry, Loki, Grafana

Do not load multiple CRR files unless the task spans multiple detected platforms/tools.

4) Propose fix path with explicit risk controls

For each fix, include:

• why this addresses the failure mode
• what could still go wrong at deploy time or runtime
• guardrails (validation commands, policy checks, rollback path)

5) Generate implementation artifacts

When applicable, output:

• Kubernetes manifests (YAML with security contexts, resource limits, labels)
• Helm values/templates or Kustomize overlays
• NetworkPolicies, RBAC resources, PodDisruptionBudgets
• Policy rules (Kyverno/OPA) and admission controls

6) Validate before finalize

Always provide validation steps tailored to deployment method and risk tier:

• kubectl apply --dry-run=server or kubectl diff
• kubeconform for schema validation against target cluster version
• cross-resource consistency check (label/selector/port alignment)
• policy scan (PSS profile check, Kyverno/OPA audit) Never recommend direct production apply without reviewed diff and approval.

7) Output contract

Return:

• assumptions and cluster version floor
• selected failure mode(s)
• chosen remediation and tradeoffs
• validation/test plan
• rollback/recovery notes (rollout undo, revision history, data safety)

Kubernetes Skill for Claude Code and Codex: KubeShark

The #1 Kubernetes skill for Claude Code and Codex, measured by GitHub stars.

Fixes Hallucinations.

LLMs hallucinate a lot when it comes to Kubernetes. They omit security contexts, generate deprecated APIs, use wildcard RBAC, forget resource limits, and produce probes that cause cascading failures. This skill fixes it. It includes best practices for Kubernetes -- good, bad, and neutral examples so the AI avoids common mistakes. Using KubeShark, the AI keeps proven practices in mind, eliminates hallucinations, and defaults to secure, reliable, production-ready manifests.

KubeShark is built as the production-grade Kubernetes skill for Claude Code and Codex: broader than resource-template skills, safer than generic Kubernetes prompts, and tuned for hallucination prevention instead of raw tutorial volume.

Very Token-Efficient.

Most Kubernetes skills dump huge walls of text onto the agent and burn expensive tokens -- with no upside. LLMs don't need the entire Kubernetes docs again. KubeShark was aggressively de-duplicated and optimized for maximum quality per token.

Based on Official Best Practices.

KubeShark is primarily based on the official Kubernetes documentation, the NSA/CISA Kubernetes Hardening Guide, OWASP Kubernetes Top 10, Pod Security Standards, and the CIS Kubernetes Benchmark. When guidance conflicts, it prioritizes official Kubernetes documentation.

Quick Start · Why KubeShark · Token Strategy · What's Included · How It Works · Philosophy

2 min Quickstart

Option 1: Clone

macOS / Linux:

git clone https://github.com/LukasNiessen/kubernetes-skill.git ~/.claude/skills/kubernetes-skill

Windows (Powershell):

git clone https://github.com/LukasNiessen/kubernetes-skill.git "$env:USERPROFILE\.claude\skills\kubernetes-skill"

Windows (Command Prompt):

git clone https://github.com/LukasNiessen/kubernetes-skill.git "%USERPROFILE%\.claude\skills\kubernetes-skill"

That's it. Claude Code auto-discovers skills in ~/.claude/skills/ -- no restart needed.

Option 2: Marketplace

Claude Code has a built-in plugin system with marketplace support. Instead of cloning manually, you can add KubeShark's marketplace and install directly from the CLI:

/plugin marketplace add LukasNiessen/kubernetes-skill
/plugin install kubernetes-skill

Or use the interactive plugin manager -- run /plugin, switch to the Discover tab, and install from there. The marketplace reads the .claude-plugin/marketplace.json in this repo to register KubeShark as an installable plugin.

Option 3: Codex

Codex has no global skill system -- setup is per-project. Clone KubeShark into your repo and reference it from your AGENTS.md:

# Clone into your project root
git clone https://github.com/LukasNiessen/kubernetes-skill.git .kubernetes-skill

Then add to your AGENTS.md (or create one in the repo root):

## Kubernetes

When working with Kubernetes manifests, Helm charts, or Kustomize overlays, follow the workflow in `.kubernetes-skill/SKILL.md`.
Load references from `.kubernetes-skill/references/` as needed.

That's it!

Done. Now ask Claude Code / Codex any Kubernetes question. KubeShark responses follow the 7-step failure-mode workflow and include an output contract with assumptions, tradeoffs, and rollback notes.

Invoke explicitly:

/kubernetes-skill Create a production-ready Deployment with an Ingress and autoscaling

/kubernetes-skill Review my Deployment for security issues and add proper RBAC, NetworkPolicies, and resource limits

Or just ask naturally -- KubeShark activates automatically for any Kubernetes task:

Review my deployment.yaml for security issues

Create a Helm chart for a PostgreSQL StatefulSet with backup CronJobs

Why KubeShark

Overview

Why Failure-Mode-First Matters for Kubernetes

The key insight is architectural. A static reference manual gives Claude information but never tells it how to think about a problem. There's no diagnosis step, no risk assessment, and no structured output -- Claude reads the reference and generates whatever it thinks fits.

KubeShark takes the opposite approach. The core SKILL.md is a compact operational workflow. It forces Claude through a diagnostic sequence: capture context -> identify failure modes -> load only the relevant references -> propose fixes with explicit risk controls -> validate -> deliver a structured output contract.

This matters for Kubernetes specifically because:

1. Silent failures are common. A Service with the wrong selector deploys successfully but routes to nothing. A NetworkPolicy with a mistyped label silently does nothing. Unlike Terraform, Kubernetes accepts most manifests without error -- failures surface at runtime.

2. Multi-dimensional risk. Kubernetes operates across security, networking, scheduling, storage, and application lifecycle simultaneously. An LLM must reason about all these dimensions for every resource.

3. Training data pollution. Kubernetes has had aggressive API deprecation. The LLM training corpus contains vast amounts of pre-1.22 YAML using removed APIs. Without diagnosis, the LLM confidently generates deprecated configurations.

Skill Comparison

Here's how KubeShark compares to other public Kubernetes-focused agent skills found during the May 2026 review. This compares Kubernetes skill behavior, not full runtime observability products or broad skill collections.