Back to DevOps & CI/CD

helm-chart-scaffolding

HelmKubernetesDevOpsChartTemplatingApplication PackagingDeploymentScaffolding
⭐ 36.8kπŸ“„ MITπŸ•’ 2026-06-16Source β†—

Install this skill

npx skills add wshobson/agents

Works across Claude Code, Cursor, Codex, Copilot & Antigravity

The Helm chart scaffolding skill provides a structured methodology for generating and refining Kubernetes packages. It centers on transforming static manifests into dynamic, reusable templates using Go templating logic. This process involves establishing a standard directory hierarchy, defining application metadata in Chart.yaml, and centralizing configuration parameters within values.yaml. By following these conventions, developers decouple application settings from deployment logic, enabling consistent rollouts across dev, stage, and production clusters. The workflow emphasizes modular design, allowing users to define dependencies, set resource limits, and manage autoscaling policies programmatically. Instead of managing raw YAML files, this approach treats infrastructure as a versioned product, ensuring that manifests remain maintainable, scalable, and compatible with established Kubernetes operational standards throughout the application lifecycle.

When to Use This Skill

  • β€’Packaging microservices for standardized cluster deployment
  • β€’Standardizing configuration across multiple environment-specific clusters
  • β€’Distributing complex multi-container applications as a single unit
  • β€’Managing versioned releases and automatic rollback configurations

How to Invoke This Skill

Example prompts that trigger this skill in Claude Code, Cursor, or Antigravity:

  • β€œscaffold a new helm chart for my service
  • β€œhelp me structure my helm values and templates
  • β€œhow do I organize my k8s manifests into a helm chart
  • β€œcreate a helm chart with standard dependencies
  • β€œshow me how to configure chart metadata and template helpers

Pro Tips

  • πŸ’‘Always version your Helm charts semantically (e.g., `1.0.0`) and ensure your `Chart.yaml` dependencies are explicitly managed for reliable deployments.
  • πŸ’‘Utilize `_helpers.tpl` for common templates and partials to keep your main templates clean and promote reusability across your chart.
  • πŸ’‘Implement `values.schema.json` to enforce strict validation for chart values, preventing common configuration errors and improving chart usability.

What this skill does

  • β€’Automates boilerplate generation for Kubernetes application structures
  • β€’Implements Go template logic for dynamic manifest injection
  • β€’Manages hierarchical configuration via default and override values files
  • β€’Defines external dependency requirements and chart metadata
  • β€’Supports modular partials using custom helper functions

When not to use it

  • βœ•For simple, single-manifest applications where complexity is unnecessary
  • βœ•When strictly using GitOps operators that prefer Kustomize-based patching

Example workflow

  1. Run helm create to initialize the file structure
  2. Define metadata and external dependencies in Chart.yaml
  3. Map required environment variables and resource limits in values.yaml
  4. Refactor static YAML manifests into dynamic Go templates
  5. Create reusable helper logic within _helpers.tpl
  6. Validate the rendered output using the helm template command

Prerequisites

  • –Installed Helm CLI
  • –Kubernetes cluster access (kubectl)
  • –Existing container images ready for deployment

Pitfalls & limitations

  • !Over-engineering templates leads to high maintenance costs
  • !Incorrectly formatted whitespace in indentations breaks template rendering
  • !Failing to scope helpers correctly can lead to namespace collisions

FAQ

Why use Helm instead of plain YAML?
Helm allows for variable injection and logic, which makes it significantly easier to manage configuration differences between development, staging, and production environments.
Can I include external database dependencies?
Yes, Helm allows you to define dependency charts in the Chart.yaml file, which will be managed and installed alongside your application.
What is the role of _helpers.tpl?
This file contains reusable template snippets and logic definitions that you can call repeatedly throughout your deployment manifests to keep code DRY.

How it compares

Unlike manual YAML editing which requires deep duplication per environment, this skill enforces a templating system that separates static manifests from variable configurations.

Source & trust

