Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
alirezarezvani avatar

Helm Chart Builder

  • 565 installs
  • 23.5k repo stars
  • Updated July 17, 2026
  • alirezarezvani/claude-skills

helm-chart-builder is a Claude Code skill that generates production-ready Helm charts with Kubernetes templates, helpers, and values schemas for developers who deploy services to clusters.

About

helm-chart-builder is a Helm chart patterns reference skill from alirezarezvani/claude-skills that scaffolds complete Kubernetes packaging for production releases. It documents a minimal production chart with Chart.yaml, values.yaml, .helmignore, and seven core templates—deployment, service, serviceaccount, helpers, NOTES.txt, and a connection test—plus an expanded layout adding ingress, HPA, PDB, NetworkPolicy, ConfigMap, Secret, and values.schema.json validation. Developers reach for helm-chart-builder when containerizing a new microservice, standardizing cluster deployments, or replacing hand-rolled YAML with Helm best practices. The skill emphasizes _helpers.tpl conventions, test hooks, and schema-validated values so agents output charts ready for helm install rather than demo manifests.

  • Generates minimal and full production Helm chart structures including all standard Kubernetes resources
  • Includes standard _helpers.tpl with name, fullname, chart, and selector label definitions
  • Creates values.yaml with comprehensive configuration options and JSON schema validation support
  • Produces deployment, service, ingress, HPA, PDB, NetworkPolicy, ConfigMap and Secret templates
  • Outputs NOTES.txt and test-connection.yaml for improved operator experience

Helm Chart Builder by the numbers

  • 565 all-time installs (skills.sh)
  • Ranked #254 of 1,440 DevOps & CI/CD skills by installs in the Skillselion catalog
  • Security screen: HIGH risk (skills.sh audit)
  • Data as of Jul 31, 2026 (Skillselion catalog sync)
npx skills add https://github.com/alirezarezvani/claude-skills --skill helm-chart-builder

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs565
repo stars23.5k
Security audit2 / 3 scanners passed
Last updatedJuly 17, 2026
Repositoryalirezarezvani/claude-skills

How do you scaffold a production Helm chart?

Generate complete, production-ready Helm charts for Kubernetes deployments with best-practice templates and helpers.

Who is it for?

Backend and platform engineers who need standardized, production-grade Helm charts for Kubernetes microservice deployments.

Skip if: Developers deploying only to serverless platforms or local Docker Compose without any Kubernetes cluster target.

When should I use this skill?

User asks to create a Helm chart, Kubernetes deployment templates, values.yaml structure, or helm install packaging for a service.

What you get

Chart.yaml, values.yaml, _helpers.tpl, Kubernetes manifest templates, NOTES.txt, and optional values.schema.json

  • Helm chart directory
  • values.yaml defaults
  • Kubernetes manifest templates

By the numbers

  • Minimal production chart includes 7 core template and metadata files
  • Full production chart adds 8+ additional templates including ingress, HPA, PDB, and NetworkPolicy

Files

SKILL.mdMarkdownGitHub ↗

Helm Chart Builder

Production-grade Helm charts. Sensible defaults. Secure by design. No cargo-culting.

Opinionated Helm workflow that turns ad-hoc Kubernetes manifests into maintainable, testable, reusable charts. Covers chart structure, values design, template patterns, dependency management, and security hardening.

Not a Helm tutorial — a set of concrete decisions about how to build charts that operators trust and developers don't fight.

---

Slash Commands

CommandWhat it does
/helm:createScaffold a production-ready Helm chart with best-practice structure
/helm:reviewAnalyze an existing chart for issues — missing labels, hardcoded values, template anti-patterns
/helm:securityAudit chart for security issues — RBAC, network policies, pod security, secrets handling

---

When This Skill Activates

Recognize these patterns from the user:

  • "Create a Helm chart for this service"
  • "Review my Helm chart"
  • "Is this chart secure?"
  • "Design a values.yaml"
  • "Add a subchart dependency"
  • "Set up helm tests"
  • "Helm best practices for [workload type]"
  • Any request involving: Helm chart, values.yaml, Chart.yaml, templates, helpers, _helpers.tpl, subcharts, helm lint, helm test

