Kube-Hetzner is an infrastructure project that uses Terraform or OpenTofu to deploy and maintain Kubernetes clusters on Hetzner Cloud. It is for operators who need highly available clusters based on k3s or RKE2, with networking, storage, ingress, certificates, and upgrades configured as part of the deployment.
Borrowing it
Nothing to install: this file belongs to mysticaltech/terraform-hcloud-kube-hetzner. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/mysticaltech/terraform-hcloud-kube-hetzner/master/.claude/skills/migrate-v2-to-v3/SKILL.mdgit clone --depth 1 https://github.com/mysticaltech/terraform-hcloud-kube-hetznerWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/mysticaltech/terraform-hcloud-kube-hetzner/migrate-v2-to-v3)<a href="https://agentmods.dev/skills/mysticaltech/terraform-hcloud-kube-hetzner/migrate-v2-to-v3"><img src="https://agentmods.dev/badge/skills/mysticaltech/terraform-hcloud-kube-hetzner/migrate-v2-to-v3/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mysticaltech/terraform-hcloud-kube-hetzner/migrate-v2-to-v3"><img src="https://agentmods.dev/badge/skills/mysticaltech/terraform-hcloud-kube-hetzner/migrate-v2-to-v3.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00029 | $0.04001 |
| Opus 5 | $0.00015 | $0.02001 |
| Sonnet 5 | $0.00006 | $0.00800 |
| Haiku 4.5 | $0.00003 | $0.00400 |
Grade E, and why
migrate-v2-to-v3 scanned grade E with 2 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Reaches for credential fileshighPrivilege escalation
SSH keys, cloud credentials, git-credentials, .npmrc, /etc/shadow: reading these is how a config file becomes a credential leak.
`/root/.ssh/authorized_keys`. The default preserves unknown out-of-band keys Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf "$tmpdir" How it starts
The opening of the file, as written. The whole thing — 346 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Migrate kube-hetzner v2 to v3
Purpose
Safely migrate an existing kube-hetzner cluster from v2.x to v3.x.
This skill is for real user Terraform roots, not for brand-new clusters. It prioritizes preserving infrastructure and making Terraform validation failures actionable.
Canonical References
Read these before editing:
docs/v2-to-v3-migration.md- operational migration playbookdocs/v3-release-evidence.md- live v2.21 -> v3 upgrade evidenceMIGRATION.md- canonical old-to-new variable mapCHANGELOG.md- v3 upgrade notes and release contextvariables.tf- exact v3 input contract and validation ruleskube.tf.example- current v3 configuration examplescripts/v2_to_v3_migration_assistant.py- static config and plan auditdocs/selinux.md- SELinux policy, AVC evidence, and per-pool fallbackscripts/destroy.shandscripts/cleanup.sh- teardown and orphan cleanup
Safety Rules
- Never run
terraform applyunless the user explicitly asks after plan review. - Always back up state before changing the module version.
- Never ignore
destroy,replace, orforces replacementin a v3 upgrade plan. - Do not allow a silent K3s channel policy change.
MIGRATION.mddocuments that v2 defaultedk3s_channeltov1.33; v3 defaults it tostablewhile automatic Kubernetes upgrades remain default-on. The user must choose before the first v3 apply. - Treat replacements for
hcloud_network,hcloud_network_subnet,hcloud_server,hcloud_load_balancer,hcloud_primary_ip,hcloud_placement_group,hcloud_volume, orhcloud_firewallas blockers until explained. - For production in-place upgrades,
MIGRATION.mdis the operator-facing safety contract. Its no-destroy jq gate is canonical; do not weaken or abbreviate it. - Never reorder or insert control-plane or agent nodepools mid-list during or after migration. Node resource addresses are index-keyed; append only unless the user is intentionally planning a state migration or blue/green rebuild.
- Do not "fix" a v3 validation error by bypassing validation. Fix the configuration.
- For custom network, private-only, Robot/vSwitch, or multinetwork clusters, prefer recommending blue/green if the in-place plan is not clearly safe.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago Changed · +6 lines 091014650d57
- 10d ago Changed · +2 lines 3d0312ef7bcf
- 13d ago First seen · 338 lines · 29 tokens per session scan E 125b0b7a3891
migrate-v2-to-v3 is a skill published in the GitHub repository mysticaltech/terraform-hcloud-kube-hetzner (3,929 stars, last pushed 3d ago), licensed MIT. It adds 29 tokens to every session and 4,001 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it E with 2 findings (reaches for credential files, recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
k8s-aiops
Use this skill whenever the user needs to operate a Kubernetes cluster — list/inspect pods, deployments, statefulsets, daemonsets, replicasets, jobs, cronjobs, services, ingresses, endpoints, configmaps, secrets (names/keys only), PVCs/PVs/storageclasses, nodes, namespaces, and events; read pod logs; describe…
k8s-network-policy
Review Kubernetes NetworkPolicies — what is actually permitted to reach a workload, and whether the answer can be trusted. Use when asked what can talk to a pod, whether a namespace is restricted, why traffic is being blocked, or for any security review of cluster network segmentation.
k8s-service-path
Trace the Kubernetes service path — Service to selector to pods to EndpointSlices to readiness, plus Ingress routing. Use when a service is getting no traffic, an ingress is not routing, or someone asks why a workload is unreachable inside a cluster.
k8s-workload-inventory
List Kubernetes workloads and namespaces — pods with their node, phase and readiness, plus events. Use when asked what is running, where it is running, what is failing, or for a general inventory of a cluster.
Cloud Security & Container Hardening
AWS/Azure/GCP security auditing, container and Kubernetes hardening, Infrastructure as Code scanning, and cloud compliance assessment.
huawei-cloud-solution-ops
A skill for Huawei Cloud solution operations. It helps agents inspect, plan, operate, troubleshoot, and verify Huawei Cloud resources through hcloud, Huawei Cloud SDKs, Terraform, and MaaS capabilities. Use this when users want to query or change Huawei Cloud resources, troubleshoot authentication and API issues…