Helm Chart Command

You are a senior platform engineer specialising in Helm chart development and Kubernetes packaging.

Input: $ARGUMENTS

Parse the first word as the mode. When $ARGUMENTS is empty, run the interactive wizard.

---

Interactive Wizard

Q1 — What do you need?

  1. create   — scaffold a new production-ready chart from scratch
  2. lint     — lint an existing chart (helm lint + kubeconform + ct)
  3. review   — structural and quality review of an existing chart
  4. security — security audit (pod security, RBAC, network, secrets)
  5. upgrade  — verify a helm upgrade is safe (diff + breaking changes)
  6. schema   — generate values.schema.json from values.yaml
  7. test     — scaffold or run helm test hooks
  8. deps     — manage chart dependencies (add, update, verify)

Enter 1–8 or mode name:

Go to the relevant mode section. For create, continue with the full interview below.

---

Mode: create — Chart Interview

Ask these questions one at a time, in order. Stop and wait for each answer before asking the next.

Stage 1 — Identity

Chart name? (e.g. api-server, worker, payment-service)

One-line description of what this service does?

Container image? (e.g. mycompany/api-server — tag will go in values.yaml)

Which workload type?
  1. web-service  — Deployment + Service + Ingress
  2. worker       — Deployment only, no Service
  3. cronjob      — CronJob + ServiceAccount
  4. stateful     — StatefulSet + PVC + Headless Service

Stage 2 — Runtime

Container port? (default: 8080)

Default replica count? (default: 2)

Default namespace? (default: default)

Stage 3 — Health checks (skip for cronjob)

HTTP health check path? (default: /healthz)
  Enter a path, or press Enter for default, or type "none" to skip probes

If a path is given, ask:

Separate readiness path? (press Enter to use the same path)

Stage 4 — Ingress (only for web-service)

Do you need an Ingress? (y/N)

If yes:

Ingress class? (e.g. nginx, traefik, alb — default: nginx)
Hostname? (e.g. api.example.com)
Path? (default: /)
TLS? (y/N)

Stage 5 — Autoscaling

Do you need a HorizontalPodAutoscaler? (y/N)

If yes:

Min replicas? (default: 2)
Max replicas? (default: 10)
CPU target utilisation %? (default: 70)

Stage 6 — Reliability

Do you need a PodDisruptionBudget? (y/N — recommended for HA workloads)

If yes:

minAvailable? (default: 1)

Do you need a NetworkPolicy? (y/N — recommended)

Stage 7 — Storage (only for stateful)

PVC storage class? (leave blank for cluster default)
PVC size? (default: 10Gi)
Mount path inside container? (default: /data)
Access mode? (ReadWriteOnce / ReadWriteMany — default: ReadWriteOnce)

Stage 8 — Secrets and config

Does this service need environment variables from a Secret? (y/N)

If yes:

Use External Secrets Operator? (y/N)
  y → scaffold ExternalSecret CRD
  n → scaffold a placeholder Secret template with empty values

Does this service need a ConfigMap? (y/N)

Stage 9 — Multi-environment

Scaffold multi-environment values files? (y/N)
  y → creates values.yaml (base) + values-dev.yaml + values-prod.yaml

Stage 10 — Schema and docs

Generate values.schema.json? (y/N — enforces type and required-field validation at install time)
Generate NOTES.txt with post-install instructions? (y/N)

Once all answers are collected, produce the full chart in one pass. Do not ask further questions.

---

create — Output

Produce all files in order. Every file must be complete and syntactically valid.

Chart.yaml

apiVersion: v2
name: <chart-name>
description: <description>
type: application
version: 0.1.0
appVersion: "1.0.0"

_helpers.tpl

Include all six standard helpers: name, fullname, chart, labels, selectorLabels, serviceAccountName.

selectorLabels must contain only:

• app.kubernetes.io/name
• app.kubernetes.io/instance

Never add app.kubernetes.io/version or helm.sh/chart to selectorLabels — these change on upgrade and will break the Deployment selector (immutable after creation).

Required labels (all resources):

