k8s-yaml-validator_skill

Overview

This skill provides a comprehensive, report-only toolkit for validating, linting, and testing Kubernetes YAML manifests before they are applied to a cluster. It combines YAML syntax checks, schema validation (including CRD-aware workflows), and optional server- or client-side dry-run testing. The skill always produces a detailed validation report with suggested before/after code snippets and next steps — it never modifies files.

How this skill works

The workflow runs sequential stages: a resource-count pre-check, tool availability check, yamllint syntax/style analysis, CRD detection with documentation lookup, schema validation with kubeconform, and an optional kubectl dry-run against a cluster. Detected CRDs trigger documentation resolution (preferred context7 lookup, fallback to web search) to validate custom specs when schemas are missing. The final output is a consolidated, categorized report that lists errors, warnings, and suggested fixes as examples only.

When to use it

• Before applying Kubernetes manifests to any cluster
• When debugging YAML syntax, duplicate keys, or formatting issues
• When working with CRDs and you need spec documentation or version-specific rules
• To perform server-side or client-side dry-run tests to catch admission controller or schema issues
• When you need a consolidated, actionable validation report (report-only)

Best practices

• Run the resource-count pre-check and consult extended workflow for multi-document files (3+ resources)
• Always prefer server-side kubectl dry-run first; fall back to client-side only if cluster access fails
• Use strict schema validation (-strict) to catch unknown fields and typos, but allow ignore-missing-schemas for unknown CRDs
• When CRD schemas are unavailable, resolve CRD docs before accepting spec fields — use context7 then web search
• Report all findings with file:line references and show before/after YAML snippets as suggestions only

Example use cases

• Validate a single Deployment and Service YAML before a CI/CD promotion
• Diagnose a failing kubectl apply due to admission webhook or resource quota via server-side dry-run
• Check a multi-document manifest (Deployment, Service, CRD) and fetch CRD docs to validate custom spec fields
• Run yamllint and kubeconform locally to catch syntax and schema issues during local development
• Produce a report for reviewers showing exact suggested YAML fixes without applying changes