What makes xCloud Agent Skills notable?

1.1K downloads. Trust evidence available

How should xCloud Agent Skills be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

xCloud Agent Skills

Deploy Git repositories, diagnose errors and slow sites, then manage servers, sites, SSL, backups, billing and teams. Nine capability skills; MCP-first with a read-only REST fallback, deployment previews and explicit approval for destructive or paid actions.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

4.4.2

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 4.4.2release · observed Sep 24, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s172w5rqenpwn4qb4g5n563hx9845890:xcloud

Install using `clawhub skill install s172w5rqenpwn4qb4g5n563hx9845890:xcloud` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/asif2bd/xcloud before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-asif2bd-xcloud/snapshot"

Documentation

CLAWHUB

160,000 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

plugins/xcloud/skills/account/SKILL.md

---
name: account
description: xCloud account, teams, and org-level reads — current user, the teams this connection may act on (multi-team), incident alerts (list, read, mark as read), API token listing and revocation, connected Git providers and their repositories, Cloudflare integrations, WordPress blueprints, and API health. Use for "who am I", "which teams can you see", "switch to the Acme team", "any open alerts?", "mark resolved alerts as read", token management, or checking integrations. NOT server or site operations (see xcloud:servers / xcloud:sites), NOT billing (see xcloud:billing).
---

# xCloud Account

> **Packaged REST boundary (v4.4.2):** `xcloud.sh` enforces GET-only requests with no body and has no write override. Non-GET examples below describe upstream API operations, not executable commands for this fallback. For mutations, use the corresponding connected xCloud MCP tool only after the required concrete user approval and server confirmation. If that tool/confirmation is unavailable, stop and direct the user to the dashboard; do not bypass this boundary with direct curl, SDKs, alternate scripts or by editing the wrapper. Configure REST credentials with read-only scopes.


Identity and org-level endpoints. For auth, base URL, and response conventions
read the shared layer first:

- `${CLAUDE_PLUGIN_ROOT}/reference/auth.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/conventions.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/mcp.md` — **prefer the MCP tools when
  connected**: `user_show`, `teams_index`, `alerts_index`, `alerts_show`,
  `alerts_read`, `integrations_git_index`, `integrations_git_repositories`,
  `blueprints_index`, `integrations_cloudflare_index`.
  **Exception:** `/health` and API-token list/revoke are REST-only — the MCP
  never exposes token management; always use `$XC` for those.

```bash
XC="${CLAUDE_PLUGIN_ROOT}/scripts/xcloud.sh"
```

## Response format

Brand every user-facing reply (see `reference/conventions.md` →
**Response format**): open with `☁️ **xCloud · Account**`, give the trimmed
result, and close with a `_via xcloud:account_` line.

Narrate each call (see **Progress narration**): before every `$XC` call print one
line of what xCloud is doing, e.g. `☁️ xCloud is fetching your account…`; the
first call of a task opens with `☁️ xCloud is starting a session…`. **Every
progress line and every action sentence must start with `xCloud` as the actor —
never a bare verb like "Fetching…" or "Checking…". Say `xCloud is fetching…`.**

On the **first** xcloud reply in a conversation, lead with the xCloud startup
banner (see `reference/conventions.md` → **Startup banner**) in a fenced code
block — once per conversation.

## What this skill owns

