How do I install the Maintain Kyverno Policies skill?

Run npx skillmds@latest add devantler-tech/maintain-kyverno-policies in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Maintain Kyverno Policies safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Maintain Kyverno Policies?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Maintain Kyverno Policies free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Maintain Kyverno Policies?

devantler-tech (@devantler-tech) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Maintain Kyverno Policies by devantler-tech

Name: Maintain Kyverno Policies
Author: devantler-tech

Maintain Kyverno Policies

Maintenance + advance task menu for devantler-tech/kyverno-policies — the shared, tested Kyverno policy catalog the platform and platform-template consume instead of vendoring per-repo copies. Use when the daily maintainer selects kyverno-policies.

File contents

Maintain: Kyverno policy library (shared library)

The reusable Kyverno policy catalog for the devantler-tech platforms. Generic admission and generation policy behaviour lives here once, so consumer copies in platform and platform-template cannot drift apart. Consumer wiring and rollout stay separate changes in those repositories.

The canonical task menu lives in the repo itself — read the ## Maintenance section of libraries/kyverno-policies/AGENTS.md (on the submodule's latest main): https://github.com/devantler-tech/kyverno-policies/blob/main/AGENTS.md. This card is a pointer by design — the menu is maintained once, in the product's own AGENTS.md.

A policy is inert until a consumer pins and references it. Adding one to the catalog changes nothing on any cluster; adoption is its own draft PR, validated in every affected overlay. Keep policies generic — environment-specific exclusions, patches, and rollout choices belong to the consumer repo, never here.

Behaviour is test-first, and the gate has teeth. Every policy carries a kyverno test contract under tests/<policy>/; for a generate rule, assert the complete generated resource and at least one nonmatching resource. kyverno test . discovers fixtures recursively, so a new policy is covered as soon as its fixture exists — never hand-list fixture paths in a runner. Note that kyverno apply exits 1 on rule failures, but is fail-open on load: a policy it cannot parse is silently dropped ("Applying 0 policy rule(s)", exit 0), so an apply-based negative control passes vacuously unless a positive control proves the policy loaded (kyverno-policies#19). Trust the repo's own validation block rather than a naive invocation.

Validation (run every gate before opening or updating a PR — the repo's AGENTS.md is authoritative if this drifts). First confirm your local CLI matches the repo's pinned KYVERNO_CLI_VERSION (in .github/workflows/ci.yaml) — the CLI defines how the behaviour fixtures evaluate, so a version mismatch makes a local pass mean something different from CI:

kyverno version   # must match KYVERNO_CLI_VERSION in .github/workflows/ci.yaml
yamllint .
kubectl kustomize . > /dev/null
kyverno test . --require-tests --detailed-results --remove-color
bash scripts/test-policy-catalog.sh
shellcheck scripts/test-policy-catalog.sh
actionlint .github/workflows/ci.yaml
zizmor .github/workflows/ci.yaml
git diff --check

Tests are static and local — never connect to or mutate a live cluster to validate a policy-library diff.

Shared cross-repo rules are in the monorepo AGENTS.md.

Roadmap & enhancement

Roadmap lives in GitHub Issues on devantler-tech/kyverno-policies (roadmap-labelled epics + milestones). To advance (catalog coverage, the GeneratingPolicy API migration, test depth, CI hardening, docs) follow product-engineering.

---name: maintain-kyverno-policiesdescription: Maintenance + advance task menu for devantler-tech/kyverno-policies — the shared, tested Kyverno policy catalog the platform and platform-template consume instead of vendoring per-repo copies. Use when the daily maintainer selects kyverno-policies.---# Maintain: Kyverno policy library (shared library)The reusable **Kyverno policy catalog** for the devantler-tech platforms. Generic admission andgeneration policy behaviour lives here **once**, so consumer copies in[`platform`](../platform/SKILL.md) and `platform-template` cannot drift apart. Consumer wiring androllout stay separate changes in those repositories.The canonical task menu lives **in the repo itself** — read the **`## Maintenance`** section of`libraries/kyverno-policies/AGENTS.md` (on the submodule's latest `main`):<https://github.com/devantler-tech/kyverno-policies/blob/main/AGENTS.md>. This card is a pointer bydesign — the menu is maintained once, in the product's own `AGENTS.md`.**A policy is inert until a consumer pins and references it.** Adding one to the catalog changesnothing on any cluster; adoption is its own draft PR, validated in every affected overlay. Keeppolicies generic — environment-specific exclusions, patches, and rollout choices belong to theconsumer repo, never here.**Behaviour is test-first, and the gate has teeth.** Every policy carries a `kyverno test` contractunder `tests/<policy>/`; for a generate rule, assert the complete generated resource **and** at leastone nonmatching resource. `kyverno test .` discovers fixtures recursively, so a new policy is coveredas soon as its fixture exists — never hand-list fixture paths in a runner. Note that `kyverno apply`exits 1 on rule *failures*, but is **fail-open on load**: a policy it cannot parse is silentlydropped ("Applying 0 policy rule(s)", exit 0), so an apply-based negative control passes vacuouslyunless a positive control proves the policy loaded([kyverno-policies#19](https://github.com/devantler-tech/kyverno-policies/issues/19)). Trust therepo's own validation block rather than a naive invocation.**Validation** (run every gate before opening or updating a PR — the repo's `AGENTS.md` isauthoritative if this drifts). **First confirm your local CLI matches the repo's pinned`KYVERNO_CLI_VERSION`** (in `.github/workflows/ci.yaml`) — the CLI defines how the behaviourfixtures evaluate, so a version mismatch makes a local pass mean something different from CI:```shkyverno version # must match KYVERNO_CLI_VERSION in .github/workflows/ci.yamlyamllint .kubectl kustomize . > /dev/nullkyverno test . --require-tests --detailed-results --remove-colorbash scripts/test-policy-catalog.shshellcheck scripts/test-policy-catalog.shactionlint .github/workflows/ci.yamlzizmor .github/workflows/ci.yamlgit diff --check```Tests are **static and local** — never connect to or mutate a live cluster to validate apolicy-library diff.Shared cross-repo rules are in the monorepo [`AGENTS.md`](../../../../AGENTS.md).## Roadmap & enhancementRoadmap lives in **GitHub Issues** on `devantler-tech/kyverno-policies` (`roadmap`-labelled epics +milestones). To **advance** (catalog coverage, the GeneratingPolicy API migration, test depth, CIhardening, docs) follow [`product-engineering`](../../product-engineering/SKILL.md).

Frequently asked questions