What makes queue-aiops notable?

1.4K downloads. Trust evidence available

How should queue-aiops 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

queue-aiops

Use this skill whenever the user needs to operate a redis cache or a rabbitmq broker — a one-shot overview, redis memory posture (used vs maxmemory, eviction policy, fragmentation), SLOWLOG and a SCAN-budgeted big-key sample (never KEYS *), connected clients, CONFIG get/set, rabbitmq queues with backlog depth, connections/channels, policies and node watermark alarms, four flagship RCAs (redis memory pressure, redis latency/slowlog, rabbitmq queue backlog, connection churn on both platforms), and governed writes (set a config parameter, kill a client, declare/purge/delete a queue, set/delete a policy). Always use this skill for "redis", "rabbitmq", "maxmemory", "eviction", "evicted keys", "big key", "slowlog", "why is my cache slow", "queue backlog", "messages piling up", "no consumers", "unacked messages", "memory watermark", "connection churn", "purge a queue", "rabbitmq policy" when the context is a redis or rabbitmq deployment. Do NOT use when the target is something other than a redis/rabbitmq broker (a hypervisor, storage appliance, backup product, container-orchestration cluster, database server, monitoring stack, or OT/industrial equipment) — route those to the appropriate other AIops-tools skill. Managed cloud queue services and other broker products are out of scope. Governed broker operations with a built-in governance harness (audit, policy, token budget, undo, risk-tiers). Behaviour is validated by a mock-based test suite; see docs/VERIFICATION.md for the live-verification checklist.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.4k

Updated

Oct 10, 2026

Version

0.9.4

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.4K downloads reported by the source. Last updated 10/10/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 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.4K downloadsadoption · observed Oct 10, 2026
Latest release: 0.9.4release · observed Sep 16, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:queue-aiops

Install using `clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:queue-aiops` 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/zw008/queue-aiops before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/snapshot"

Documentation

CLAWHUB

149,905 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: queue-aiops
slug: queue-aiops
displayName: "Queue AIops"
summary: "Governed redis + rabbitmq ops: memory/latency/backlog/churn RCA, policies. 28 tools."
license: MIT
homepage: https://github.com/AIops-tools/Queue-AIops
tags: [aiops, mcp, governance, queue]
description: >
  Use this skill whenever the user needs to operate a redis cache or a rabbitmq broker — a one-shot overview, redis memory posture (used vs maxmemory, eviction policy, fragmentation), SLOWLOG and a SCAN-budgeted big-key sample (never KEYS *), connected clients, CONFIG get/set, rabbitmq queues with backlog depth, connections/channels, policies and node watermark alarms, four flagship RCAs (redis memory pressure, redis latency/slowlog, rabbitmq queue backlog, connection churn on both platforms), and governed writes (set a config parameter, kill a client, declare/purge/delete a queue, set/delete a policy).
  Always use this skill for "redis", "rabbitmq", "maxmemory", "eviction", "evicted keys", "big key", "slowlog", "why is my cache slow", "queue backlog", "messages piling up", "no consumers", "unacked messages", "memory watermark", "connection churn", "purge a queue", "rabbitmq policy" when the context is a redis or rabbitmq deployment.
  Do NOT use when the target is something other than a redis/rabbitmq broker (a hypervisor, storage appliance, backup product, container-orchestration cluster, database server, monitoring stack, or OT/industrial equipment) — route those to the appropriate other AIops-tools skill. Managed cloud queue services and other broker products are out of scope.
  Governed broker operations with a built-in governance harness (audit, policy, token budget, undo, risk-tiers). Behaviour is validated by a mock-based test suite; see docs/VERIFICATION.md for the live-verification checklist.
installer:
  kind: uv
  package: queue-aiops
argument-hint: "[a queue/key/client id, or describe your cache/broker task]"
allowed-tools:
  - Bash
metadata: {"openclaw":{"requires":{"anyBins":["queue-aiops","uvx"]},"optional":{"env":["QUEUE_AIOPS_CONFIG","QUEUE_AIOPS_MASTER_PASSWORD"]},"homepage":"https://github.com/AIops-tools/Queue-AIops","emoji":"📬","os":["macos","linux"]}}
compatibility: >
  Standalone, self-governed broker operations across redis (RESP wire protocol via the redis Python client; password optional — auth-less lab instances are supported — TLS optional) and rabbitmq (management HTTP API /api/..., HTTP Basic auth with a monitoring/management-tagged user). Each target in the config names its own platform, and a name-keyed platform registry selects the protocol shape, so one config can span a mixed estate. The governance harness (audit, policy, token/runaway budget, undo, risk-tiers) is bundled in the package — no external skill-family dependency.
  All write operations are audited to a local SQLite DB under ~/.queue-aiops/ (relocatable via QUEUE_AIOPS_HOME).
  Credentials: the redis password (optional) or the rabbitmq management password is stored ENCRYP