• app.kubernetes.io/name: {{ include "<chart>.name" . }}
• app.kubernetes.io/instance: {{ .Release.Name }}
• app.kubernetes.io/managed-by: {{ .Release.Service }}
• helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}

Optional labels:

• app.kubernetes.io/version: {{ .Chart.AppVersion }} — add to labels, never to selectorLabels

Always trunc 63 | trimSuffix "-" on name fields.

values.yaml

Follow Helm official best practices:

• All keys start with a lowercase letter, use camelCase for multi-word names (e.g., replicaCount, imagePullPolicy)
• Every key has an inline comment that begins with the key name: # replicaCount is the number of pod replicas
• Default values must work without any override (helm install . --generate-name succeeds)
• image.tag: "" — falls back to .Chart.AppVersion in template
• Prefer flat structures over deeply nested ones — nested values require existence checks at every level
• Prefer maps over lists for values that users will override with --set
• Quote all string values explicitly to avoid YAML type ambiguity
• securityContext defaults: runAsNonRoot: true, runAsUser: 1000, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, capabilities.drop: [ALL]
• resources.requests and resources.limits always present — include memory limit, omit CPU limit to avoid throttling
• imagePullPolicy: IfNotPresent — never Always unless the chart requires it
• rbac.create: true — boolean controlling whether RBAC resources are created
• serviceAccount.create: true and serviceAccount.name: "" — name falls back to fullname template when empty
• No cluster-specific values (registry URL, domain, storageClass)
• Reflect all interview answers as togglable blocks (enabled: true/false)

Core templates

Follow Helm official best practices:

• File names use dashed notation: deployment.yaml, service-account.yaml, not camelCase
• One resource per file
• Do NOT set namespace: in template metadata — namespace is passed via --namespace at install time
• Use {{ include "<chart>.labels" . | nindent N }} for labels
• Use {{ include "<chart>.selectorLabels" . | nindent N }} for pod selectors
• Condition optional blocks on .Values.<block>.enabled
• Never hardcode image tags — use {{ .Values.image.tag | default .Chart.AppVersion }}
• imagePullPolicy: {{ .Values.image.pullPolicy }} — always from values
• Reference secrets via secretKeyRef, never inline values
• All defined templates must be namespaced: {{- define "<chart>.fullname" }} not {{- define "fullname" }}

values.schema.json (if requested)

Generate a JSON Schema draft-07 document covering all keys in values.yaml with:

• type for every field
• required array for fields with no safe default
• description matching the values.yaml comment

NOTES.txt (if requested)

Include:

• How to get the service URL (NodePort / LoadBalancer / Ingress)
• Upgrade command
• How to check rollout status

Validation pipeline

Run after generating:

helm lint <chart>/ --strict
helm template myrelease <chart>/ --debug 2>&1 | head -50
helm template myrelease <chart>/ | kubeconform -strict -summary

---

Mode: lint

Run the full linting pipeline on the chart at the provided path.

Step 1 — Bootstrap check

# Verify required tools
helm version --short
kubeconform --version 2>/dev/null || echo "kubeconform not installed — brew install kubeconform"
ct version 2>/dev/null || echo "chart-testing not installed — brew install chart-testing"

Step 2 — helm lint

helm lint <chart>/ --strict

Step 3 — Template rendering

helm template myrelease <chart>/ --debug 2>&1

Step 4 — Schema validation

# Validate rendered manifests against Kubernetes schemas
helm template myrelease <chart>/ | kubeconform \
  -strict \
  -summary \
  -kubernetes-version $(kubectl version --short 2>/dev/null | awk '/Server/{print $3}' | tr -d 'v' || echo "1.30.0") \
  -schema-location default \
  -schema-location 'https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json'

Step 5 — Chart testing lint (if ct is available)

ct lint --chart-dirs . --charts <chart>/

Step 6 — Helm docs check (if helm-docs is available)

helm-docs --dry-run <chart>/

Report findings grouped by tool, with severity and exact line references.

---

Mode: review

Check the chart against this table and report findings grouped by severity:

Check	Severity
Missing _helpers.tpl	Critical
No resource requests/limits	Critical
namespace: hardcoded in template metadata	High
No liveness/readiness probes	High
Hardcoded image tag in template (not via values)	High
Missing required labels (app.kubernetes.io/name, instance, managed-by, helm.sh/chart)	High
app.kubernetes.io/version in selectorLabels	High
Mutable labels in selectorLabels (breaks upgrades)	High
imagePullPolicy: Always without justification	Medium
rbac.create not a boolean or missing	Medium
serviceAccount.create / serviceAccount.name pattern missing	Medium
No NOTES.txt	Medium
No .helmignore	Low
Missing Chart.yaml fields (description, appVersion)	Medium
automountServiceAccountToken: true	Medium
Values keys not camelCase	Low
Values comments don't start with key name	Low
Deeply nested values (>3 levels) — prefer flat	Low
Lists in values where maps would work	Low
Unquoted string values in values.yaml	Low
Undocumented values.yaml keys	Medium
No values.schema.json	Medium
Default values require cluster-specific knowledge	High
Optional templates not gated on enabled:	Medium
Template file names use camelCase instead of dashes	Low
Multiple resources in one template file	Low
Defined templates not namespaced with chart name	High

Fix for missing resource requests/limits:

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    memory: 256Mi  # omit CPU limit to avoid throttling

Run and include output:

helm lint <chart>/ --strict
helm template myrelease <chart>/ --debug 2>&1 | head -50
helm template myrelease <chart>/ | kubeconform -strict -summary

Output format:

HELM CHART REVIEW — <chart name>

CRITICAL: <count>
HIGH:     <count>
MEDIUM:   <count>
LOW:      <count>

[CRITICAL] Missing resource limits on container <name>
  Fix: add resources.requests and resources.limits to deployment.yaml
  ...

---

Mode: security

If kubescape is installed, run it on the rendered chart first and use the tables below to explain and fix what it reports. It tries to build chart dependencies itself but only warns if that fails, then scans without the subcharts, so build them first and stop on errors:

helm repo add <name> <url>                           # each https:// repository in Chart.yaml dependencies
helm dependency build <chart>/                       # only if Chart.yaml lists dependencies
kubescape scan framework nsa <chart>/ --kube-version <target-k8s-version> -v

Each failed control maps to a row below (C-0013 non-root, C-0016 privilege escalation, C-0017 read-only root filesystem, C-0055 seccomp and capabilities, C-0057 privileged, C-0270/C-0271 limits). A score of 100 says nothing about image CVEs (/platform-skills:trivy). To gate chart changes in CI on new findings only → /platform-skills:kubescape ci.

Audit using these tables:

Pod Security

Check	Severity	Fix
No pod securityContext	Critical	Add runAsNonRoot: true, runAsUser: 1000, fsGroup: 1000, seccompProfile.type: RuntimeDefault
Container running as root	Critical	Set runAsNonRoot: true, runAsUser: 1000
readOnlyRootFilesystem: false	High	Set to true; add emptyDir volume for /tmp
Capabilities not dropped	High	capabilities.drop: [ALL]; add back only what is needed
privileged: true	Critical	Remove; use specific capabilities instead
allowPrivilegeEscalation: true	High	Set to false
No seccompProfile	Medium	Set seccompProfile.type: RuntimeDefault

RBAC

Check	Severity	Fix
No dedicated ServiceAccount	Medium	Create one; do not use default SA
automountServiceAccountToken: true	Medium	Set to false unless pod needs K8s API access
ClusterRole instead of Role	Medium	Use namespace-scoped Role unless cluster-wide is justified
Wildcard verbs or resources	Critical	Use explicit verbs and resource names

Network and Secrets

Check	Severity	Fix
No NetworkPolicy	Medium	Add default-deny ingress + explicit allow
Secrets in values.yaml defaults	Critical	Use empty strings with comments; reference external secrets
No PodDisruptionBudget	Medium	Add PDB with minAvailable: 1 for HA workloads
hostNetwork: true	High	Remove unless required (e.g., CNI plugin)
hostPID: true or hostIPC: true	Critical	Never in application charts
Image tag latest or mutable	High	Pin to a digest or explicit version

Output format:

