elizaOS is an open-source TypeScript framework and product stack for building and running autonomous AI agents. Developers use its runtime, application, command-line tool, cloud services, native bridges, and plugins to create agent-based software. The catalogue entries provide skills, commands, instructions, and rules for working with this monorepo and its agent ecosystem.
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 elizaOS/eliza --skill eliza-cloud-manage-domaingit clone --depth 1 https://github.com/elizaOS/elizaWrote 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/elizaos/eliza/eliza-cloud-manage-domain)<a href="https://agentmods.dev/skills/elizaos/eliza/eliza-cloud-manage-domain"><img src="https://agentmods.dev/badge/skills/elizaos/eliza/eliza-cloud-manage-domain/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/elizaos/eliza/eliza-cloud-manage-domain"><img src="https://agentmods.dev/badge/skills/elizaos/eliza/eliza-cloud-manage-domain.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Snyk pass
- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 31 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Tool Misuse · line 34 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
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.00125 | $0.01621 |
| Opus 5 | $0.00063 | $0.00811 |
| Sonnet 5 | $0.00025 | $0.00324 |
| Haiku 4.5 | $0.00013 | $0.00162 |
Grade A, and why
eliza-cloud-manage-domain 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 13d 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Manage your Eliza Cloud domains
Use this skill once the user already has at least one domain attached to one of their apps (registered via eliza-cloud-buy-domain or attached as external via the /domains POST). It covers everything after the buy: looking at what they own, editing DNS records on cloudflare-managed zones, refreshing live status, and detaching from an app.
It does NOT register new domains — that's eliza-cloud-buy-domain. It does not modify DNS on external (user-owned-elsewhere) domains — those records live at the user's existing DNS provider.
In a conversational agent running @elizaos/plugin-cloud-apps, the read path
("what domains does my app have", "is it verified") is already a first-class
action — LIST_APP_DOMAINS — so prefer that from chat. DNS record CRUD,
verify, sync, and detach remain SDK/skill territory below.
For live status checks, use the Cloud API plus direct HTTP/DNS/RDAP requests. Do not use web search snippets or registrar-search pages to decide whether a domain is bought, attached, or serving an app; those results can be stale.
What this skill can do
| User intent | Endpoint | Notes |
|---|---|---|
| "list my domains" / "what domains do I own" | GET /api/v1/domains |
org-wide across all their apps |
| "what domains does {app} have" | GET /api/v1/apps/{appId}/domains |
per-app; from chat prefer the LIST_APP_DOMAINS action |
| "did myapp.com get bought" / "is it active" | POST /api/v1/apps/{appId}/domains/status |
one attached domain's live registrar status |
| "show dns records for myapp.com" | GET /api/v1/apps/{appId}/domains/{domain}/dns |
cloudflare zones only |
| "add a CNAME pointing www.myapp.com to ..." | POST /api/v1/apps/{appId}/domains/{domain}/dns |
cloudflare zones only |
| "change the A record for myapp.com to ..." | PATCH /api/v1/apps/{appId}/domains/{domain}/dns/{recordId} |
get the recordId from the list call first |
| "delete that record" | DELETE /api/v1/apps/{appId}/domains/{domain}/dns/{recordId} |
irreversible; warn the user |
| "sync my domains" / "refresh domain status" | POST /api/v1/apps/{appId}/domains/sync |
refresh all attached cloudflare domains into managed_domains |
| "I added the verification record, check it" | POST /api/v1/apps/{appId}/domains/verify |
external domains: re-check the TXT challenge |
| "remove this domain from my app" | DELETE /api/v1/apps/{appId}/domains |
detach only; the cloudflare registration remains until expiry |
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 13d ago First seen · 110 lines · 125 tokens per session scan A e36237b83530
eliza-cloud-manage-domain is a skill published in the GitHub repository elizaOS/eliza (19,326 stars, last pushed today), licensed MIT. It adds 125 tokens to every session and 1,621 once invoked, about $0.0006 per session on Opus 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-08-30.
Other skills, from other repositories
vercel-deploy
Deploy applications and websites to Vercel. Use this skill when the user requests deployment actions such as "Deploy my app", "Deploy this to production", "Create a preview deployment", "Deploy and give me the link", or "Push this live". No authentication required - returns preview URL and claimable deployment link.
huggingface-jobs
Plan, launch, inspect, monitor, and cancel authenticated Hugging Face Jobs for CPU, GPU, TPU, batch, inference, and data workloads.
cloudflare-temporary-deploy
Deploy a temporary Cloudflare Workers preview with Wrangler for short-lived web app smoke tests.
aws-cost-optimizer
Analyze and optimize AWS costs with recommendations for Reserved Instances, right-sizing, and resource cleanup. Use when reducing AWS spending, analyzing costs, or optimizing cloud infrastructure expenses.
stack-designer
Designs CloudFormation stack structure, nested stacks, and resource organization. Use when designing CloudFormation infrastructure, organizing resources into stacks, or planning nested stack hierarchies.
template-validator
Validates CloudFormation templates for syntax, security, and best practices. Use when validating CloudFormation templates, checking for security issues, or ensuring compliance with best practices.