A production overlay with secretGenerator literals such as DB_PASSWORD=... puts the database password in git for everyone with the repository, and the Secret it builds is only base64. A remote base written as https://github.com/org/platform//base with no ?ref= deploys whatever the default branch holds on the day you build. And an overlay that never sets a namespace sends production objects into whatever namespace the current kubectl context uses. This skill finds those and the other Kustomize mistakes below, and tells you how to fix each one.

Your agent runs a scanner on every kustomization.yaml, kustomization.yml and Kustomization file (kustomizations and components). It follows local bases such as ../../base to see whether any of them sets a namespace, and opens the env files and files that secretGenerator reads to see whether they hold real values and whether .gitignore keeps them out of git. It knows the current Kustomize v5 fields and deprecations, the remote URL forms, and that a ref can be a branch, a tag or a full commit hash. SOPS-encrypted env files, ${VAR} placeholders and Flux Kustomization objects are not reported. It never runs kustomize, kubectl, helm or git. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach. Secrets are never printed.

What it checks

BLOCK (fix before shipping)

• K01: secrets written in the kustomization: secretGenerator literals, configMapGenerator literals with secret names, secret values and secret env variables in helmCharts valuesInline, Secret data or secret env values in inline patches, a password in a remote URL, or a GitHub, GitLab, Slack, npm or AWS token anywhere in the file (keys that only name a Secret, such as tlsSecret: proxy-tls, are left alone)
• K02: secretGenerator env files and key files (or configMapGenerator env files with secret names) kept in the repository with real values and no .gitignore rule
• K03: remote git bases, resources or components with no ref or version
• K04: remote resources, bases or Helm chart repositories over plain http://

REVIEW (check before release)

• K11: remote refs that move: a branch (main, stable, release-1.28), a short commit hash, a raw file URL on a branch, a releases/latest download, or a file URL with no version
• K12: helmCharts with no version, latest, or a version range
• K13: images with newTag latest, main, nightly or another moving tag and no digest
• K14: deprecated fields (bases, patchesStrategicMerge, patchesJson6902, vars, imageTags, helmChartInflationGenerator), and a generator's env, the older singular form of envs that kustomize edit fix merges into envs
• K15: commonLabels, which also rewrites selectors that cannot change on live workloads
• K16: disableNameSuffixHash: true, so changed config does not roll the pods
• K17: overlays that set no namespace, namePrefix or nameSuffix, on a local base that sets no namespace either (bases of only cluster-scoped kinds such as ClusterIssuer or ClusterRole are left alone)
• K18: files loaded from outside the kustomization folder, which the default load restrictor refuses

What's included

• The scanner (Python 3.9+, standard library only)
• A rules guide with the reason, safer approach and official source for each rule
• A risky and a safe example repository (a base, a production overlay and a platform kustomization), and the real report the scanner produces on the risky one

Limits

It reads the kustomization files as written and does not run the build, so what patches, components, replacements and Helm templates produce, and the Kubernetes manifests themselves, are not checked. Remote bases and charts are not fetched. Whether a file is committed is decided from .gitignore files only. Tags and branches are told apart by their names. A namespace set by an Argo CD Application or a Flux Kustomization is not known. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 27 files: SKILL.md, the scanner in scripts/ (8 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (16 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.