_meta.json

{
  "ownerId": "kn7b067awq2s97bn3d7p5qfhw5827pxc",
  "slug": "queue-aiops",
  "version": "0.9.4",
  "publishedAt": 1789562000585
}

references/agent-guardrails.md

# Agent guardrails — running queue-aiops with a smaller / local model

If you drive these tools with a local model (Llama, Qwen, Mistral … via Goose,
Ollama, LM Studio, or any OpenAI-compatible runtime), you will get noticeably
better results with a short system prompt. This page gives you one, and — more
importantly — tells you which guardrails you **no longer need to write**, because
the tool now enforces them itself.

The distinction matters. A guardrail in a prompt is a request. A guardrail in the
harness is a guarantee. Anything below that we could move into the harness, we did.

## Authorization is not this tool's job — decide it where it belongs

Whether a write should happen is your decision, or the account's. The tool does
not gate it — there is no read-only switch and no approval prompt to configure.
The two right places to control read vs write:

- **The account you connect with.** Give the Redis connection an ACL user
restricted to read commands, or the RabbitMQ management user only the
`monitoring` tag (no `management`/`policymaker`). A write then fails at the
broker, which is the only place the permission actually lives — a revoked
permission cannot be argued around by a model, but a skill-side flag can.
- **Your agent's system prompt.** If you want an observe-only session, tell the
model not to call the write tools (they are clearly tagged `[WRITE]`).

What the tool *does* guarantee is that you can always see what happened:

## What the tool enforces — do not waste prompt budget on these

| You might be tempted to prompt | Why you don't need to |
|---|---|
| "Don't invent a value when a field is missing" | RabbitMQ omits `idle_since` for an active queue; a Redis primary reports no `master_link_status`; an unnamed client has no name. Those come back as `null`, never as `""`. |
| "Tell me if the output was cut off" | `redis_slowlog`, `redis_clients`, `redis_big_keys`, `list_queues`, `list_connections`, `list_channels` and `list_policies` all return `{"<items>": [...], "returned": N, "limit": L, "truncated": true/false}`. Truncation is measured — one extra entry is requested from Redis — not guessed from a length coincidence. |
| "Make it show the number it judged on" | Every finding from `rabbitmq_queue_backlog_rca`, `redis_memory_pressure_rca`, `redis_latency_rca` and `connection_churn_analysis` carries the measured value it was based on under `evidence`, so a claim can always be checked against a number rather than taken on the model's word. |
| "Don't run KEYS * on production" | `redis_big_keys` uses SCAN under a hard key budget and sizes only an evenly-spaced subset with MEMORY USAGE. There is no code path that can issue `KEYS *`. `coveragePct` reports how partial the walk was. |
| "Confirm before anything destructive" | `delete_queue` and `purge_queue` require a `--dry-run`-able preview plus double confirmation at the CLI. |
| "Log what you did" | Every governed call is audited to `~/.queue-aiops/audit.db` regardless o

references/capabilities.md

# queue-aiops — full capability reference

## Platforms

| Platform | Protocol | Auth | Default port |
|----------|----------|------|:---:|
| `redis` | RESP wire protocol via the `redis` Python client (30s socket timeouts, `decode_responses=True`) | `AUTH` password — **optional** (auth-less lab instances supported); TLS optional (`use_tls`, `verify_ssl`) | 6379 |
| `rabbitmq` | Management HTTP API (`/api/...`) via httpx (30s timeout) | HTTP Basic — management user (needs the `monitoring` or `management` tag) | 15672 |

A name-keyed platform registry (`queue_aiops/platform.py`) maps each target's
`platform` field to its protocol shape. New broker families are additive
registry entries — the ops/CLI/MCP layers don't change.

### redis command surface (typed allow-list — no generic passthrough)

`PING`, `INFO [section]`, `SLOWLOG GET`, `CLIENT LIST`, `CLIENT KILL ID/ADDR`,
`CONFIG GET`, `CONFIG SET`, `MEMORY STATS`, `MEMORY USAGE`, `SCAN`
(budgeted), `DBSIZE`. Never `KEYS *`.

Big-key sampling budget (named constants in `ops/redis_reads.py`):
`SCAN_BUDGET_KEYS=10000`, `SCAN_PAGE=500`, `MEMORY_SAMPLE_MAX=200`,
`TOP_KEYS=20`. `coveragePct` reports how partial the walk was.

### rabbitmq management-API paths (all interpolated segments percent-encoded)

`/api/overview`, `/api/nodes`, `/api/whoami`, `/api/queues[/{vhost}[/{name}]]`,
`/api/queues/{vhost}/{name}/contents` (purge), `/api/connections`,
`/api/channels`, `/api/consumers`, `/api/policies[/{vhost}[/{name}]]`.
The default vhost `/` is sent as `%2F`.