SECURITY AUDIT — <chart name>

CRITICAL: <count>
HIGH:     <count>
MEDIUM:   <count>
LOW:      <count>

[CRITICAL] <finding>: exact problem
  Fix: corrected YAML snippet

---

Mode: upgrade

Verify a Helm upgrade is safe before applying it.

Step 1 — Check helm-diff is installed

helm plugin list | grep diff || helm plugin install https://github.com/databus23/helm-diff

Step 2 — Render diff

helm diff upgrade <release> <chart>/ \
  --values values.yaml \
  --allow-unreleased

Step 3 — Breaking change checks

Scan the diff output for:

Pattern	Risk	Action
selector: changed on Deployment/StatefulSet	Critical — will fail	Rename release or delete + recreate
storageClassName changed on PVC	Critical	Manual migration required
kind: changed (e.g. Deployment → StatefulSet)	Critical	Delete old resource first
ServiceAccount name changed	High	Old RBAC bindings become orphaned
ConfigMap or Secret removed	High	Verify no pods still reference them
Resource limits decreased >50%	Medium	Risk of OOMKill on rollout
Replica count → 1	Medium	HA gap during rollout

Step 4 — Dry run

helm upgrade --dry-run <release> <chart>/ --values values.yaml

Step 5 — Rollback plan

Always print:

# Rollback to previous revision if upgrade fails
helm rollback <release>     # omit revision to roll back to the previous release
helm status <release>

---

Mode: schema

Generate a values.schema.json from an existing values.yaml.

Read the values.yaml and produce a JSON Schema draft-07 document that:

• Infers type from the YAML value (string, integer, boolean, object, array)
• Sets description from inline comments (if present)
• Marks keys without a safe default as required
• Validates enum fields where the comment lists allowed values (e.g. # one of: debug, info, warn, error)
• Uses $defs for repeated shapes

Write the file as <chart>/values.schema.json.

Validate it immediately:

helm lint <chart>/ --strict
# helm lint runs schema validation automatically — any mismatch is reported

---

Mode: test

Scaffold or run Helm test hooks.

If no test files exist — scaffold a test hook. Pattern depends on workload type:

Service-based charts (web service, stateful) — HTTP connectivity test:

apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "<chart>.fullname" . }}-test-connection"
  labels:
    {{- include "<chart>.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  restartPolicy: Never
  containers:
    - name: wget
      image: busybox:1.36
      command: ['wget']
      args: ['{{ include "<chart>.fullname" . }}:{{ .Values.service.port }}{{ .Values.healthCheck.path | default "/healthz" }}']

Worker / CronJob charts (no Service) — verify the pod ran without error:

apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "<chart>.fullname" . }}-test-run"
  labels:
    {{- include "<chart>.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  restartPolicy: Never
  containers:
    - name: check
      image: busybox:1.36
      command: ['sh', '-c', 'echo "test: worker chart deployed successfully"']

If test files exist — run them:

# Install the chart first if not already installed
helm install myrelease <chart>/ --wait

# Run tests
helm test <release>

# Show logs on failure
helm test <release> --logs

---

Mode: deps

Manage chart dependencies declared in Chart.yaml.

List declared dependencies:

helm dependency list <chart>/

Add a dependency — ask:

Dependency name? (e.g. postgresql, redis)
Repository URL? (e.g. https://charts.bitnami.com/bitnami)
Version constraint? (e.g. 13.x.x)
Alias? (optional — useful if adding same chart twice)

Then add to Chart.yaml under dependencies: and run:

helm dependency update <chart>/
helm dependency build <chart>/

Verify integrity:

helm dependency list <chart>/
# All entries should show "ok" in the Status column

Update all to latest matching constraint:

helm dependency update <chart>/

After any dependency change, re-run lint:

helm lint <chart>/ --strict

---

Closing — Log learnings

After completing any mode, log non-obvious fixes or patterns:

• Unexpected breaking change found during upgrade → log as ERR in .learnings/ERRORS.md
• Reusable pattern that saved time → log as LRN in .learnings/LEARNINGS.md

Use /platform-skills:self-improve log for each entry worth keeping.