Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add dryvist/claude-code-plugins --skill proxmox-cluster-opsgit clone --depth 1 https://github.com/dryvist/claude-code-pluginsWrote 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/dryvist/claude-code-plugins/proxmox-cluster-ops)<a href="https://agentmods.dev/skills/dryvist/claude-code-plugins/proxmox-cluster-ops"><img src="https://agentmods.dev/badge/skills/dryvist/claude-code-plugins/proxmox-cluster-ops/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/dryvist/claude-code-plugins/proxmox-cluster-ops"><img src="https://agentmods.dev/badge/skills/dryvist/claude-code-plugins/proxmox-cluster-ops.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.00047 | $0.00818 |
| Opus 5.5 | $0.00019 | $0.00327 |
| Sonnet 5.5 | $0.00009 | $0.00164 |
| Haiku 4.5 | $0.00005 | $0.00082 |
Grade A, and why
proxmox-cluster-ops scanned grade A with 0 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 14d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Proxmox VE cluster operations
Three recurring operator tasks on a Proxmox VE cluster, generalized from real bring-up and maintenance work. Every identifier is a placeholder — substitute your own node names, VMIDs, and domain.
Current state
For cluster, guest, service, GPU, and storage state, follow the
monitoring-first skill. This runbook covers Proxmox-specific change
procedures. Keep live guest configuration in configuration management and
guest shape changes in infrastructure-as-code; do not edit live guests by
hand.
Rolling updates that respect quorum
A cluster needs a strict majority of nodes online to stay quorate (e.g. 2 of 3, 3 of 5). Update one node at a time, and never take a second node down while the first is still rebooting or rejoining — that's the exact window where a second failure loses quorum and makes the cluster read-only.
- Confirm quorum is healthy in monitoring before touching anything; cite the query or panel used.
- Live-migrate or stop any guest on that node that can't tolerate the coming reboot.
- Update packages, reboot if the kernel changed, and verify through monitoring that the node rejoins quorate before moving to the next.
- Repeat, one node at a time. If any node in the cluster has a scheduled sleep/power-down window, update it last, and only outside that window, so it has time to fully rejoin before its next scheduled power-off.
Adding a node to the cluster
The shape that generalizes across a join, regardless of hardware:
- Install and configure networking first, matching the existing cluster's Proxmox major version — a joining node must match.
- Verify hardware before trusting it for workloads through monitoring, citing the query or panel for passthrough devices such as GPUs and NICs.
- Gate the join on DNS resolving, if the estate is DNS/FQDN-first:
dig +short <new-node>.<domain>must return the expected address before any converge step runs against that name. - Join via automation, verifying the peer's fingerprint — a join trusts
whichever cluster it's handed; confirm the existing cluster's fingerprint
before the new node commits, and let serial preflights (version match,
ring reachability, no pre-existing cluster config on the new node) run
before the actual
pvecm add. A half-joined node is worse than an unjoined one. - Confirm quorum arithmetic explicitly after the join using monitoring evidence — e.g. going from a 3-node to a 4-node cluster changes the number of nodes needed to stay quorate; re-derive the new "N/total, quorate?" table rather than assuming the old threshold still applies.
- Full converge, then mark the node commissioned in whatever tracks desired state (infra-as-code state file, inventory flag) — only after both the cluster and the configuration-management side agree the node is real.
- Verify storage before scheduling guests: pools import and are healthy, and the node reports its storage to the rest of the cluster.
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.
- 14d ago Changed · -26 lines · -19 tokens per session 1cf942109b3d
- 27d ago Changed · -23 tokens per session e2e9339bb505
- 1mo ago First seen · 97 lines · 89 tokens per session scan A c58196305011
proxmox-cluster-ops is a skill published in the GitHub repository dryvist/claude-code-plugins (3 stars, last pushed yesterday), licensed Apache-2.0. It adds 47 tokens to every session and 818 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other skills, from other repositories
agent-cloud-architect
Specialist subagent: Multi-cloud architecture, cost optimization, serverless vs containers, disaster recovery, and infrastructure design specialist. Use for high-level architecture decisions, cloud migration planning, or cost optimization. Trigger phrases: cloud, AWS, GCP, Azure, serverless, containers, Kubernetes…
kubernetes-ops
Kubernetes and Helm in practice: Deployments, Services, probes, resources, autoscaling, disruption budgets, NetworkPolicy, Pod Security Standards, Gateway API (ingress-nginx is retired), Helm 4 charts and releases, and kubectl without accidents. ECS and EKS specifics go to AWS's aws-containers skill, Flux to…
docker-kubernetes
Production Docker and Kubernetes patterns including multi-stage builds, minimal base images, non-root users, layer caching, docker-compose for development, K8s Deployments, Services, Ingress, ConfigMaps, Secrets, health checks, resource limits, HPA autoscaling, security contexts, and Helm chart basics. Use when…
infra-deploy
Cal.com self-hosted deployment to GCP Cloud Run with Supabase PostgreSQL. Docker Compose for local dev.
helm
Helm chart authoring, templating, and release management for Kubernetes: charts, values, templating functions, repositories, dependencies, and lifecycle operations.
cloud-run
Generate Google Cloud Run configs.