hetzner

Run uv run "$HERE/scripts/invoke.py" — $HERE is the directory that holds this SKILL.md — with everything the user typed after the Skill name, verbatim and however many lines, on stdin. Exit 0: do what it prints. On any other exit, if you introduced a known construction error and can correct it while preserving the user's request and authority, account for effects already produced, submit the corrected invocation through the same shim, and continue from the failed boundary; a refusal before the operation starts consumes no operation. Otherwise show what it printed to the user verbatim and stop. Never repair input the user supplied, or automatically retry exact help, an unmet dependency, an unrelated failure, or a failure whose origin or valid correction is unknown.

Arguments

<project> is a Hetzner Cloud project's name exactly as the Console shows it, and the name of the hcloud context setup makes for that project. --yes lets setup replace a context of that name, which is how a token is rotated.

With path setup or status, follow that section below and not the steps. With an empty path there is no operand: the task is instruction, or, where there is none, the task established in the conversation; where there is neither, ask what the user wants to do on Hetzner.

Establish the operation

1. Read the project's deployment documentation and existing infrastructure, configuration, and release files. Resolve the target Hetzner project, environment, resource identity, requested outcome, and existing authorization. A project is reached through the hcloud context that carries its name exactly as the Console shows it, and hcloud context list names them: where the instruction names a project, that project's context is the target; where it names none and exactly one context exists, that one is; otherwise settle the target before any remote operation. A context named otherwise is used only where the instruction names it by that name. Preparation or inspection alone authorizes no deployment.
2. Keep the project's chosen stack and source of truth. Manage resources already owned by Terraform or Ansible through that project's workflow; reconcile emergency changes back into it. For a new small setup, use hcloud for Cloud resources, cloud-init for bootstrap, and SSH for installation and deployment. Add a platform or configuration tool only when the task calls for it.
3. For Cloud access, check hcloud version and the relevant command's --help; use the official CLI documentation for missing details or installation. Check hcloud and SSH only when that operation needs them; local preparation can continue without remote tools or credentials. A project's token reaches this machine only through /hetzner setup <project>, which the user runs; where the target has no context, say so, name that command, and leave the remote part undone. Name the context on every call and keep an ambient token from overriding it — env -u HCLOUD_TOKEN hcloud --context <project> location list verifies access — and never make a context active, since every call names its own. Verify resource ownership before mutation; a public catalog read establishes connectivity, not the intended project's identity.
4. Inspect current state, then perform only the requested operation using the relevant reference below. An uncertain write result requires reconciliation before another write. Finish with the actual verification result, including any unfinished work.

Read for the current task