plugin/skills/helm-procedures/SKILL.md
Use this skill when the agent is authoring or running a Helm upgrade, previewing chart changes with helm diff, rolling back a release, inspecting release history, or managing values files for a Helm chart — for Helm procedures covering helm diff (via helm-diff plugin), atomic upgrade with --atomic and --wait, helm install / upgrade / rollback, release history, and values-file conventions. Loaded by `/infra-change` and other Kubernetes deployment workflows; not a workflow itself.
npx skillsauth add avav25/ai-assets helm-proceduresInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Knowledge reference for Helm operations used by infrastructure-change workflows. Covers chart linting, diff preview via the helm-diff plugin, the safe upgrade pattern (--atomic + --wait), rollback, and inspection of release state.
helm list -n <namespace>
helm get values <release-name> -n <namespace>
helm history <release-name> -n <namespace>
Record current image tags, replica counts, and values-file diffs as the rollback baseline before any upgrade.
Before any diff or upgrade, lint:
helm lint <chart-path>
Lint failures should block the workflow.
The helm-diff plugin is the recommended tool for previewing chart changes before upgrade. Install once:
helm plugin install https://github.com/databus23/helm-diff
Then preview:
helm diff upgrade <release> <chart-path> -n <namespace> -f <values-file>
When presenting a diff for review, summarise as:
## Helm Diff Summary
| Object | Action | Key Changes |
|--------|--------|-------------|
| Deployment/X | changed | replicas: 1->2, image: v1->v2 |
| Service/Y | added | port 8080 |
| Secret/Z | changed | keys modified |
WARNING — Critical changes:
- [deployment restart expected]
- [secret reference changed]
Downtime risk: [yes/no]
helm upgrade <release> <chart-path> -n <namespace> -f <values-file> \
--atomic --timeout 5m --wait
Flag rationale:
--atomic — auto-rolls back on failure (recommended for production). If any resource fails to reach Ready within --timeout, Helm reverts the entire release to the prior revision.--timeout 5m — should match the application's readiness-probe budget, with headroom for image pull and init containers. Tune per environment.--wait — blocks until all resources reach Ready. Without --wait, the upgrade command returns immediately after the API server accepts the manifests, hiding rollout failures from the operator.helm install <release> <chart-path> -n <namespace> -f <values-file> \
--atomic --timeout 5m --wait
For idempotent flows, prefer helm upgrade --install which installs if missing and upgrades if present.
helm rollback <release> <previous-revision> -n <namespace>
Use helm history to find the target revision number. Rollback creates a new revision (it does not delete the failed one), so the release history grows monotonically.
For releases deployed with --atomic, an automatic rollback already executed on failure — manual rollback is needed only for issues detected after the upgrade reports success.
Common values-file layouts:
values.yaml — chart defaults, checked into the chart repovalues-<env>.yaml (e.g., values-prod.yaml, values-staging.yaml) — per-environment overridesvalues-secrets.yaml — encrypted with SOPS or sealed-secrets, never committed in plaintextPass multiple values files in precedence order (later wins):
helm upgrade <release> <chart-path> -n <namespace> \
-f values.yaml -f values-prod.yaml -f values-secrets.yaml \
--atomic --timeout 5m --wait
| Phase | Apply this knowledge |
|---|---|
| Step 3 — Review current state | helm list, helm get values, helm history |
| Step 4 — Implement | Modify values.yaml / templates; helm lint <chart-path> |
| Step 5 — Plan review | helm diff upgrade and diff-summary format |
| Step 6 — Apply | helm upgrade ... --atomic --timeout 5m --wait |
| Step 8 — Rollback | helm rollback <release> <revision> |
/infra-change (Steps 3, 4, 5, 6, 8 — Helm release lifecycle), /deploy-production, /deploy-staging (when charts are the deploy unit)@deployment-procedures (rolling/canary/blue-green strategy choice), @gitops-detection (Argo CD / Flux own the apply gate when GitOps is in use)development
Use this skill when running the recurring (daily) knowledge-base rescan for a repo that already has knowledge/.knowledge-sync.yml — the main-thread dispatcher that reads the config, computes the git delta since last_scanned_sha, maps changed paths to affected doc areas, early-exits cheaply when nothing changed, then fans out one Agent(content-writer) per affected area, applies the propose/direct update policy, advances the baseline only on success, and writes an L4 run log — all with the G1 untrusted-content choke-point, secret-scan, deny-list, and budget controls woven in. For first-time setup use /knowledge-sync-init.
development
Use this skill when bootstrapping scheduled knowledge-base sync for a repo that has no knowledge/.knowledge-sync.yml yet — to run one-time setup that detects the knowledge_root from CLAUDE.md/AGENTS.md, maps doc areas to source globs, records opt-in external sources (Linear/Notion/WebFetch, all disabled by default), captures a baseline last_scanned_sha, sets the per-area update policy, generates or seeds knowledge/CONVENTIONS.md, provisions the L4 memory dir, and offers to register the daily routine. Routes ongoing recurring sync operations to /knowledge-sync.
tools
Use this skill when bootstrapping a target repository to be ai-skills-aware — on the first run of any ai-skills workflow in a fresh repo, when adopting the ai-skills plugin in an existing repo, or after upgrading to a plugin version that adds new memory paths or templates, including when the user does not say "init" but asks to "set up" or "onboard" the repo — to detect codebase type, create CLAUDE.md + AGENTS.md scaffolding, initialize the .ai-skills-memory/ directory tree from L1 templates, and configure .gitignore. Idempotent — safe to re-run. Accepts `--codebase-type <type>` and `--overwrite`. Not for re-initializing only memory — use `/memory-init` instead.
tools
Use this skill when extending, repairing, or improving plugin assets, when ingesting a `/feedback` report as a fix-cycle backlog, or when you do not remember which lower-level command is right for the job — the umbrella workflow for ai-skills plugin-asset authoring and maintenance: creating, auditing, fixing, improving, refactoring, and migrating skills, agents, rules, hooks, prompts, schemas, and rubrics inside the plugin. Auto-classifies the request, loads the right knowledge skills (`@prompt-engineering`, `@context-engineering`, `@team-protocols`), and spawns the right subagents (`prompt-engineer`, `system-architect`, `python-engineer`, `software-engineer`, `qa-engineer`, `eval-judge`) via the `Agent` tool.