Claude Prompt to Create Helm Charts for Microservices

What this prompt does

This prompt creates a reusable Helm chart for deploying [service_name], a [service_type] microservice, to Kubernetes. The Chart.yaml uses API version v2 with proper metadata, app version [app_version], and a chart version following semver, while the values.yaml parameterizes image repository, tag, replica count, resource limits, ingress host, and [custom_values] with sensible defaults. The goal is one chart that ships the same templates to every environment with only the values changing.

The structure works because it makes a single chart serve dev, staging, and production cleanly. Templates for Deployment, Service, Ingress, ConfigMap, and HPA use template helpers in _helpers.tpl for labels, selectors, and name generation, and environment-specific values files (values-dev, values-staging, values-production) carry the [env_differences]. Conditional templates enable or disable ingress, HPA, PodDisruptionBudget, and service monitor based on values flags, a NOTES.txt outputs the access URL and health check command after deployment, a tests/ directory holds a connection test pod, and pre-install and pre-upgrade hooks handle [hook_tasks]. The chart is validated with helm lint and helm template before it ships. Good _helpers.tpl labels and conditional templates are exactly what keep a chart reusable instead of a copy-paste mess.

When to use it

• You deploy the same service to dev, staging, and production and want one chart with per-env values.
• You want consistent labels and selectors via _helpers.tpl instead of copy-paste.
• You need optional components toggled by values flags rather than separate forks.
• You want pre-install or pre-upgrade hooks for migrations or cache warmup.
• You want a connection test and a NOTES.txt for clear post-deploy guidance.
• You want the chart validated with helm lint and helm template before shipping.

Example output

Expect a full chart directory rather than a single file. You get a Chart.yaml, a parameterized values.yaml including [custom_values], templates for Deployment, Service, Ingress, ConfigMap, and HPA, and a _helpers.tpl with shared label and selector logic. It also includes environment-specific values files reflecting [env_differences], conditional blocks for optional components, a NOTES.txt, a tests/ connection pod, and pre-install and pre-upgrade hooks for [hook_tasks]. The whole structure is shaped to pass helm lint and render cleanly with helm template before you ever install it.

Pro tips

• Keep good label and selector helpers in _helpers.tpl, since consistent labels are what keep a chart reusable instead of a copy-paste mess.
• Put only real [env_differences] such as replica count, resource limits, and log level in the per-env files, not duplicated defaults.
• Use conditional templates so optional pieces like the PodDisruptionBudget or service monitor turn on by flag rather than living in separate forks.
• Order [hook_tasks] carefully, since a pre-upgrade migration that fails should block the rollout rather than leave a half-migrated database.
• Always run helm lint and helm template before installing, because rendering locally catches templating errors a live install would surface painfully.
• Keep the tests/ connection pod, since helm test then gives you a cheap post-deploy smoke check whenever you deploy.