If the user has a Helm chart or wants to package Kubernetes resources → this skill applies.

---

Workflow

/helm:create — Chart Scaffolding

1. Identify workload type

  • Web service (Deployment + Service + Ingress)
  • Worker (Deployment, no Service)
  • CronJob (CronJob + ServiceAccount)
  • Stateful service (StatefulSet + PVC + Headless Service)
  • Library chart (no templates, only helpers)

2. Scaffold chart structure

   mychart/
   ├── Chart.yaml              # Chart metadata and dependencies
   ├── values.yaml             # Default configuration
   ├── values.schema.json      # Optional: JSON Schema for values validation
   ├── .helmignore             # Files to exclude from packaging
   ├── templates/
   │   ├── _helpers.tpl        # Named templates and helper functions
   │   ├── deployment.yaml     # Workload resource
   │   ├── service.yaml        # Service exposure
   │   ├── ingress.yaml        # Ingress (if applicable)
   │   ├── serviceaccount.yaml # ServiceAccount
   │   ├── hpa.yaml            # HorizontalPodAutoscaler
   │   ├── pdb.yaml            # PodDisruptionBudget
   │   ├── networkpolicy.yaml  # NetworkPolicy
   │   ├── configmap.yaml      # ConfigMap (if needed)
   │   ├── secret.yaml         # Secret (if needed)
   │   ├── NOTES.txt           # Post-install usage instructions
   │   └── tests/
   │       └── test-connection.yaml
   └── charts/                 # Subcharts (dependencies)

3. Apply Chart.yaml best practices

   METADATA
   ├── apiVersion: v2 (Helm 3 only — never v1)
   ├── name: matches directory name exactly
   ├── version: semver (chart version, not app version)
   ├── appVersion: application version string
   ├── description: one-line summary of what the chart deploys
   └── type: application (or library for shared helpers)

   DEPENDENCIES
   ├── Pin dependency versions with ~X.Y.Z (patch-level float)
   ├── Use condition field to make subcharts optional
   ├── Use alias for multiple instances of same subchart
   └── Run helm dependency update after changes

4. Generate values.yaml with documentation

  • Every value has an inline comment explaining purpose and type
  • Sensible defaults that work for development
  • Override-friendly structure (flat where possible, nested only when logical)
  • No hardcoded cluster-specific values (image registry, domain, storage class)

5. Validate

   python3 scripts/chart_analyzer.py mychart/
   helm lint mychart/
   helm template mychart/ --debug

/helm:review — Chart Analysis

1. Check chart structure

CheckSeverityFix
Missing _helpers.tplHighCreate helpers for common labels and selectors
No NOTES.txtMediumAdd post-install instructions
No .helmignoreLowCreate one to exclude .git, CI files, tests
Missing Chart.yaml fieldsMediumAdd description, appVersion, maintainers
Hardcoded values in templatesHighExtract to values.yaml with defaults

2. Check template quality

