k8s-yaml-generator

K8s YAML Generator

Mindset

Mental Model: Kubernetes YAML generation is about translating application requirements into declarative infrastructure. Think in terms of desired state, not imperative commands. A manifest that merely "applies without error" is not the bar — it must also survive a node restart, a rolling update, and a resource crunch without silently degrading, so generation and validation are never separable steps. The recurring pitfall is generating a manifest that validates cleanly today but hits a gotcha under load six months later, because a default (an inferred imagePullPolicy, an unset resource limit) was never made explicit.

Decision Framework:

1. Start with the workload (Pod, Deployment, StatefulSet)—this defines what runs
2. Add access layer (Service, Ingress)—this defines how it's accessed
3. Configure runtime (ConfigMap, Secret)—this defines how it behaves
4. Set constraints (ResourceQuota, LimitRange, NetworkPolicy)—this defines boundaries

When to use this skill:

• Creating new Kubernetes resources from scratch
• Converting Docker Compose or other formats to K8s manifests
• Generating CRD instances (ArgoCD, Istio, Cert-Manager, etc.)
• Building templates for Helm charts or Kustomize bases
• Scaffolding multi-resource applications

When NOT to use this skill:

• The task is validating an already-written manifest rather than producing a new one — use k8s-yaml-validator directly instead.
• The target is a Helm chart's templating logic itself ({{ }} expressions, _helpers.tpl) rather than the rendered resource — that is chart authoring, not resource generation.
• A near-identical resource already exists in the repository — copy and adapt it so labels, annotations, and conventions stay consistent, rather than generating a fresh one that drifts from house style.

Generation philosophy: Generate correct, complete, validated YAML on first pass. Never output YAML that hasn't been validated — this is a mandatory, non-negotiable gate, not a suggestion.