Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
This skill provides a comprehensive validation and analysis workflow for Helm charts, combining Helm-native linting, template rendering, YAML validation, schema validation, CRD documentation lookup, and security best practices checking.
IMPORTANT: This validator is read-only by default. It analyzes charts and proposes improvements. Only modify files when the user explicitly asks to apply fixes.
Trigger Cases
Use this skill when one or more of these top cases apply:
The user asks to validate, lint, check, test, or troubleshoot a Helm chart
Helm templates fail to render, lint, or produce valid Kubernetes YAML
A pre-deployment quality gate is needed (schema, dry-run, security checks)
CRD resources are present and their spec fields must be verified against docs
The user wants a severity-based validation report with proposed remediations
Trigger phrase examples:
"Validate this Helm chart before release"
"Why does helm template fail?"
"Check this chart for Kubernetes and security issues"
Out of scope by default:
New chart scaffolding or broad chart generation (use helm-generator)
Role Boundaries
This skill validates and reports; it does not silently rewrite user files.
It can propose concrete patches and apply them only when the user explicitly requests fixes.
If execution constraints block a stage, it must continue with reachable stages and document the skip reason.
Execution Model
Run stages in order (1 through 10).
Keep going after stage-level failures to collect complete findings, unless rendering fails and no manifests exist.
If Stage 4 produces no manifests, mark Stages 5 to 9 as blocked and continue to Stage 10 reporting.
Treat Stage 8 as environment-dependent optional; treat Stage 9 and Stage 10 as mandatory when manifests exist.
For every skipped stage, record the exact tool/environment reason in the final summary table.
Use mcp__context7__resolve-library-id with the CRD project name
Example: "cert-manager" for cert-manager.io CRDs
"prometheus-operator" for monitoring.coreos.com CRDs
"istio" for networking.istio.io CRDs
Then use mcp__context7__query-docs with:
- libraryId from resolve step
- query: The CRD kind and relevant features (e.g., "Certificate spec required fields")
Fallback to web.search_query (web search) if Context7 fails:
Why this matters: CRDs have custom schemas not available in standard Kubernetes validation tools. Understanding the CRD's spec requirements prevents validation errors and ensures correct resource configuration.
Stage 7: Schema Validation
Validate rendered templates against Kubernetes schemas:
File: .helmignore (new file)
Severity: ⚠️ Warning
Reason: Excludes unnecessary files from chart packaging
Proposed: Copy from assets/.helmignore
#### Step 5: Automation Opportunities
List all detected automation opportunities:
- If `_helpers.tpl` is missing → Recommend: `bash scripts/generate_helpers.sh <chart>`
- If `.helmignore` is missing → Recommend: Copy from `assets/.helmignore`
- If `values.schema.json` is missing → Recommend: Copy and customize from `assets/values.schema.json`
- If `NOTES.txt` is missing → Recommend: Create post-install notes template
- If `README.md` is missing → Recommend: Create chart documentation
#### Step 6: Final Summary
Provide a final summary:
Validation Summary
Chart:Status: ⚠️ Warnings Found (or ✅ Ready for Deployment)
Issues Found:
Errors: X
Warnings: Y
Info: Z
Proposed Changes: N changes recommended
Next Steps:
Review proposed changes above
Apply changes manually or use helm-generator skill
Re-run validation to confirm fixes
## Workflow Done Criteria
Validation is complete only when all of the following are true:
- A Stage 1 to Stage 10 status table is present with `✅ Passed`, `⚠️ Warning`, `❌ Failed`, or `⏭️ Skipped` for each stage.
- Every skipped stage includes a concrete tool or environment reason.
- Stage 7 and Stage 8 are evaluated against their explicit success criteria above.
- Severity totals are reported (`Errors`, `Warnings`, `Info`) with proposed remediation actions.
- Role boundary is respected: no file edits unless explicitly requested by the user.
## Helm Templating Automation & Best Practices
This section covers advanced Helm templating techniques, helper functions, and automation strategies.
### Template Helpers (`_helpers.tpl`)
Template helpers are reusable functions defined in `templates/_helpers.tpl`. They promote DRY principles and consistency.
**Standard helper patterns:**
1. **Chart name helper:**
```yaml
{{/*
Expand the name of the chart.
*/}}
{{- define "mychart.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}
# replicaCount is the number of pod replicas for the deploymentreplicaCount:1# image configures the container imageimage:# image.repository is the container image registry and namerepository:nginx# image.tag overrides the image tag (default is chart appVersion)tag:"1.21.0"
Skip optional stages but document what was skipped
Continue with available tools
Template Rendering Errors
Show the specific template file and line number
Check if values are defined in values.yaml
Verify template function syntax
Test with simpler value combinations
Use --debug flag for detailed error messages
Cluster Access Issues
Fall back to client-side validation
Use rendered templates with kubectl
Skip cluster validation if no kubectl config
Document limitations in validation report
CRD Documentation Not Found
Document that documentation lookup failed
Attempt validation with kubeconform CRD schemas
Suggest manual CRD inspection:
kubectl get crd <crd-name>.group -o yaml
kubectl explain <kind>
Validation Stage Failures
Continue to next stage even if one fails
Collect all errors before presenting to user
Prioritize fixing Helm lint errors first
Then fix template errors
Finally fix schema/validation errors
macOS Extended Attributes Issue
Symptom: Helm reports "Chart.yaml file is missing" even though the file exists and is readable.
Cause: On macOS, files created programmatically (via Write tool, scripts, or certain editors) may have extended attributes (e.g., com.apple.provenance, com.apple.quarantine) that interfere with Helm's file detection.
Diagnosis:
# Check for extended attributes
xattr /path/to/chart/Chart.yaml
# If attributes are present, you'll see output like:# com.apple.provenance# com.apple.quarantine
Solutions:
Remove extended attributes:
# Remove all extended attributes from a file
xattr -c /path/to/chart/Chart.yaml
# Remove all extended attributes recursively from chart directory
xattr -cr /path/to/chart/
Create files using shell commands instead:
# Use cat with heredoc instead of direct file writescat > Chart.yaml << 'EOF'
apiVersion: v2
name: mychart
version: 0.1.0
EOF
Copy from helm-created chart:
# Create a fresh chart and copy structure
helm create temp-chart
cp -r temp-chart/* /path/to/your/chart/
rm -rf temp-chart
Prevention: When creating new chart files on macOS, prefer using helm create as a base or use shell heredocs (cat > file << 'EOF') rather than direct file creation tools.
Communication Guidelines
When presenting validation results and fixes:
Be clear and concise about what was found
Explain why issues matter (e.g., "This will cause pod creation to fail")
Provide context from Helm best practices when relevant
Group related issues (e.g., all missing helper issues together)
Use file:line references when available
Show confidence level for auto-fixes (high confidence = syntax, low = logic changes)
Always provide a summary after proposing fixes (and after applying fixes when explicitly requested) including:
What was changed and why
File and line references for each fix
Total count of issues resolved
Final validation status
Any remaining warnings or recommendations
Version Awareness
Always consider Kubernetes and Helm version compatibility:
Check for deprecated Kubernetes APIs
Ensure Helm chart apiVersion is v2 (for Helm 3+)
For CRDs, ensure the apiVersion matches what's in the cluster
Use kubectl api-versions to list available API versions
Reference version-specific documentation when available
Set kubeVersion constraint in Chart.yaml if needed
Chart Testing
For comprehensive testing, use Helm test resources:
Create test resources:
# templates/tests/test-connection.yamlapiVersion:v1kind:Podmetadata:name:"{{ include "mychart.fullname" . }}-test-connection"annotations:"helm.sh/hook":testspec:containers:-name:wgetimage:busyboxcommand: ['wget']
args: ['{{ include "mychart.fullname" . }}:{{ .Values.service.port }}']
restartPolicy:Never
Run tests:
helm test <release-name>
Automation Opportunities Reference
During Stage 10 (Final Report), list all detected automation opportunities in the summary.
Do NOT ask user questions or modify files. Simply list recommendations.
Automation opportunities to detect and list:
Missing Item
Recommendation
_helpers.tpl
Run: bash scripts/generate_helpers.sh <chart>
.helmignore
Copy from: assets/.helmignore
values.schema.json
Copy and customize from: assets/values.schema.json
NOTES.txt
Create post-install notes template
README.md
Create chart documentation
Repeated patterns
Extract to helper functions
Security recommendations to include when issues found:
