Chapter 14: Worked Example: Creating a Helm Chart From a Reference Chart

February 11, 2026 · 4 min read
blog

Series: LLM Development Guide

Chapter 14 of 15

Previous: Chapter 13: Building a Prompt Library: Governance + Quality Bar

Next: Chapter 15: Worked Example: Converting an Ansible Playbook to a Go Temporal Workflow

What you’ll be able to do

You’ll be able to create a production-quality Helm chart by following an existing chart in your repo as the reference:

  • Gather high-signal reference inputs.
  • Produce a phased plan and prompt docs.
  • Execute in reviewable commits.
  • Verify the chart renders and lints cleanly.

TL;DR

  • The reference chart is the source of truth for structure and conventions.
  • Paste the reference inputs into your planning prompt.
  • Execute one file at a time, with helm lint and helm template as gates.
  • If you do not have a real reference chart, pick a different worked example.

Table of contents

Scenario

Goal: create a new chart (example: metrics-gateway) based on a known-good reference chart (example: event-processor).

This is a workflow example. You will need to substitute your real chart names and paths.

Reference inputs

Run these commands in your repo and paste the output into the planning prompt.

# Chart structure and key files.
tree charts/event-processor/

sed -n '1,200p' charts/event-processor/Chart.yaml

sed -n '1,200p' charts/event-processor/values.yaml

sed -n '1,200p' charts/event-processor/templates/_helpers.tpl

# If your reference chart uses these, include them too.
ls -la charts/event-processor | rg -n "values-" || true

Why this matters:

  • Structure: avoids “generic Helm” output.
  • Naming and labels: keeps your charts consistent.
  • Values shape: keeps operator UX consistent.

Phase 1: Plan

Create a plan that is mostly:

  • What files will exist.
  • What differences are specific to metrics-gateway (ports, probes, resources).
  • How you will verify each phase.

Example plan skeleton:

# metrics-gateway Helm Chart Plan

## Goals
- Create charts/metrics-gateway matching reference structure.
- Render successfully with helm template.
- Lint cleanly.

## References
- charts/event-processor/

## Phase 1: Analysis
- [ ] Document naming conventions from reference.

Verification:
- tree charts/event-processor

## Phase 2: Scaffold
- [ ] Create Chart.yaml
- [ ] Create values.yaml
- [ ] Create templates/_helpers.tpl

Verification:
- helm lint charts/metrics-gateway

## Phase 3: Core templates
- [ ] deployment
- [ ] service
- [ ] configmap

Verification:
- helm template charts/metrics-gateway > /tmp/rendered.yaml

## Definition of done
- [ ] helm lint exits 0
- [ ] helm template exits 0

Phase 2: Prompt docs

Generate one prompt file per phase. Include:

  • The plan path.
  • The work-notes path.
  • Reference chart file paths.
  • Deliverables (exact files).
  • Constraints (MUST and MUST NOT).
  • Verification commands.

A good constraint to include:

  • “Match reference structure exactly.” (and name what that means)

Phase 3: Execute in logical units

You have two implementation strategies.

This is often the fastest way to guarantee structure consistency.

cp -R charts/event-processor charts/metrics-gateway

# Then rename strings and values in a controlled way.
# Review each replacement before committing.
rg -n "event-processor" charts/metrics-gateway

Now execute in logical units:

  • Update Chart.yaml.
  • Update values.yaml.
  • Update _helpers.tpl.
  • Update one template file at a time.

For each logical unit:

  • Update work notes.
  • Run helm lint.
  • Propose a commit.

Strategy B: scaffold from scratch, guided by the reference

Use this when copying would bring too much baggage.

You still paste the reference files, but ask the model to reproduce the structure explicitly.

Verification

Run both linting and rendering.

helm lint charts/metrics-gateway

helm template charts/metrics-gateway > /tmp/metrics-gateway.rendered.yaml

test -s /tmp/metrics-gateway.rendered.yaml

Expected results:

  • All commands exit with code 0.
  • The rendered YAML is non-empty.

Optional: diff against the reference chart structure:

# Compare structure only.
(cd charts/event-processor && find . -type f | sort) > /tmp/ref-files.txt
(cd charts/metrics-gateway && find . -type f | sort) > /tmp/new-files.txt

diff -u /tmp/ref-files.txt /tmp/new-files.txt || true

Expected result:

  • The file lists are close, with only intentional differences.

Gotchas

  • If you do not paste the reference files, you will get generic charts.
  • Be explicit about service ports, probe paths, and resource defaults.
  • Add negative constraints (“do not add ingress yet”) so scope doesn’t expand.

Continue -> Chapter 15: Worked Example: Converting an Ansible Playbook to a Go Temporal Workflow

Llm Software-Engineering Workflow Agents
Authors
Roy Gabriel
DevOps Architect · Applied AI Engineer
I’ve spent 20 years building systems across embedded firmware, security platforms, fintech, and enterprise architecture. Today I focus on production AI systems in Go: multi-agent orchestration, MCP server ecosystems, and the DevOps platforms that keep them running. I care about systems that work under pressure: observable, recoverable, and built to last.