hermuz
Operate the live Hermuz deployment via CLI for scheduling, session management, and deployment triggers.
Install
mkdir -p .claude/skills/hermuz && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/19065" && unzip -o skill.zip -d .claude/skills/hermuz && rm skill.zipInstalls to .claude/skills/hermuz
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Operate the live Hermuz deployment — list/inspect/schedule games, campaigns and their sessions; set a repeating campaign's recurrence (weekday/time/timezone, incl. past-anchored biweekly series); generate/cancel sessions; trigger Render deploys; read runtime logs; and inspect the Discord guild's roles/channels. Use whenever the task is running or changing the deployed Hermuz app (not its source code).Key capabilities
- →List and inspect games, campaigns, and sessions
- →Schedule repeating campaigns with specific recurrence patterns
- →Generate or cancel individual sessions within a campaign
- →Trigger Render deploys for the Hermuz web service
- →Read runtime logs from the Hermuz deployment
- →Inspect Discord guild roles and channels
How it works
This skill operates the live Hermuz deployment using a bundled CLI, allowing management of games, campaigns, and sessions. It automates authentication and interacts with the Render web service.
Inputs & outputs
When to use hermuz
- →Scheduling game campaigns
- →Generating session series
- →Triggering service deployments
- →Inspecting runtime logs
About this skill
Hermuz operator
Hermuz runs as one Render web service (Discord bot + JSON API over SQLite) with a
Netlify web console. This skill drives the live deployment through a bundled
CLI so you don't hand-roll curl + admin JWTs.
The CLI
Run from the repo root:
bun scripts/hermuz.ts <command> [args] # or: ./scripts/hermuz.ts <command>
Auth is automatic — the CLI reads the Render API key from 1Password
(op-agent secret op://claude-agent/render/credential), pulls JWT_SECRET /
DISCORD_TOKEN / GUILD_ID from the Render service's env, and mints a
short-lived admin token. Nothing to configure. (If op-agent can't read the
key, ask the user to store it at op://claude-agent/render/credential.)
Commands
| Command | What it does |
|---|---|
games | list games (kind default, max sessions, id) |
campaigns | list campaigns (kind, active session count, anchor, id) |
campaign <id> | show a campaign JSON + its sessions |
campaign <id> schedule … | make REPEATING + set recurrence, then generate sessions |
campaign <id> generate | materialize / extend the session series |
campaign <id> cancel <sessionNo> | cancel one session |
campaign <id> announce | (re)post the campaign to the scheduling channel (touches Discord) |
sessions <id> | list a campaign's sessions |
deploy [--wait] | trigger a Render deploy of main, optionally poll to live |
logs [n] | last n runtime log lines |
discord roles / discord channels | list the guild's roles / channels (to find ids) |
whoami | verify the auth chain |
Scheduling a repeating campaign
Either give an explicit ISO anchor, or let the CLI compute it (DST-aware):
# "started this past Monday, 8:30pm ET, every other week"
bun scripts/hermuz.ts campaign <id> schedule \
--weekday mon --time 20:30 --tz ET --start past --every 2
# "starts next Sunday, 11am ET, weekly, capped at 6 sessions"
bun scripts/hermuz.ts campaign <id> schedule \
--weekday sun --time 11:00 --tz ET --start next --every 1 --max 6
# explicit anchor
bun scripts/hermuz.ts campaign <id> schedule --anchor 2026-07-19T15:00:00Z --every 2
--start is past (most recent occurrence, for series already running),
next (next occurrence), or a YYYY-MM-DD. --tz accepts ET/CT/MT/PT/UTC
or any IANA zone. The anchor is the first session's datetime and is the
source of truth for the cadence.
Things to know
- Sessions are calendar/DB entries only —
schedule/generatedo not create Discord roles/channels/events.announceand campaign creation (via the web console / bot) are what touch Discord. - The API is admin-gated; the CLI mints an admin token, so all commands work.
- Render auto-deploy isn't wired, so after merging a PR to
main, runbun scripts/hermuz.ts deploy --waitto ship it (migrations run on boot). - Overrides via env if the service ever moves:
HERMUZ_RENDER_SERVICE,HERMUZ_RENDER_OWNER,HERMUZ_API_ORIGIN. - To find a role/channel id for a campaign, use
discord roles/discord channels.
When not to use it
- →When the task involves modifying the Hermuz source code
- →When creating Discord roles, channels, or events directly through the skill
Limitations
- →Sessions are calendar/DB entries only; `schedule`/`generate` do not create Discord roles/channels/events
- →Render auto-deploy isn't wired, requiring manual `deploy` command after merging to `main`
- →Authentication relies on `op-agent` reading the Render API key from 1Password
How it compares
This workflow uses a bundled CLI for Hermuz operations, automating authentication and direct interaction with the live deployment, unlike manually crafting `curl` commands with admin JWTs.
Compared to similar skills
hermuz side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| hermuz (this skill) | 0 | 12d | Review | Intermediate |
| cloudflare-manager | 25 | 9mo | Review | Intermediate |
| railway-cli-management | 9 | 8mo | Review | Intermediate |
| azure-functions | 10 | 4mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
cloudflare-manager
qdhenry
Comprehensive Cloudflare account management for deploying Workers, KV Storage, R2, Pages, DNS, and Routes. Use when deploying cloudflare services, managing worker containers, configuring KV/R2 storage, or setting up DNS/routing. Requires CLOUDFLARE_API_KEY in .env and Bun runtime with dependencies installed.
railway-cli-management
CaptainCrouton89
Deploy, manage services, view logs, and configure Railway infrastructure. Use when deploying to Railway, managing environment variables, viewing deployment logs, scaling services, or managing volumes.
azure-functions
aj-geddes
Create serverless functions on Azure with triggers, bindings, authentication, and monitoring. Use for event-driven computing without managing infrastructure.
nuxthub-migration
onmax
Use when migrating NuxtHub projects or when user mentions NuxtHub Admin sunset, GitHub Actions deployment removal, self-hosting NuxtHub, or upgrading to v1/nightly. Covers v0.9.X self-hosting (stable) and v1/nightly multi-cloud (experimental, database/blob not ready).
deployment-pipeline-design
wshobson
Design multi-stage CI/CD pipelines with approval gates, security checks, and deployment orchestration. Use when architecting deployment workflows, setting up continuous delivery, or implementing GitOps practices.
terraform-module-library
wshobson
Build reusable Terraform modules for AWS, Azure, and GCP infrastructure following infrastructure-as-code best practices. Use when creating infrastructure modules, standardizing cloud provisioning, or implementing reusable IaC components.