/creating-helm-charts
Creating Helm charts to Lerian conventions via ring:helm: standardized chart structure, full env-var coverage from .env.example, security defaults (runAsNonRoot, readOnlyRootFilesystem), ClusterIP-only services, and health probes; validates helm lint and template render. Use
$ npx -y skills add LerianStudio/ring --skill creating-helm-charts --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/creating-helm-charts
Context preview
The summary Claude sees to decide when to auto-load this skill.
Creating Helm charts to Lerian conventions via ring:helm: standardized chart structure, full env-var coverage from .env.example, security defaults (runAsNonRoot, readOnlyRootFilesystem), ClusterIP-only services, and health probes; validates helm lint and template render. Use
SKILL.md
creating-helm-charts.SKILL.mdname: ring:creating-helm-charts
description: "Creating Helm charts to Lerian conventions via ring:helm: standardized chart structure, full env-var coverage from .env.example, security defaults (runAsNonRoot, readOnlyRootFilesystem), ClusterIP-only services, and health probes; validates helm lint and template render. Use when creating, modifying, or reviewing a chart, or migrating docker-compose to Helm. Skip for app-code-only changes or docker-compose-only deployments."
Helm Chart Creation & Maintenance
When to use
- Creating a new Helm chart for any Lerian service
- Modifying an existing Helm chart (adding components, dependencies, templates)
- Reviewing a Helm chart PR for convention compliance
- Migrating a docker-compose setup to Helm
Skip when
- Modifying only application code (no chart changes)
- Working on non-Helm deployment (docker-compose only) → use backend engineer via ring:implementing-tasks
Sequence
Standalone/on-demand. Not part of the lean backend dev-cycle.
Related
**Complementary:** ring:implementing-tasks
**Standards reference:** `dev-team/docs/standards/helm/` **Executor agent:** `ring:helm`
You orchestrate. `ring:helm` creates chart files.
Step 1: Validate Input
Required: `service_name`, `chart_type` (single|multi-component|umbrella), `components` (non-empty). Optional: `dependencies` (postgresql, mongodb, rabbitmq, valkey, keda), `has_worker`, `namespace`.
Step 2: Naming Convention
Default: {service_name}-helm (e.g., reporter-helm, tracer-helm)
Exceptions (no -helm suffix):
- plugin-access-manager
- otel-collector-lerianStep 3: Dispatch Agent
Task:
subagent_type: "ring:helm"
description: "Create Helm chart for {service_name}"
prompt: |
## Helm Chart Creation
service_name: {service_name}
components: {components}
dependencies: {dependencies}
chart_type: {chart_type}
namespace: {namespace}
Standards: Load dev-team/docs/standards/helm/ files.
## Required Steps
1. Read application .env.example and bootstrap/config.go
— extract ALL env vars (missing vars = CrashLoopBackOff)
2. Verify health check endpoint in application source
3. Create chart structure:
charts/{service_name}-helm/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── configmap.yaml
│ ├── secret.yaml (if secrets exist)
│ ├── hpa.yaml (optional)
│ └── serviceaccount.yaml
└── charts/ (dependencies)
4. Chart.yaml: name, version, appVersion, description, type: application
5. _helpers.tpl: name, fullname, chart, labels, selectorLabels, versionLabelValue
6. values.yaml structure:
- global: replicaCount, image.repository/tag/pullPolicy
- Per-component config sections
- configmap: all non-secret env vars
- secrets: all sensitive env vars (no real values)
- service: type: ClusterIP, port, targetPort
- resources: requests/limits
- probes: livenessProbe, readinessProbe (match /health and /readyz)
- dependencies config sections
7. Security defaults:
- securityContext: runAsNonRoot: true, runAsUser: 1000
- readOnlyRootFilesystem: true
- allowPrivilegeEscalation: false
8. Service type: ALWAYS ClusterIP (never NodePort or LoadBalancer)
## Required Output
- Env Var Coverage table (100% of .env.example covered)
- helm lint result: MUST PASS
- helm template render: MUST produce valid YAML
- Files created listStep 4: Validate Output
if env_vars_missing > 0:
→ FAIL: list missing vars, re-dispatch
if helm lint fails:
→ Re-dispatch with specific lint errors
if all checks PASS:
→ Proceed to worker setup or final validation
Worker Chart (if has_worker = true)
Additional dispatch for worker component:
- Separate Deployment without Service
- Different resource limits (CPU-focused, no port exposure)
- Same configmap/secrets references
- LivenessProbe via process check (not HTTP)
Validation Checklist
## Helm Chart Validation
| Check | Status | Evidence |
|-------|--------|----------|
| Env var coverage (100%) | ✅/❌ | X/Y vars mapped |
| helm lint PASS | ✅/❌ | command output |
| helm template renders | ✅/❌ | YAML valid |
| Security context set | ✅/❌ | deployment.yaml:{line} |
| Service type = ClusterIP | ✅/❌ | service.yaml:{line} |
| Health probes match endpoints | ✅/❌ | deployment.yaml:{line} |
| No real secrets in values | ✅/❌ | |Read more
name: ring:creating-helm-charts description: "Creating Helm charts to Lerian conventions via ring:helm: standardized chart structure, full env-var coverage from .env.example, security defaults (runAsNonRoot, readOnlyRootFilesystem), ClusterIP-only services, and health probes; validates helm lint and template render. Use when creating, modifying, or reviewing a chart, or migrating docker-compose to Helm. Skip for app-code-only changes or docker-compose-only deployments."
Helm Chart Creation & Maintenance
When to use
- Creating a new Helm chart for any Lerian service
- Modifying an existing Helm chart (adding components, dependencies, templates)
- Reviewing a Helm chart PR for convention compliance
- Migrating a docker-compose setup to Helm
Skip when
- Modifying only application code (no chart changes)
- Working on non-Helm deployment (docker-compose only) → use backend engineer via ring:implementing-tasks
Sequence
Standalone/on-demand. Not part of the lean backend dev-cycle.
Related
**Complementary:** ring:implementing-tasks
**Standards reference:** `dev-team/docs/standards/helm/` **Executor agent:** `ring:helm`
You orchestrate. `ring:helm` creates chart files.
Step 1: Validate Input
Required: `service_name`, `chart_type` (single|multi-component|umbrella), `components` (non-empty). Optional: `dependencies` (postgresql, mongodb, rabbitmq, valkey, keda), `has_worker`, `namespace`.
Step 2: Naming Convention
Default: {service_name}-helm (e.g., reporter-helm, tracer-helm)
Exceptions (no -helm suffix):
- plugin-access-manager
- otel-collector-lerianStep 3: Dispatch Agent
Task:
subagent_type: "ring:helm"
description: "Create Helm chart for {service_name}"
prompt: |
## Helm Chart Creation
service_name: {service_name}
components: {components}
dependencies: {dependencies}
chart_type: {chart_type}
namespace: {namespace}
Standards: Load dev-team/docs/standards/helm/ files.
## Required Steps
1. Read application .env.example and bootstrap/config.go
— extract ALL env vars (missing vars = CrashLoopBackOff)
2. Verify health check endpoint in application source
3. Create chart structure:
charts/{service_name}-helm/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── configmap.yaml
│ ├── secret.yaml (if secrets exist)
│ ├── hpa.yaml (optional)
│ └── serviceaccount.yaml
└── charts/ (dependencies)
4. Chart.yaml: name, version, appVersion, description, type: application
5. _helpers.tpl: name, fullname, chart, labels, selectorLabels, versionLabelValue
6. values.yaml structure:
- global: replicaCount, image.repository/tag/pullPolicy
- Per-component config sections
- configmap: all non-secret env vars
- secrets: all sensitive env vars (no real values)
- service: type: ClusterIP, port, targetPort
- resources: requests/limits
- probes: livenessProbe, readinessProbe (match /health and /readyz)
- dependencies config sections
7. Security defaults:
- securityContext: runAsNonRoot: true, runAsUser: 1000
- readOnlyRootFilesystem: true
- allowPrivilegeEscalation: false
8. Service type: ALWAYS ClusterIP (never NodePort or LoadBalancer)
## Required Output
- Env Var Coverage table (100% of .env.example covered)
- helm lint result: MUST PASS
- helm template render: MUST produce valid YAML
- Files created listStep 4: Validate Output
if env_vars_missing > 0: → FAIL: list missing vars, re-dispatch if helm lint fails: → Re-dispatch with specific lint errors if all checks PASS: → Proceed to worker setup or final validation
Worker Chart (if has_worker = true)
Additional dispatch for worker component:
- Separate Deployment without Service
- Different resource limits (CPU-focused, no port exposure)
- Same configmap/secrets references
- LivenessProbe via process check (not HTTP)
Validation Checklist
## Helm Chart Validation
| Check | Status | Evidence |
|-------|--------|----------|
| Env var coverage (100%) | ✅/❌ | X/Y vars mapped |
| helm lint PASS | ✅/❌ | command output |
| helm template renders | ✅/❌ | YAML valid |
| Security context set | ✅/❌ | deployment.yaml:{line} |
| Service type = ClusterIP | ✅/❌ | service.yaml:{line} |
| Health probes match endpoints | ✅/❌ | deployment.yaml:{line} |
| No real secrets in values | ✅/❌ | |Proven engineering practices, enforced through skills. Ring is a comprehensive skills library and workflow system for AI agents that transforms how AI assistants approach software development.
Repo: LerianStudio/ring
Other skills on ring.
- /analyzing-options
Analyzing different approaches for a task or problem with structured comparisons, effort estimates, and recommendations. Use when facing strategic decisions, architecture choices, or multiple viable approaches. Skip when there's an obvious single approach or the decision is
Open skill - /auditing-production-readiness
Auditing a service's production readiness against Ring engineering standards across base dimensions plus a conditional multi-tenant dimension, then emitting a scored report and an HTML dashboard. Use before production deploy, periodic review, onboarding, or a major release. Skip
Open skill - /cleaning-comments
Cleaning redundant and obvious comments following clean code principles while preserving meaningful documentation. Supports git scope filtering (staged, unstaged, branch, commit-range). Use when code has excessive comments, during code review, or post-refactor cleanup. Skip when
Open skill - /committing-changes
Commit changes with scope allowlist enforcement, atomic grouping, GPG-signed conventional commits, and trailer management. Detects the repo's PR-validation scope policy before proposing any message. Use when the user asks to commit or has changes ready to record. Skip when the
Open skill - /creating-handoffs
Creating a handoff document that captures session state (completed work, decisions, open items, next steps) and delivering it via Plan Mode so the user gets the native 'clear context and continue implementing' resume option. Use when ending a session, when context grows large,
Open skill - /creating-worktrees
Creating an isolated git worktree for parallel branch work: selects the directory by priority order, verifies/adds .gitignore safety, auto-installs the detected toolchain's dependencies, runs a baseline test, and reports readiness. Use before a feature that needs isolation from
Open skill

