/helmchart

name: helmchart
description: Scaffold, lint, review, security-audit, test, and upgrade-verify Helm charts. Runs an interactive interview to build production-ready charts from scratch. Covers chart structure, values design, schema validation, kubeconform, helm diff, and multi-environment scaffolding. Use when asked to "create a helm chart", "lint my chart", "review my helm chart", "check helm security", "generate values schema", "run helm diff", or "add helm tests".
argument-hint: "[create|lint|review|security|upgrade|schema|test|deps] [chart path]"
title: "Helm Chart Command"
sidebar_label: "helmchart"
custom_edit_url: null

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 Y