| Operation | Method + path | Scope |
|---|---|---|
| API health | `GET /health` | none |
| Current user | `GET /user` | token |
| Teams this token may act on | `GET /teams` | token |
| Incident alerts (filter `unread`, `severity`, `category`) | `GET /alerts` | `read:servers` or `rea

plugins/xcloud/skills/billing/SKILL.md

---
name: billing
description: xCloud billing, pricing and paid add-ons — current plan, billing overview, invoices, bills, subscriptions, purchased packages and products, payment methods on file, paying an outstanding invoice, public hosting prices and app requirements, and buying or managing email add-ons (branded mailboxes with DNS verification and IMAP/POP/SMTP settings, and mail-delivery SMTP subscriptions). Use for "what plan am I on", "show last month's invoice", "how much would a server for X cost", "pay invoice 1234", "buy a mailbox for example.com", "verify the mailbox DNS", or "give me the SMTP settings". NOT creating a server (see xcloud:servers), NOT deploying apps (see xcloud:deploy).
---

# xCloud Billing

> **Packaged REST boundary (v4.4.2):** `xcloud.sh` enforces GET-only requests with no body and has no write override. Non-GET examples below describe upstream API operations, not executable commands for this fallback. For mutations, use the corresponding connected xCloud MCP tool only after the required concrete user approval and server confirmation. If that tool/confirmation is unavailable, stop and direct the user to the dashboard; do not bypass this boundary with direct curl, SDKs, alternate scripts or by editing the wrapper. Configure REST credentials with read-only scopes.

Owns money and paid add-ons. Read the shared layer first:

- `${CLAUDE_PLUGIN_ROOT}/reference/auth.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/conventions.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/mcp.md` — **prefer the MCP tools when
connected**: `billing_*`, `catalog_pricing_index`, `catalog_apps_index`,
`payments_pay`, `addons_mailbox_*`, `addons_mail-delivery_*`; the `$XC` calls
below are the REST fallback.

```bash
XC="${CLAUDE_PLUGIN_ROOT}/scripts/xcloud.sh"
```

Scopes: `read:billing` for billing reads, `read:addons` / `write:addons` for
add-ons and invoice payment. Purchases and payments also need the team
permission (`addon:create`, `billing:create`).

## Response format

Brand every user-facing reply (see `reference/conventions.md` →
**Response format**): open with `☁️ **xCloud · Billing** — <team or item>`, give
the trimmed result, and close with a `_via xcloud:billing_` line.

Narrate each call (see **Progress narration**): before every call print one line
of what xCloud is doing, e.g. `☁️ xCloud is fetching your latest invoice…`; the
first call of a task opens with `☁️ xCloud is starting a session…`. **Every
progress line and every action sentence must start with `xCloud` as the actor —
never a bare verb like "Fetching…" or "Buying…". Say `xCloud is fetching…`.**

On the **first** xcloud reply in a conversation, lead with the xCloud startup
banner (see `reference/conventions.md` → **Startup banner**) in a fenced code
block — once per conversation.

## Sub-resources (load on demand)

| Sub-resource | Reference file |
|---|---|
| Mailboxes and mail delivery (plans, purchase, DNS, IMAP/POP/SMTP) | `reference/addons.md` |

## Core endpoints

| Oper

plugins/xcloud/skills/deploy/SKILL.md

---
name: deploy
description: Deploy anything to xCloud from one plain request — a GitHub, GitLab or Bitbucket URL (or owner/repo), a Docker Compose or Dockerfile app, a Git-backed staging environment from a branch, a one-click app (Ghost, Uptime Kuma, Vaultwarden…), or a new WordPress site — end to end, with repository detection, a dry-run preview, one approval, provisioning, polling, a live check, and automatic diagnosis and retry when a deploy fails. Use whenever the user pastes a repository URL, says deploy / ship / host / launch / put this app online, asks for a staging copy of a Git site, asks to install a one-click app, asks to ship the latest commit, or says a deploy failed. NOT day-2 site settings (see xcloud:sites), NOT buying a server (see xcloud:servers).
---

# xCloud Deploy

> **Packaged REST boundary (v4.4.2):** `xcloud.sh` enforces GET-only requests with no body and has no write override. Non-GET examples below describe upstream API operations, not executable commands for this fallback. For mutations, use the corresponding connected xCloud MCP tool only after the required concrete user approval and server confirmation. If that tool/confirmation is unavailable, stop and direct the user to the dashboard; do not bypass this boundary with direct curl, SDKs, alternate scripts or by editing the wrapper. Configure REST credentials with read-only scopes.


Owns getting code and apps **live** on xCloud, and getting failed deploys
**back on track**. Read the shared layer first for auth, conventions, and the
MCP rules:

- `${CLAUDE_PLUGIN_ROOT}/reference/auth.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/conventions.md` — including **Proactive mode**
- `${CLAUDE_PLUGIN_ROOT}/reference/mcp.md` — **prefer the MCP tools when
  connected** (`xcloud_agent_search`, `git_detect`, `git_compose-scan`,
  `servers_sites_git_auto`, `sites_status`, `sites_deploy-diagnosis`,
  `sites_provision-retry`, `oneclickApps_*`, `sites_stagingSites_create`); the
  `$XC` calls in the reference files are the REST fallback.

```bash
XC="${CLAUDE_PLUGIN_ROOT}/scripts/xcloud.sh"
```

Scopes: `read:servers` + `read:sites` to look, `write:servers` to create a site
on a server, `write:sites` for retries, redeploys, staging and one-click
lifecycle.

## Response format

Brand every user-facing reply (see `reference/conventions.md` →
**Response format**): open with `☁️ **xCloud · Deploy** — <repo, app or site>`,
give the trimmed result, and close with a `_via xcloud:deploy_` line.

Narrate each call (see **Progress narration**): before every call print one line
of what xCloud is doing, e.g. `☁️ xCloud is analysing \`acme/shop\`…`; the first
call of a task opens with `☁️ xCloud is starting a session…`. **Every progress
line and every action sentence must start with `xCloud` as the actor — never a
bare verb like "Deploying…" or "Polling…". Say `xCloud is deploying…`.**