CheckSeverityFix
Missing standard labelsHighUse app.kubernetes.io/* labels via _helpers.tpl
No resource requests/limitsCriticalAdd resources section with defaults in values.yaml
Hardcoded image tagHighUse {{ .Values.image.repository }}:{{ .Values.image.tag }}
No imagePullPolicyMediumDefault to IfNotPresent, overridable
Missing liveness/readiness probesHighAdd probes with configurable paths and ports
No pod anti-affinityMediumAdd preferred anti-affinity for HA
Duplicate template codeMediumExtract into named templates in _helpers.tpl

3. Check values.yaml quality

   python3 scripts/values_validator.py mychart/values.yaml

4. Generate review report

   HELM CHART REVIEW — [chart name]
   Date: [timestamp]

   CRITICAL: [count]
   HIGH:     [count]
   MEDIUM:   [count]
   LOW:      [count]

   [Detailed findings with fix recommendations]

/helm:security — Security Audit

1. Pod security audit

CheckSeverityFix
No securityContextCriticalAdd runAsNonRoot, readOnlyRootFilesystem
Running as rootCriticalSet runAsNonRoot: true, runAsUser: 1000
Writable root filesystemHighSet readOnlyRootFilesystem: true + emptyDir for tmp
All capabilities retainedHighDrop ALL, add only specific needed caps
Privileged containerCriticalSet privileged: false, use specific capabilities
No seccomp profileMediumSet seccompProfile.type: RuntimeDefault
allowPrivilegeEscalation trueHighSet allowPrivilegeEscalation: false

2. RBAC audit

CheckSeverityFix
No ServiceAccountMediumCreate dedicated SA, don't use default
automountServiceAccountToken trueMediumSet to false unless pod needs K8s API access
ClusterRole instead of RoleMediumUse namespace-scoped Role unless cluster-wide needed
Wildcard permissionsCriticalUse specific resource names and verbs
No RBAC at allLowAcceptable if pod doesn't need K8s API access

3. Network and secrets audit

CheckSeverityFix
No NetworkPolicyMediumAdd default-deny ingress + explicit allow rules
Secrets in values.yamlCriticalUse external secrets operator or sealed-secrets
No PodDisruptionBudgetMediumAdd PDB with minAvailable for HA workloads
hostNetwork: trueHighRemove unless absolutely required (e.g., CNI plugin)
hostPID or hostIPCCriticalNever use in application charts

4. Generate security report

   SECURITY AUDIT — [chart name]
   Date: [timestamp]

   CRITICAL: [count]
   HIGH:     [count]
   MEDIUM:   [count]
   LOW:      [count]

   [Detailed findings with remediation steps]

---

Tooling

scripts/chart_analyzer.py

CLI utility for static analysis of Helm chart directories.

Features:

  • Chart structure validation (required files, directory layout)
  • Template anti-pattern detection (hardcoded values, missing labels, no resource limits)
  • Chart.yaml metadata checks
  • Standard labels verification (app.kubernetes.io/*)
  • Security baseline checks
  • JSON and text output

Usage:

# Analyze a chart directory
python3 scripts/chart_analyzer.py mychart/

# JSON output
python3 scripts/chart_analyzer.py mychart/ --output json

# Security-focused analysis
python3 scripts/chart_analyzer.py mychart/ --security

scripts/values_validator.py

CLI utility for validating values.yaml against best practices.

Features:

  • Documentation coverage (inline comments)
  • Type consistency checks
  • Hardcoded secrets detection
  • Default value quality analysis
  • Structure depth analysis
  • Naming convention validation
  • JSON and text output

Usage:

# Validate values.yaml
python3 scripts/values_validator.py values.yaml

# JSON output
python3 scripts/values_validator.py values.yaml --output json

# Strict mode (fail on warnings)
python3 scripts/values_validator.py values.yaml --strict

---

Template Patterns

Pattern 1: Standard Labels (_helpers.tpl)

{{/*
Common labels for all resources.
*/}}
{{- define "mychart.labels" -}}
helm.sh/chart: {{ include "mychart.chart" . }}
app.kubernetes.io/name: {{ include "mychart.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

{{/*
Selector labels (subset of common labels — must be immutable).
*/}}
{{- define "mychart.selectorLabels" -}}
app.kubernetes.io/name: {{ include "mychart.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}

Pattern 2: Conditional Resources

{{- if .Values.ingress.enabled -}}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ include "mychart.fullname" . }}
  labels:
    {{- include "mychart.labels" . | nindent 4 }}
  {{- with .Values.ingress.annotations }}
  annotations:
    {{- toYaml . | nindent 4 }}
  {{- end }}
spec:
  {{- if .Values.ingress.tls }}
  tls:
    {{- range .Values.ingress.tls }}
    - hosts:
        {{- range .hosts }}
        - {{ . | quote }}
        {{- end }}
      secretName: {{ .secretName }}
    {{- end }}
  {{- end }}
  rules:
    {{- range .Values.ingress.hosts }}
    - host: {{ .host | quote }}
      http:
        paths:
          {{- range .paths }}
          - path: {{ .path }}
            pathType: {{ .pathType }}
            backend:
              service:
                name: {{ include "mychart.fullname" $ }}
                port:
                  number: {{ $.Values.service.port }}
          {{- end }}
    {{- end }}
{{- end }}

Pattern 3: Security-Hardened Pod Spec

spec:
  serviceAccountName: {{ include "mychart.serviceAccountName" . }}
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: {{ .Chart.Name }}
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
      image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
      imagePullPolicy: {{ .Values.image.pullPolicy }}
      resources:
        {{- toYaml .Values.resources | nindent 8 }}
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

---

Values Design Principles

STRUCTURE
├── Flat over nested (image.tag > container.spec.image.tag)
├── Group by resource (service.*, ingress.*, resources.*)
├── Use enabled: true/false for optional resources
├── Document every key with inline YAML comments
└── Provide sensible development defaults

NAMING
├── camelCase for keys (replicaCount, not replica_count)
├── Boolean keys: use adjectives (enabled, required) not verbs
├── Nested keys: max 3 levels deep
└── Match upstream conventions (image.repository, image.tag, image.pullPolicy)

ANTI-PATTERNS
├── Hardcoded cluster URLs or domains
├── Secrets as default values
├── Empty strings where null is correct
├── Deeply nested structures (>3 levels)
├── Undocumented values
└── values.yaml that doesn't work without overrides

---

Dependency Management

SUBCHARTS
├── Use Chart.yaml dependencies (not requirements.yaml — Helm 3)
├── Pin versions: version: ~15.x.x (patch float)
├── Use condition: to make optional: condition: postgresql.enabled
├── Use alias: for multiple instances of same chart
├── Override subchart values under subchart name key in values.yaml
└── Run helm dependency update before packaging

LIBRARY CHARTS
├── type: library in Chart.yaml — no templates directory
├── Export named templates only — no rendered resources
├── Use for shared labels, annotations, security contexts
└── Version independently from application charts

---

Proactive Triggers

Flag these without being asked:

  • No _helpers.tpl → Create one. Every chart needs standard labels and fullname helpers.
  • Hardcoded image tag in template → Extract to values.yaml. Tags must be overridable.
  • No resource requests/limits → Add them. Pods without limits can starve the node.
  • Running as root → Add securityContext. No exceptions for production charts.
  • No NOTES.txt → Create one. Users need post-install instructions.
  • Secrets in values.yaml defaults → Remove them. Use placeholders with comments explaining how to provide secrets.
  • No liveness/readiness probes → Add them. Kubernetes needs to know if the pod is healthy.
  • Missing app.kubernetes.io labels → Add via _helpers.tpl. Required for proper resource tracking.

---

Installation

One-liner (any tool)

git clone https://github.com/alirezarezvani/claude-skills.git
cp -r claude-skills/engineering/helm-chart-builder ~/.claude/skills/

Multi-tool install

./scripts/convert.sh --skill helm-chart-builder --tool codex|gemini|cursor|windsurf|openclaw

OpenClaw

clawhub install cs-helm-chart-builder

---

Related Skills

  • senior-devops — Broader DevOps scope (CI/CD, IaC, monitoring). Complementary — use helm-chart-builder for chart-specific work, senior-devops for pipeline and infrastructure.
  • docker-development — Container building. Complementary — docker-development builds the images, helm-chart-builder deploys them to Kubernetes.
  • ci-cd-pipeline-builder — Pipeline construction. Complementary — helm-chart-builder defines the deployment artifact, ci-cd-pipeline-builder automates its delivery.
  • senior-security — Application security. Complementary — helm-chart-builder covers Kubernetes-level security (RBAC, pod security), senior-security covers application-level threats.

Related skills

How it compares

Use helm-chart-builder when the deliverable is Helm chart scaffolding; use general DevOps skills when the task is CI pipeline wiring without Kubernetes packaging.

FAQ

What files does helm-chart-builder generate?

helm-chart-builder documents a minimal production chart with Chart.yaml, values.yaml, .helmignore, _helpers.tpl, deployment.yaml, service.yaml, serviceaccount.yaml, NOTES.txt, and tests/test-connection.yaml. The full layout adds ingress, HPA, PDB, NetworkPolicy, ConfigMap, Secret

When should developers use helm-chart-builder?

Developers should use helm-chart-builder when packaging a service for Kubernetes with Helm instead of raw YAML. The skill targets repeatable cluster releases with helpers, tests, and optional schema validation—not application business logic.

Is Helm Chart Builder safe to install?

skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

DevOps & CI/CDdevopsintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.