## Tools (28)

### Overview (1)

| Tool | Returns |
|------|---------|
| `queue_overview(target?)` | Platform-dispatched one-shot: redis → version/role, memory posture, clients, ops/sec, hit rate, key count; rabbitmq → version, queue/message totals, connections/channels/consumers, rates, node alarms. Partial failures degrade into an `errors` list. |

### redis reads (7)

| Tool | Returns |
|------|---------|
| `redis_server_info` | version, mode, role, uptime, clients, blocked clients, ops/sec, hit rate |
| `redis_memory_stats` | usedBytes vs maxmemoryBytes (+ usedPctOfMax), maxmemory policy, fragmentation ratio, RSS/peak, key count |
| `redis_clients` | clients (bounded 200) + grouped `bySource` (ip without port), busiest first |
| `redis_slowlog(count?)` | slowlog entries, slowest first (durationUs, command folded to one string) |
| `redis_config_get(pattern?)` | CONFIG GET glob → sorted parameter map |
| `redis_keyspace` | per-db keys/expires/avgTtl + expiry coverage % |
| `redis_big_keys(top?)` | SCAN-budgeted big-key sample, largest first, with budget + coveragePct |

### rabbitmq reads (7)

| Tool | Returns |
|------|---------|
| `rabbitmq_overview` | version, cluster, queue/message totals, object counts, publish/deliver/ack rates, connection/channel churn rates |
| `list_queues(vhost?)` | queues deepest-backlog first: messages/ready/unacked, consumers, rates, memory |
| `queue_detail(vhost, name)` | one queue: counts, rates, durable/auto_delet

references/cli-reference.md

# queue-aiops — CLI reference

All read commands print JSON. All write commands support `--dry-run` and
double-confirm before executing through the governed MCP twins (audited).
`--target/-t <name>` selects a target from config; omitted = the first target.

## Top level

```bash
queue-aiops init                 # onboarding wizard (targets + encrypted secrets)
queue-aiops doctor [--skip-auth] # config/secret/connectivity check (PING / /api/overview)
queue-aiops overview [-t T]      # one-shot health summary (platform-dispatched)
queue-aiops mcp                  # run the MCP server (stdio)
```

## Secrets

```bash
queue-aiops secret set <target>    # add/update an encrypted secret
queue-aiops secret list            # names only — values are never printed
queue-aiops secret rm <target>
queue-aiops secret migrate         # legacy .env / env vars → encrypted store
queue-aiops secret rotate-password
```

## redis

```bash
queue-aiops redis info                      # version, role, clients, ops/sec, hit rate
queue-aiops redis memory                    # used vs maxmemory, policy, fragmentation
queue-aiops redis clients                   # clients grouped by source
queue-aiops redis slowlog [-n 128]          # slowest entries first
queue-aiops redis config-get "maxmemory*"   # CONFIG GET glob
queue-aiops redis keyspace                  # per-db keys + expiry coverage
queue-aiops redis bigkeys [--top 20]        # SCAN-budgeted big-key sample

# writes (dry-run + double-confirm; audited via the governed twins)
queue-aiops redis config-set maxmemory-policy allkeys-lru [--dry-run]
queue-aiops redis kill-client --id 77 [--dry-run]
queue-aiops redis kill-client --addr 10.0.0.5:5000 [--dry-run]
```

## rabbitmq

```bash
queue-aiops rabbitmq overview                    # totals + rates + churn
queue-aiops rabbitmq queues [--vhost /]          # deepest backlog first
queue-aiops rabbitmq queue <name> [--vhost /]    # one queue's detail
queue-aiops rabbitmq connections                 # grouped by peer host
queue-aiops rabbitmq channels                    # most unacked first
queue-aiops rabbitmq policies [--vhost /]
queue-aiops rabbitmq nodes                       # memory/disk/fd + alarms

# writes (dry-run + double-confirm; audited via the governed twins)
queue-aiops rabbitmq declare-queue <name> [--vhost /] [--durable/--transient] [--auto-delete]
queue-aiops rabbitmq purge <name> [--vhost /] [--dry-run]          # HIGH risk
queue-aiops rabbitmq delete-queue <name> [--vhost /] [--dry-run]   # HIGH risk
queue-aiops rabbitmq set-policy <name> '<pattern>' '{"max-length": 100000}' \
    [--vhost /] [--priority 0] [--apply-to queues] [--dry-run]
queue-aiops rabbitmq delete-policy <name> [--vhost /] [--dry-run]
```

`QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional — set them to
record who ran a write and why on the audit row (never required, never block):

```bash
export QUEUE_AUDIT_APPROVED_BY="alice"
export QUEUE_AUDIT_RATIONALE="INC-1234: drain t

Github ReposUpdated 1d 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.