k8s-yaml-validator

Kubernetes YAML Validator

Mindset

Mental Model: Validation is a layered funnel—syntax → schema → cluster constraints → runtime behavior. Each layer catches different classes of errors, and a pass at one layer must never be read as a pass at the next: yamllint clean says nothing about schema compliance, and kubeconform clean says nothing about whether an admission webhook will reject the resource. You must always run every applicable layer, never stop at the first one that returns clean. The classic pitfall this catches: a manifest that is syntactically perfect and schema-valid but still gets rejected by a PodSecurity admission webhook — a gotcha that only the cluster-constraints layer can surface.

Decision Framework:

1. Syntax first: Fix YAML structure before schema issues (broken YAML can't be validated)
2. Schema second: Verify API compliance before cluster-specific checks
3. Cluster third: Test against real constraints (RBAC, quotas, admission webhooks)
4. Runtime last: Consider how the resource behaves in production

When to use this skill:

• Before applying any YAML to a cluster (development, staging, production)
• When debugging mysterious kubectl apply failures
• During CI/CD pipeline execution (catch errors early)
• When working with unfamiliar CRDs (validation guides learning)
• After generating YAML with k8s-yaml-generator

When NOT to use this skill:

• The manifest has already passed server-side dry-run against the exact target cluster and namespace in this same session, and nothing has changed since — re-running the full funnel adds no new information.
• The task is generating a new resource rather than checking an existing one — use k8s-yaml-generator and let its own validation step call into this skill.
• Only a single, well-understood field is in question (e.g. confirming a typo) — a direct kubectl explain lookup is faster and does not require the full workflow.

Validation philosophy: Report all issues, prioritize by severity, suggest fixes but never apply them automatically — this is a hard constraint, not a stylistic preference, and it must never be relaxed even when a fix is obvious.