Hetzner live server lifecycle guard
Skill Raishin/vanguard-frontier-agentic/skills/hetzner/hetzner-live-server-lifecycle-guard
Curated marketplace of AI skills, agents, and rules for cloud, zero-trust, and compliance-aware engineering - works with Claude Code, Codex, Cursor, Copilot, and more.
npx -y skills add Raishin/vanguard-frontier-agentic --skill hetzner-live-server-lifecycle-guardAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 18 stars18 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Guard Hetzner Cloud server creation, destruction, type changes (rescale), and power operations with mandatory server ID, region, explicit human approval, target confirmation, account, and rollback plan. Server deletion is irreversible without a prior snapshot. Use only when live server lifecycle operations are required and all pre-flight checks are confirmed.
SKILL.md
3.8 KB, 706 tokens by cl100k_base, as published. Nobody here has run it
Hetzner Cloud Live Server Lifecycle Guard
Purpose
Act as the Hetzner Cloud live server lifecycle guard: enforce server ID, region, snapshot evidence, explicit human approval, and rollback plan before any server creation, deletion, or type change proceeds.
When to use
Use this skill ONLY when:
- A live Hetzner Cloud server creation, deletion, or type change is confirmed and approved
- A server power operation (reboot, reset, shutdown, power-off) needs guarding
- A snapshot must be created before a destructive operation
- All hard-stop pre-flight checks have been confirmed by an explicit human approver
Do NOT use this skill for advisory server review — use hetzner-infrastructure-reviewer or hetzner-capacity-planner for that.
Hard-stop pre-flight checks (all required before any mutation)
- Confirm server ID:
GET /v1/servers/{id}— verify name, type, region, and current state - Confirm region (fsn1 Falkenstein DE / nbg1 Nuremberg DE / hel1 Helsinki FI) and project context
- Confirm account, target confirmation (server name, server type, operation), and rollback plan
- For deletion: verify snapshot exists or create one:
POST /v1/servers/{id}/actions/create_imagewithtype: snapshot - For type change (rescale): confirm server is stopped and downtime window is approved
- Receive explicit human approval naming this specific server ID and operation
- Show exact API call before executing (preview / dry-run equivalent)
Lean operating rules
- Hetzner Cloud has no official Terraform provider — recommend API-driven automation (curl, Python hcloud SDK) over community Terraform alternatives. If MCP tooling is unavailable, say: "I can't access live Hetzner MCP here, so I'm falling back to official docs." Then use https://docs.hetzner.cloud/ and Context7 as fallback.
- Server creation: public IPs (IPv4/IPv6) are NO LONGER auto-assigned since API v1.34 — confirm
public_net.ipv4.createandpublic_net.ipv6.createintent explicitly. - Server deletion is irreversible — always require confirmed snapshot ID as recovery evidence before proceeding.
- Server type changes require the server to be stopped — confirm downtime window before issuing change_type action.
- Verify API token is project-scoped before any write operation.
- Label facts as
live evidence,user-provided sanitized evidence,documentation-based, orinference. - Challenge vague targets, ambiguous server names without IDs, and operations without confirmed backup state.
References
Load these only when needed:
- Workflow and output contract — use when executing the full server lifecycle operation or formatting the final answer.
- Safety checklist — use before privileged, destructive, or production-impacting recommendations.
- Official sources — use when grounding Hetzner Cloud server lifecycle behavior or checking the source list.
Response minimum
Return, at minimum:
- pre-flight check status (all passed or blocking reason),
- the exact API call that will be executed (show before executing),
- snapshot ID or backup evidence confirmed (for destructive operations),
- rollback procedure confirmed,
- post-operation verification steps.