On the **first** xcloud reply in a conversation, lead with the xCloud startup
banner (see `reference/conventions.md`

plugins/xcloud/skills/performance/SKILL.md

---
name: performance
description: Diagnose a slow xCloud site from data — site and server CPU/RAM/disk samples and their history, which cache layers are on (page cache, Redis / Object Cache Pro object cache, Cloudflare edge cache), the latest PageSpeed run, access-log traffic spikes and bots, service health, and the site's PHP version — then name the cause and hand off the switches that are dashboard-only (enabling a cache layer, a per-site PHP version). Use whenever the user says a site is slow, loads slowly, has a high TTFB, asks "is Redis on", "why is my site slow", "speed up my site" or asks about caching for a site. A site that errors (500/502) → xcloud:troubleshoot; running or comparing PageSpeed scans on their own → xcloud:wordpress; purging a cache on request → xcloud:sites; server PHP installs → xcloud:servers.
---

# xCloud Performance

> **Packaged REST boundary (v4.4.2):** `xcloud.sh` enforces GET-only requests with no body and has no write override. Non-GET examples below describe upstream API operations, not executable commands for this fallback. For mutations, use the corresponding connected xCloud MCP tool only after the required concrete user approval and server confirmation. If that tool/confirmation is unavailable, stop and direct the user to the dashboard; do not bypass this boundary with direct curl, SDKs, alternate scripts or by editing the wrapper. Configure REST credentials with read-only scopes.


Owns the **"my site is slow"** investigation: measure, name the cause, and hand
off what the API cannot switch. Read the shared layer first:

- `${CLAUDE_PLUGIN_ROOT}/reference/auth.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/conventions.md` — including **Proactive
  mode** and **Untrusted output**
- `${CLAUDE_PLUGIN_ROOT}/reference/mcp.md` — **prefer the MCP tools when
  connected** (`xcloud_agent_search`, `sites_monitoring`,
  `sites_monitoring_history`, `servers_monitoring`,
  `servers_monitoringHistory`, `sites_cacheSettings`,
  `sites_pagespeed_latest`, `sites_access-logs`, `servers_services`,
  `sites_wordpress_status`); the `$XC` calls below are the REST fallback.
- `${CLAUDE_PLUGIN_ROOT}/reference/capability-map.md` — what the API cannot
  do, and where it lives in the dashboard.

```bash
XC="${CLAUDE_PLUGIN_ROOT}/scripts/xcloud.sh"
```

Scopes: `read:sites` + `read:servers` for every read; `write:sites` for a
PageSpeed scan or a cache purge; `write:servers` for server PHP changes. Team
permissions: site monitoring needs `site:manage-monitoring`; WordPress status
and PageSpeed need `site:manage-update`. A `403` there means the token's team
role lacks it — a different sentence from "xCloud cannot show you that".

## Response format

Brand every user-facing reply (see `reference/conventions.md` →
**Response format**): open with `☁️ **xCloud · Performance** — <site domain>`,
give the finding with the numbers behind it, and close with a
`_via xcloud:performance_` line.

Narrate each call (see **Progress narration**): before ever

plugins/xcloud/skills/servers/SKILL.md

---
name: servers
description: Manage xCloud servers — list/inspect servers, buy a new xCloud-managed server (plans, prices, regions, provisioning progress), monitoring, services (install, enable, restart, disable), Node.js and PHP versions, verified reboots, tasks, snapshots, sudo users, server cron jobs, firewall rules, fail2ban, IP whitelisting, and checking whether a domain's DNS points at a server. Use for any server-level infrastructure, capacity, or server security request. Deploying apps and creating sites on a server → xcloud:deploy. NOT site-level config (see xcloud:sites), NOT SSL certs (see xcloud:ssl), NOT WordPress app management (see xcloud:wordpress).
---

# xCloud Servers

> **Packaged REST boundary (v4.4.2):** `xcloud.sh` enforces GET-only requests with no body and has no write override. Non-GET examples below describe upstream API operations, not executable commands for this fallback. For mutations, use the corresponding connected xCloud MCP tool only after the required concrete user approval and server confirmation. If that tool/confirmation is unavailable, stop and direct the user to the dashboard; do not bypass this boundary with direct curl, SDKs, alternate scripts or by editing the wrapper. Configure REST credentials with read-only scopes.


Owns server infrastructure and server-level security. Read the shared layer
first for auth, base URL, envelope, pagination, and rate limits:

- `${CLAUDE_PLUGIN_ROOT}/reference/auth.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/conventions.md`
- `${CLAUDE_PLUGIN_ROOT}/reference/mcp.md` — **prefer `mcp__xcloud__servers_*`
  tools when connected** (e.g. `servers_index`, `servers_show`,
  `servers_plans`, `servers_store`, `servers_reboots_store`,
  `servers_services_install`, `servers_dns_check`); the `$XC` calls below are
  the REST fallback.

```bash
XC="${CLAUDE_PLUGIN_ROOT}/scripts/xcloud.sh"
```

Scopes: reads need `read:servers`, writes need `write:servers`.

## Response format

Brand every user-facing reply (see `reference/conventions.md` →
**Response format**): open with `☁️ **xCloud · Servers** — <server>`, give the
trimmed result, and close with a `_via xcloud:servers_` line.

Narrate each call (see **Progress narration**): before every `$XC` call print one
line of what xCloud is doing, e.g. `☁️ xCloud is fetching server \`<name>\`…`; the
first call of a task opens with `☁️ xCloud is starting a session…`. **Every
progress line and every action sentence must start with `xCloud` as the actor —
never a bare verb like "Creating…" or "Provisioning…". Say `xCloud is creating…`.**

On the **first** xcloud reply in a conversation, lead with the xCloud startup
banner (see `reference/conventions.md` → **Startup banner**) in a fenced code
block — once per conversation.

## Sub-resources (load on demand)

Big domain — detailed per-sub-resource guidance lives in `reference/`:

| Sub-resource | Reference file |
|---|---|
| Buying a server: plans, prices, regions, provisioning progress | `reference/p

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.