⭐ 37k starsπŸ“„ MITπŸ•’ Updated 2026-06-16
πŸ“„ Full skill instructions β€” original source: wshobson/agents
# Helm Chart Scaffolding

Comprehensive guidance for creating, organizing, and managing Helm charts for packaging and deploying Kubernetes applications.

## Purpose

This skill provides step-by-step instructions for building production-ready Helm charts, including chart structure, templating patterns, values management, and validation strategies.

## When to Use This Skill

Use this skill when you need to:

- Create new Helm charts from scratch
- Package Kubernetes applications for distribution
- Manage multi-environment deployments with Helm
- Implement templating for reusable Kubernetes manifests
- Set up Helm chart repositories
- Follow Helm best practices and conventions

## Helm Overview

**Helm** is the package manager for Kubernetes that:

- Templates Kubernetes manifests for reusability
- Manages application releases and rollbacks
- Handles dependencies between charts
- Provides version control for deployments
- Simplifies configuration management across environments

## Step-by-Step Workflow

### 1. Initialize Chart Structure

**Create new chart:**

helm create my-app


**Standard chart structure:**

my-app/
β”œβ”€β”€ Chart.yaml # Chart metadata
β”œβ”€β”€ values.yaml # Default configuration values
β”œβ”€β”€ charts/ # Chart dependencies
β”œβ”€β”€ templates/ # Kubernetes manifest templates
β”‚ β”œβ”€β”€ NOTES.txt # Post-install notes
β”‚ β”œβ”€β”€ _helpers.tpl # Template helpers
β”‚ β”œβ”€β”€ deployment.yaml
β”‚ β”œβ”€β”€ service.yaml
β”‚ β”œβ”€β”€ ingress.yaml
β”‚ β”œβ”€β”€ serviceaccount.yaml
β”‚ β”œβ”€β”€ hpa.yaml
β”‚ └── tests/
β”‚ └── test-connection.yaml
└── .helmignore # Files to ignore


### 2. Configure Chart.yaml

**Chart metadata defines the package:**

apiVersion: v2
name: my-app
description: A Helm chart for My Application
type: application
version: 1.0.0 # Chart version
appVersion: "2.1.0" # Application version

# Keywords for chart discovery
keywords:
- web
- api
- backend

# Maintainer information
maintainers:
- name: DevOps Team
email: [email protected]
url: https://github.com/example/my-app

# Source code repository
sources:
- https://github.com/example/my-app

# Homepage
home: https://example.com

# Chart icon
icon: https://example.com/icon.png

# Dependencies
dependencies:
- name: postgresql
version: "12.0.0"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
- name: redis
version: "17.0.0"
repository: "https://charts.bitnami.com/bitnami"
condition: redis.enabled


**Reference:** See assets/Chart.yaml.template for complete example

### 3. Design values.yaml Structure

**Organize values hierarchically:**

# Image configuration
image:
repository: myapp
tag: "1.0.0"
pullPolicy: IfNotPresent

# Number of replicas
replicaCount: 3

# Service configuration
service:
type: ClusterIP
port: 80
targetPort: 8080

# Ingress configuration
ingress:
enabled: false
className: nginx
hosts:
- host: app.example.com
paths:
- path: /
pathType: Prefix

# Resources
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"

# Autoscaling
autoscaling:
enabled: false
minReplicas: 2
maxReplicas: 10
targetCPUUtilizationPercentage: 80

# Environment variables
env:
- name: LOG_LEVEL
value: "info"

# ConfigMap data
configMap:
data:
APP_MODE: production

# Dependencies
postgresql:
enabled: true
auth:
database: myapp
username: myapp

redis:
enabled: false


**Reference:** See assets/values.yaml.template for complete structure

### 4. Create Template Files

**Use Go templating with Helm functions:**

**templates/deployment.yaml:**

apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "my-app.fullname" . }}
labels:
{{- include "my-app.labels" . | nindent 4 }}
spec:
{{- if not .Values.autoscaling.enabled }}
replicas: {{ .Values.replicaCount }}
{{- end }}
selector:
matchLabels:
{{- include "my-app.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "my-app.selectorLabels" . | nindent 8 }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
- name: http
containerPort: {{ .Values.service.targetPort }}
resources:
{{- toYaml .Values.resources | nindent 12 }}
env:
{{- toYaml .Values.env | nindent 12 }}


### 5. Create Template Helpers

**templates/\_helpers.tpl:**

{{/*
Expand the name of the chart.
*/}}
{{- define "my-app.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}

{{/*
Create a default fully qualified app name.
*/}}
{{- define "my-app.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- if contains $name .Release.Name }}
{{- .Release.Name | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
{{- end }}

{{/*
Common labels
*/}}
{{- define "my-app.labels" -}}
helm.sh/chart: {{ include "my-app.chart" . }}
{{ include "my-app.selectorLabels" . }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

{{/*
Selector labels
*/}}
{{- define "my-app.selectorLabels" -}}
app.kubernetes.io/name: {{ include "my-app.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}


### 6. Manage Dependencies

**Add dependencies in Chart.yaml:**

dependencies:
- name: postgresql
version: "12.0.0"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled


**Update dependencies:**

helm dependency update
helm dependency build


**Override dependency values:**

# values.yaml
postgresql:
enabled: true
auth:
database: myapp
username: myapp
password: changeme
primary:
persistence:
enabled: true
size: 10Gi


### 7. Test and Validate

**Validation commands:**

# Lint the chart
helm lint my-app/

# Dry-run installation
helm install my-app ./my-app --dry-run --debug

# Template rendering
helm template my-app ./my-app

# Template with values
helm template my-app ./my-app -f values-prod.yaml

# Show computed values
helm show values ./my-app


**Validation script:**

#!/bin/bash
set -e

echo "Linting chart..."
helm lint .

echo "Testing template rendering..."
helm template test-release . --dry-run

echo "Checking for required values..."
helm template test-release . --validate

echo "All validations passed!"


**Reference:** See scripts/validate-chart.sh

### 8. Package and Distribute

**Package the chart:**

helm package my-app/
# Creates: my-app-1.0.0.tgz


**Create chart repository:**

# Create index
helm repo index .

# Upload to repository
# AWS S3 example
aws s3 sync . s3://my-helm-charts/ --exclude "*" --include "*.tgz" --include "index.yaml"


**Use the chart:**

helm repo add my-repo https://charts.example.com
helm repo update
helm install my-app my-repo/my-app


### 9. Multi-Environment Configuration

**Environment-specific values files:**

my-app/
β”œβ”€β”€ values.yaml # Defaults
β”œβ”€β”€ values-dev.yaml # Development
β”œβ”€β”€ values-staging.yaml # Staging
└── values-prod.yaml # Production


**values-prod.yaml:**

replicaCount: 5

image:
tag: "2.1.0"

resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1Gi"
cpu: "1000m"

autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 20

ingress:
enabled: true
hosts:
- host: app.example.com
paths:
- path: /
pathType: Prefix

postgresql:
enabled: true
primary:
persistence:
size: 100Gi


**Install with environment:**

helm install my-app ./my-app -f values-prod.yaml --namespace production


### 10. Implement Hooks and Tests

**Pre-install hook:**

# templates/pre-install-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: {{ include "my-app.fullname" . }}-db-setup
annotations:
"helm.sh/hook": pre-install
"helm.sh/hook-weight": "-5"
"helm.sh/hook-delete-policy": hook-succeeded
spec:
template:
spec:
containers:
- name: db-setup
image: postgres:15
command: ["psql", "-c", "CREATE DATABASE myapp"]
restartPolicy: Never


**Test connection:**

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
name: "{{ include "my-app.fullname" . }}-test-connection"
annotations:
"helm.sh/hook": test
spec:
containers:
- name: wget
image: busybox
command: ['wget']
args: ['{{ include "my-app.fullname" . }}:{{ .Values.service.port }}']
restartPolicy: Never


**Run tests:**

helm test my-app


## Common Patterns

### Pattern 1: Conditional Resources

{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: {{ include "my-app.fullname" . }}
spec:
# ...
{{- end }}


### Pattern 2: Iterating Over Lists

env:
{{- range .Values.env }}
- name: {{ .name }}
value: {{ .value | quote }}
{{- end }}


### Pattern 3: Including Files

data:
config.yaml: |
{{- .Files.Get "config/application.yaml" | nindent 4 }}


### Pattern 4: Global Values

global:
imageRegistry: docker.io
imagePullSecrets:
- name: regcred

# Use in templates:
image: {{ .Values.global.imageRegistry }}/{{ .Values.image.repository }}


## Best Practices

1. **Use semantic versioning** for chart and app versions
2. **Document all values** in values.yaml with comments
3. **Use template helpers** for repeated logic
4. **Validate charts** before packaging
5. **Pin dependency versions** explicitly
6. **Use conditions** for optional resources
7. **Follow naming conventions** (lowercase, hyphens)
8. **Include NOTES.txt** with usage instructions
9. **Add labels** consistently using helpers
10. **Test installations** in all environments

## Troubleshooting

**Template rendering errors:**

helm template my-app ./my-app --debug


**Dependency issues:**

helm dependency update
helm dependency list


**Installation failures:**

helm install my-app ./my-app --dry-run --debug
kubectl get events --sort-by='.lastTimestamp'


## Reference Files

- assets/Chart.yaml.template - Chart metadata template
- assets/values.yaml.template - Values structure template
- scripts/validate-chart.sh - Validation script
- references/chart-structure.md - Detailed chart organization

## Related Skills

- k8s-manifest-generator - For creating base Kubernetes manifests
- gitops-workflow - For automated Helm chart deployments

How to Use This Skill Unit

Option A: Project-Specific (Recommended)

  1. Click "Download" above
  2. In your project, create the directory: .agent/skills/helm-chart-scaffolding/
  3. Save the file as SKILL.md
  4. The agent will automatically discover the skill based on its description.

Option B: Global Installation (All Agents)

Save the file to these locations to make it available across all projects:

  • Claude Code: ~/.claude/skills/wshobson/agents/helm-chart-scaffolding/SKILL.md
  • Cursor: ~/.cursor/skills/wshobson/agents/helm-chart-scaffolding/SKILL.md
  • Antigravity: ~/.gemini/antigravity/skills/wshobson/agents/helm-chart-scaffolding/SKILL.md

πŸš€ Install with CLI:
npx skills add wshobson/agents

Read the Master Guide: Mastering Agent Skills β†’

Recommended Rules

View more rules β†’

Recommended Workflows

View more workflows β†’

Recommended MCP Servers

View more MCP servers β†’

Take It Further

Maximize your productivity with these powerful resources

πŸ“‹

Define Your Standards

Set up coding standards to ensure this workflow produces consistent, high-quality results.

Browse Rules Library
πŸ“–

Master Workflows

Learn how to create custom workflows, use Turbo Mode, and build your automation library.

Complete Guide

How to use this Skill in Claude Code & Cursor

For Claude Code (CLI)

To use this skill in Claude Code, copy the rule content into your project's custom instructions or follow our Add-Skill CLI guide. This ensures Claude follows your standards during every code generation.

For Cursor & Windsurf

For Cursor or Windsurf, individual skills are best used in the "Rules for AI" section. This specific unit helps the agent avoid devops & ci/cd issues, leading to cleaner, more efficient code.

Why the skill format matters: the standardized Agent Skills format lets your AI agent load detailed instructions only when they are relevant, keeping your prompt clean while improving results.

Source & attribution

This skill is categorized under DevOps & CI/CD and is published by W. Shobson, maintained in wshobson/agents.

← Browse All Agent Skills
Sponsored AI assistant. Recommendations may be paid.