{"id":"36a4fed7-990b-4412-852c-f9bf259eed55","entityType":"agent","slug":"clawhub-zw008-queue-aiops","name":"queue-aiops","canonicalUrl":"https://www.xpersona.co/agent/clawhub-zw008-queue-aiops","canonicalPath":"/agent/clawhub-zw008-queue-aiops","generatedAt":"2026-10-10T21:40:26.018Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T15:46:14.615Z","emptyReason":null},"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.","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.4K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:queue-aiops","sourceUrl":"https://clawhub.ai/zw008/queue-aiops","homepage":"https://clawhub.ai/zw008/skills/queue-aiops","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/zw008/queue-aiops","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/zw008/skills/queue-aiops","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":63,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"queue-aiops technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T15:46:14.615Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T15:46:14.615Z","emptyReason":null},"stars":null,"forks":null,"downloads":1353,"packageName":null,"latestVersion":"0.9.4","tractionLabel":"1.4K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T15:46:14.614Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T15:46:14.615Z","lastCrawledAt":"2026-10-10T15:46:14.614Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T15:46:14.615Z","lastVerifiedAt":null,"highlights":[{"version":"0.9.4","createdAt":"2026-09-16T12:33:20.585Z","changelog":"## queue-aiops 0.9.4 - Updated project documentation in SKILL.md and agent-guardrails.md - Removed obsolete skill-card.md file - No changes to runtime logic or public API; documentation and guardrail updates only","fileCount":7,"zipByteSize":20282},{"version":"0.9.3","createdAt":"2026-09-15T06:19:51.073Z","changelog":"- Removed the file skill-card.md. - No changes to core functionality or documentation other than this file removal.","fileCount":7,"zipByteSize":19903},{"version":"0.9.2","createdAt":"2026-09-12T14:43:52.143Z","changelog":"- Updated documentation to point OpenClaw plugin install to the @zw008 namespace instead of @aiops-tools. - Removed the unnecessary skill-card.md file from the repository. - No changes to core functionality.","fileCount":7,"zipByteSize":19819},{"version":"0.9.1","createdAt":"2026-09-12T10:26:50.217Z","changelog":"## queue-aiops 0.9.1 Changelog - Updated documentation in SKILL.md: enhanced installation instructions and clarified OpenClaw plugin integration. - Removed redundant skill-card.md file. - No changes to core functionality or toolset; operational and governance details remain the same.","fileCount":7,"zipByteSize":19975},{"version":"0.9.0","createdAt":"2026-09-12T01:14:46.772Z","changelog":"# queue-aiops 0.9.0 Changelog - Updated the `SKILL.md` manifest for improved metadata accuracy, including new `anyBins` requirement (`queue-aiops` or `uvx`). - Expanded optional environment variable configuration details. - Removed the `skill-card.md` file. - No changes to core functionality or user-facing features.","fileCount":7,"zipByteSize":19733},{"version":"0.8.0","createdAt":"2026-08-10T06:54:00.547Z","changelog":"- Removed the file: skill-card.md - No changes to functionality or features. - Housekeeping update; documentation file cleanup only.","fileCount":7,"zipByteSize":19739},{"version":"0.7.0","createdAt":"2026-08-10T03:58:42.479Z","changelog":"- Removed file: skill-card.md (no other changes in functionality or documentation) - Housekeeping update; no user-facing changes - All features, tools, and documentation remain unchanged","fileCount":7,"zipByteSize":19730},{"version":"0.6.0","createdAt":"2026-08-03T05:54:53.555Z","changelog":"- Removed the file skill-card.md from the repository. - No user-facing changes to functionality, description, or supported features. - Documentation and usage instructions remain unchanged. - Version incremented to 0.6.0.","fileCount":7,"zipByteSize":19712}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:queue-aiops","setupComplexity":"low","setupSteps":["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":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T21:40:26.013Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-zw008-queue-aiops/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T15:46:14.615Z","emptyReason":null},"readme":"Skill: queue-aiops\n\nOwner: zw008\n\nSummary: 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.\n\nTags: latest:0.9.4\n\nVersion history:\n\nv0.9.4 | 2026-09-16T12:33:20.585Z | auto\n\n## queue-aiops 0.9.4\n\n- Updated project documentation in SKILL.md and agent-guardrails.md\n- Removed obsolete skill-card.md file\n- No changes to runtime logic or public API; documentation and guardrail updates only\n\nv0.9.3 | 2026-09-15T06:19:51.073Z | auto\n\n- Removed the file skill-card.md.\n- No changes to core functionality or documentation other than this file removal.\n\nv0.9.2 | 2026-09-12T14:43:52.143Z | auto\n\n- Updated documentation to point OpenClaw plugin install to the @zw008 namespace instead of @aiops-tools.\n- Removed the unnecessary skill-card.md file from the repository.\n- No changes to core functionality.\n\nv0.9.1 | 2026-09-12T10:26:50.217Z | auto\n\n## queue-aiops 0.9.1 Changelog\n\n- Updated documentation in SKILL.md: enhanced installation instructions and clarified OpenClaw plugin integration.\n- Removed redundant skill-card.md file.\n- No changes to core functionality or toolset; operational and governance details remain the same.\n\nv0.9.0 | 2026-09-12T01:14:46.772Z | auto\n\n# queue-aiops 0.9.0 Changelog\n\n- Updated the `SKILL.md` manifest for improved metadata accuracy, including new `anyBins` requirement (`queue-aiops` or `uvx`).\n- Expanded optional environment variable configuration details.\n- Removed the `skill-card.md` file.\n- No changes to core functionality or user-facing features.\n\nv0.8.0 | 2026-08-10T06:54:00.547Z | auto\n\n- Removed the file: skill-card.md\n- No changes to functionality or features.\n- Housekeeping update; documentation file cleanup only.\n\nv0.7.0 | 2026-08-10T03:58:42.479Z | auto\n\n- Removed file: skill-card.md (no other changes in functionality or documentation)\n- Housekeeping update; no user-facing changes\n- All features, tools, and documentation remain unchanged\n\nv0.6.0 | 2026-08-03T05:54:53.555Z | auto\n\n- Removed the file skill-card.md from the repository.\n- No user-facing changes to functionality, description, or supported features.\n- Documentation and usage instructions remain unchanged.\n- Version incremented to 0.6.0.\n\nv0.5.0 | 2026-08-02T09:41:39.903Z | auto\n\n- Removed the file skill-card.md.\n- No changes were made to functionality or documentation content.\n- This update consists solely of a documentation cleanup.\n\nv0.4.0 | 2026-07-21T09:42:59.142Z | auto\n\n## queue-aiops 0.4.0\n\n- Updated governance model: risk tiers are now descriptive labels; @governed_tool performs budget guard, audit, and labelling (approver gate removed).\n- Improved CLI safety for high-risk actions (purge_queue, delete_queue): now require dry_run plus double confirmation.\n- Documentation updates: clarified governance workflow, CLI behaviour, and undo logic in SKILL.md and reference docs.\n- Removed legacy skill-card.md file.\n- Minor text edits for accuracy and alignment across documentation files.\n\nv0.3.0 | 2026-07-20T11:17:22.977Z | auto\n\n- Removed the skill-card.md file.\n- No functional changes to the skill; documentation only.\n- Package content is unchanged apart from the documentation file deletion.\n\nv0.2.2 | 2026-07-19T17:35:18.108Z | auto\n\n## queue-aiops 0.2.2\n\n- Removed the file: `skill-card.md`\n- No feature or functionality changes. This is a documentation cleanup release.\n- No impact to runtime behavior or user experience.\n\nv0.2.1 | 2026-07-19T13:11:54.668Z | auto\n\n- Removed the file skill-card.md.\n- No changes to skill logic or functionality.\n- No user-facing features modified.\n\nv0.2.0 | 2026-07-19T03:53:22.325Z | auto\n\nqueue-aiops v0.2.0\n\n- Added new agent guardrails documentation for enhanced governance reference.\n- Introduced undo tool support (undo_list, undo_apply), expanding tool count to 28.\n- Improved skill description, metadata, and presentation for clarity and discoverability.\n- Updated capability references and documentation for current feature set.\n- Removed legacy skill-card.md in favor of reorganized references and documentation.\n\nv0.1.1 | 2026-07-17T06:05:25.237Z | auto\n\nNo file changes were detected in this release.\n\n- Version bump to 0.1.1 with no code or documentation changes.\n\nv0.1.0 | 2026-07-17T05:57:34.682Z | auto\n\nInitial release of Queue AIops — governed operations for Redis and RabbitMQ brokers.\n\n- Provides one-shot broker overviews, memory posture, slowlog, big-key sampling, clients, and config for Redis; and queue depths, connections, policies, and alarms for RabbitMQ.\n- Includes four flagship root-cause analyses: Redis memory pressure, Redis latency/slowlog, RabbitMQ queue backlog, and connection churn on both platforms.\n- All write operations (config set, client kill, queue declare/purge/delete, policy set/delete) are audited, risk-tiered, and pass through a governance harness with undo and token budget.\n- Credentials stored encrypted, never plaintext; governance, policy, auditing, and risk controls are built-in.\n- Safe surface: only SCAN-based sampling for Redis big keys, no dangerous commands (like KEYS *).\n- Tool runs in standalone/mock mode and supports both platforms from a single config.\n\nArchive index:\n\nArchive v0.9.4: 7 files, 20282 bytes\n\nFiles: references/agent-guardrails.md (7917b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (3038b), SKILL.md (17504b), _meta.json (130b)\n\nFile v0.9.4:SKILL.md\n\n---\nname: queue-aiops\nslug: queue-aiops\ndisplayName: \"Queue AIops\"\nsummary: \"Governed redis + rabbitmq ops: memory/latency/backlog/churn RCA, policies. 28 tools.\"\nlicense: MIT\nhomepage: https://github.com/AIops-tools/Queue-AIops\ntags: [aiops, mcp, governance, queue]\ndescription: >\n  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).\n  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.\n  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.\n  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.\ninstaller:\n  kind: uv\n  package: queue-aiops\nargument-hint: \"[a queue/key/client id, or describe your cache/broker task]\"\nallowed-tools:\n  - Bash\nmetadata: {\"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\"]}}\ncompatibility: >\n  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.\n  All write operations are audited to a local SQLite DB under ~/.queue-aiops/ (relocatable via QUEUE_AIOPS_HOME).\n  Credentials: the redis password (optional) or the rabbitmq management password is stored ENCRYPTED in ~/.queue-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'queue-aiops init' to onboard (it asks for the platform), or 'queue-aiops secret set <target>' to add one. The store is unlocked by a master password from QUEUE_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var QUEUE_<TARGET_NAME_UPPER>_SECRET is still honoured as a fallback with a deprecation warning (migrate with 'queue-aiops secret migrate'). The secret is presented as AUTH at connect time (redis) or HTTP Basic auth (rabbitmq) and held only in memory; secrets are never logged or echoed.\n  State-changing operations pass through the @governed_tool decorator (budget guard + audit + risk-tier labelling). purge_queue and delete_queue are risk=high with dry_run + double confirmation at the CLI; purge is irreversible (priorState = the message count about to be destroyed), and delete_queue's undo re-declares the captured queue definition — the messages are NOT restored. Reversible writes (redis_config_set, set_policy, delete_policy, declare_queue) capture the real fetched before-state and record an inverse undo descriptor.\n  Safety: the redis surface is a typed command allow-list (no generic passthrough) and big-key sampling is SCAN-based under a hard budget — never KEYS *. rabbitmq path segments (queue/policy names and the default vhost '/') are percent-encoded centrally.\n  Webhooks: none — no outbound network calls beyond the configured redis instances / rabbitmq management API.\n  Transitive dependencies: the redis Python client, httpx (HTTP client), and the MCP SDK. No post-install scripts or background services.\n---\n\n# Queue AIops\n\n> **Disclaimer**: Community-maintained open-source project, **not affiliated with, endorsed by, or sponsored by the Redis or RabbitMQ projects or their respective owners.** Redis and RabbitMQ are trademarks of their respective owners. Source at [github.com/AIops-tools/Queue-AIops](https://github.com/AIops-tools/Queue-AIops) under the MIT license.\n\nGoverned broker operations — **28 MCP tools** across **redis** (RESP client) and\n**rabbitmq** (management HTTP API), every one wrapped with the bundled\n`@governed_tool` harness: a local unified audit log under `~/.queue-aiops/`,\npolicy engine, token/runaway budget guard, undo-token recording, and\ndescriptive risk tiers. A per-target `platform` field selects the\nprotocol shape, so one config can span a mixed estate. The redis password /\nrabbitmq management password is stored **encrypted**\n(`~/.queue-aiops/secrets.enc`, Fernet + scrypt) — never plaintext on disk.\n\n> **Standalone**: the governance harness is bundled in the package\n> (`queue_aiops.governance`) — no external skill-family dependency. Behaviour is\n> covered by a mock-based test suite; `docs/VERIFICATION.md` is the checklist for a\n> live run (both platforms are free/self-hostable, so a lab container is enough).\n\n## What This Skill Does\n\n| Group | Tools | Count | R/W |\n|-------|-------|:-----:|:---:|\n| **Overview** | queue_overview | 1 | read |\n| **redis** | redis_server_info, redis_memory_stats, redis_clients, redis_slowlog, redis_config_get, redis_keyspace, redis_big_keys | 7 | read |\n| **rabbitmq** | rabbitmq_overview, list_queues, queue_detail, list_connections, list_channels, list_policies, node_health | 7 | read |\n| **Flagship analyses** | redis_memory_pressure_rca, redis_latency_rca, rabbitmq_queue_backlog_rca, connection_churn_analysis | 4 | read |\n| **Writes** | redis_config_set, redis_kill_client, declare_queue, set_policy, delete_policy | 5 | write (med) |\n| **Writes** | purge_queue, delete_queue | 2 | write (**high**) |\n| **Undo** | undo_list, undo_apply | 2 | read / write |\n\nThe four flagship analyses are transparent heuristics that report their numbers,\nnever a black-box verdict: `redis_memory_pressure_rca` reads used-vs-maxmemory +\neviction policy + fragmentation + the big-key sample into a cause + action;\n`redis_latency_rca` digests the SLOWLOG by command pattern and adds fork/AOF\nstall signals; `rabbitmq_queue_backlog_rca` classifies each deep queue (no\nconsumers / unacked pileup / rate deficit) and reports watermark alarms that\nblock all publishers; `connection_churn_analysis` works on both platforms and\npins churn to client sources.\n\n## Quick Install\n\n```bash\nuv tool install queue-aiops\nqueue-aiops init       # wizard: pick platform (redis/rabbitmq) + encrypted secret\nqueue-aiops doctor\n```\n\nOr as an OpenClaw plugin, which installs this skill and its MCP server together:\n\n```bash\nopenclaw plugins install clawhub:@zw008/queue-aiops\nopenclaw skills info queue-aiops          # expect: Visible to model: yes\n```\n\nNeeds `uvx` on `PATH`: the MCP server is fetched with uv, pinned to this release.\n\n## When to Use This Skill\n\n- Get a one-shot snapshot (`overview` / `redis_server_info` / `rabbitmq_overview`)\n- Investigate cache memory pressure (`analyze memory`) → cause + action\n  (raise maxmemory vs fix eviction policy vs split big keys)\n- Chase latency (`analyze latency`, `redis slowlog`) → O(N) command patterns,\n  blocked clients, fork/AOF stalls\n- Triage a growing queue (`analyze backlog`, `rabbitmq queues`) → per-queue\n  cause (no consumers / unacked pileup / slow consumers) + watermark alarms\n- Spot connection churn or leaks (`analyze churn`, `redis clients`,\n  `rabbitmq connections`) — clients grouped by source\n- Safely change state: `redis config-set` (undo = prior value), `rabbitmq\n  set-policy`/`delete-policy` (undo = prior policy), `declare-queue`, and the\n  high-risk `purge`/`delete-queue` (dry-run + double confirmation; messages are\n  not restorable)\n\n**Do NOT use when** the target is not a redis/rabbitmq broker — route\nhypervisor, storage, backup, cluster/orchestration, database, network,\nmonitoring-stack, or OT/industrial work to the appropriate other AIops-tools\nskill.\n\n## Related Skills — Skill Routing\n\n| If the user wants… | Use |\n|--------------------|-----|\n| redis / rabbitmq cache & broker ops | **queue-aiops** (this skill) |\n| A non-broker platform (hypervisor, storage, backup, cluster, database, network, monitoring stack, OT edge) | the appropriate **other AIops-tools** skill |\n| Managed cloud queue services / other broker products | out of scope for this tool |\n\n## Common Workflows\n\n### 1. Redis is near maxmemory and starting to evict\n\n1. `queue-aiops doctor` → confirm the broker is reachable and the credential (if any)\n   works before you read numbers off it.\n2. `queue-aiops redis memory` → used vs `maxmemory`, the eviction policy in force, and\n   the fragmentation ratio, straight from `INFO memory`.\n3. `queue-aiops analyze memory --used-pct 85` → findings in check order, each citing its measured\n   number (order is not severity — weigh them all): **noeviction near the limit** (the dangerous one — writes will start failing\n   with OOM rather than evicting), active eviction in progress, fragmentation versus real\n   swapping, and oversized keys.\n4. `queue-aiops redis bigkeys --count 500` → a SCAN-budgeted sample of the largest keys,\n   reported **with its coverage %** so you know how much of the keyspace was actually\n   examined. A low coverage number means \"no big key found\" is not yet an answer.\n5. `queue-aiops redis keyspace` → which database the growth is in, to point the fix at\n   the right workload.\n6. If the policy is the problem: `queue-aiops redis config-get maxmemory*` to read the\n   current values, then\n   `queue-aiops redis config-set maxmemory-policy allkeys-lru --dry-run` and re-run for\n   real (double-confirm; the prior value is captured from `CONFIG GET` as the undo\n   descriptor).\n7. **Failure branch**: switching a cache from `noeviction` to an eviction policy means\n   Redis will start **deleting data** — if that instance is being used as a datastore\n   rather than a cache, this is the wrong fix and you need memory instead. Reverse it\n   immediately with `queue-aiops undo list` → `undo apply <id>`, which restores the\n   **prior** policy rather than a default. Note `config-set` changes the running config\n   only; if it must survive a restart, persist it in the config file too — the undo store\n   cannot help you with a value the broker forgot on its own.\n\n### 2. Redis got slow\n\n1. `queue-aiops redis slowlog --limit 50` → the slowest entries the broker itself\n   recorded.\n2. `queue-aiops analyze latency --slow-us 10000` → the slowlog digested **by command\n   pattern**, with O(N) commands flagged and an incremental variant suggested\n   (`KEYS` → `SCAN`, `SMEMBERS` → `SSCAN`), plus blocked-client counts and fork/AOF stall\n   signals read out of `INFO persistence`.\n3. `queue-aiops redis info` → confirm whether the stalls line up with background saves\n   (a fork stall is a persistence problem, not a query problem).\n4. `queue-aiops redis clients` → who is connected, and how many are blocked;\n   `queue-aiops analyze churn` → whether clients are reconnecting constantly, which shows\n   up as latency but is really a client-configuration bug.\n5. If one client is pathological: `queue-aiops redis kill-client --addr <ip:port>\n   --dry-run` then for real (double-confirm).\n6. **Failure branch**: `kill-client` is **irreversible and records no undo** — a killed\n   connection cannot be un-killed, and a well-behaved client will simply reconnect,\n   which fixes nothing while your kill is audited as a write. If latency does not\n   improve, the cause is more likely the O(N) command pattern from step 2: fix the\n   caller, not the connection. Killing clients in a loop will trip the runaway budget\n   guard.\n\n### 3. A RabbitMQ queue keeps growing\n\n1. `queue-aiops rabbitmq overview` and `queue-aiops rabbitmq nodes` → check first for\n   **memory or disk watermark alarms**, which block every publisher on the node and make\n   every queue look broken at once.\n2. `queue-aiops rabbitmq queues --vhost /` → queues sorted deepest-backlog-first.\n3. `queue-aiops analyze backlog --vhost / --top 20` → the per-queue cause: **no consumers\n   attached**, consumers connected but **not acking** (an unacked pile-up), or a publish\n   rate simply outpacing delivery — each citing the measured counts.\n4. `queue-aiops rabbitmq queue <name>` → that queue's detail: consumer count, ready vs\n   unacked split, and its arguments.\n5. `queue-aiops rabbitmq connections` and `queue-aiops rabbitmq channels` → confirm\n   whether the consumers exist at all, and whether their prefetch is starving throughput.\n6. To cap unbounded growth while the consumer is fixed:\n   `queue-aiops rabbitmq set-policy backlog-cap '^orders\\.' '{\"max-length\": 100000}'\n   --apply-to queues --dry-run`, then re-run for real (reversible — the prior policy is\n   captured for undo).\n7. **Failure branch**: do **not** reach for `rabbitmq purge` as a first response — it is\n   **irreversible, risk=high, and destroys real messages**; if the cause from step 3 was\n   \"no consumers\", those messages are the backlog your consumers still need. Purge only\n   with explicit sign-off, a `--dry-run` read first, and the CLI double confirmation.\n   A `max-length` policy also **drops messages** once the cap is hit — if that is not\n   acceptable, `queue-aiops undo apply <id>` restores the prior policy and the real fix\n   is consumer capacity.\n\n### 4. Retire a queue, reversibly\n\n1. `queue-aiops overview` → the broker-wide picture across configured targets.\n2. `queue-aiops rabbitmq queue <name> --vhost /` → confirm it is genuinely idle: zero\n   consumers, zero ready, zero unacked. A queue with messages is not a queue you retire.\n3. `queue-aiops rabbitmq policies` → check no policy still targets its name pattern, so\n   you are not leaving a dangling rule behind.\n4. `queue-aiops rabbitmq delete-queue <name> --vhost / --dry-run` → preview.\n5. Re-run without `--dry-run` (double-confirm, risk=high) — the write\n   captures the queue's definition first, so the undo descriptor **re-declares exactly\n   that queue** (durability and auto-delete flags included).\n6. `queue-aiops rabbitmq queues` → confirm it is gone and nothing else changed.\n7. **Failure branch**: `queue-aiops undo apply <id>` re-declares the queue from the\n   captured definition — but it restores the queue, **not its messages**, which are gone\n   with it. Bindings created outside this tool are not captured either. If the queue\n   turns out to have been in use, expect to re-create bindings by hand; that asymmetry is\n   why step 2 (proving it is idle) matters more than the undo does.\n\n## Governance & Safety\n\nThe skill delivers reads and writes and records them; it does **not** decide\nwhether a write is permitted. That is your agent's judgement, or the permission\nof the account you connect it with (a Redis ACL user restricted to read\ncommands, a RabbitMQ management user with only the `monitoring` tag — writes\nthen fail at the broker). There is no read-only switch, policy file, or approval\ngate.\n\n- **Audit is the guarantee, and it is not bypassable.** Every operation — MCP\n  and CLI alike — is logged to `~/.queue-aiops/audit.db` (relocatable via\n  `QUEUE_AIOPS_HOME`): params (secrets redacted), result, status, duration, and\n  the risk tier. The CLI writes the same row the MCP path does.\n- `QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional annotations\n  recorded on the audit row (who/why); they are never required and never block.\n- **Runaway guard** — a safety backstop, not authorization: the same call looped\n  in a tight window trips a circuit breaker. Disable with `QUEUE_RUNAWAY_MAX=0`.\n- Writes support `--dry-run` / `dry_run=True` and double confirmation at the CLI;\n  CLI writes execute through the governed twins, so they are audited too.\n- Reversible writes capture the real fetched before-state and record an\n  inverse descriptor; `purge_queue` and `redis_kill_client` are irreversible\n  and record priorState only. `delete_queue`'s undo restores the queue\n  *definition*, never its messages — the descriptor says so.\n- Big-key sampling is SCAN-budgeted (never `KEYS *`); the redis surface is a\n  typed command allow-list; rabbitmq paths are centrally percent-encoded\n  (default vhost `/` included).\n\n## References\n\n- `references/capabilities.md` — full tool + platform + API/command reference\n- `references/cli-reference.md` — CLI command reference\n- `references/setup-guide.md` — onboarding, credentials, and connectivity\n\nFile v0.9.4:_meta.json\n\n{\n  \"ownerId\": \"kn7b067awq2s97bn3d7p5qfhw5827pxc\",\n  \"slug\": \"queue-aiops\",\n  \"version\": \"0.9.4\",\n  \"publishedAt\": 1789562000585\n}\n\nFile v0.9.4:references/agent-guardrails.md\n\n# Agent guardrails — running queue-aiops with a smaller / local model\n\nIf you drive these tools with a local model (Llama, Qwen, Mistral … via Goose,\nOllama, LM Studio, or any OpenAI-compatible runtime), you will get noticeably\nbetter results with a short system prompt. This page gives you one, and — more\nimportantly — tells you which guardrails you **no longer need to write**, because\nthe tool now enforces them itself.\n\nThe distinction matters. A guardrail in a prompt is a request. A guardrail in the\nharness is a guarantee. Anything below that we could move into the harness, we did.\n\n## Authorization is not this tool's job — decide it where it belongs\n\nWhether a write should happen is your decision, or the account's. The tool does\nnot gate it — there is no read-only switch and no approval prompt to configure.\nThe two right places to control read vs write:\n\n- **The account you connect with.** Give the Redis connection an ACL user\n  restricted to read commands, or the RabbitMQ management user only the\n  `monitoring` tag (no `management`/`policymaker`). A write then fails at the\n  broker, which is the only place the permission actually lives — a revoked\n  permission cannot be argued around by a model, but a skill-side flag can.\n- **Your agent's system prompt.** If you want an observe-only session, tell the\n  model not to call the write tools (they are clearly tagged `[WRITE]`).\n\nWhat the tool *does* guarantee is that you can always see what happened:\n\n## What the tool enforces — do not waste prompt budget on these\n\n| You might be tempted to prompt | Why you don't need to |\n|---|---|\n| \"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 `\"\"`. |\n| \"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. |\n| \"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. |\n| \"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. |\n| \"Confirm before anything destructive\" | `delete_queue` and `purge_queue` require a `--dry-run`-able preview plus double confirmation at the CLI. |\n| \"Log what you did\" | Every governed call is audited to `~/.queue-aiops/audit.db` regardless of what the model says it did — and the CLI writes the same row the MCP path does, so there is no unaudited entry point. |\n| \"Don't get stuck retrying\" | The runaway guard trips a circuit breaker if the same call is hammered in a tight loop — a stuck agent is stopped rather than left to burn calls and time. |\n\n## What still needs a prompt\n\nThese are model-behaviour problems the harness cannot fix from the outside.\n\n⚠️ **Finding order is not priority.** These RCAs append findings in the order the checks\nrun, not worst-first, and there is no `rank` key in the payload. A broker at 12 % of\n`maxmemory` with 35 GiB of oversized keys reports the fragmentation finding first purely\nbecause fragmentation is checked before big keys. Do not let the model treat `findings[0]`\nas the headline — make it weigh every finding's `evidence` and say which one it acted on.\n(Earlier versions of this file claimed these lists were ranked worst-first. They never were.)\n\nCopy this into your agent's system prompt:\n\n```text\nYou operate a RabbitMQ broker or a Redis instance through the queue-aiops MCP\ntools.\n\nTOOL USE\n- Before answering any question about the current broker, you MUST call a tool.\n  Never answer from memory or assumption.\n- Actually invoke the tool. Do not describe the call you would make, and do not\n  emit an example JSON response in place of calling it.\n- If a tool call fails, report the real error verbatim. Never fill the gap with\n  a plausible-sounding answer.\n\nREADING RESULTS\n- Read the whole result before concluding. If a result contains a \"truncated\"\n  field that is true, say so and re-run with a higher limit. The slowest command\n  or the deepest queue may be the one just past the cut-off.\n- A null field means the broker did not report that value. Report it as \"not\n  available\" — never infer it.\n- Report values exactly as returned. Redis counters from INFO are cumulative\n  since the instance started — compare rates, never quote a raw total as\n  \"operations today\". SLOWLOG durations are microseconds.\n- \"coveragePct\" on a big-key sample is how much of the keyspace was walked. A\n  large key found in a 3% sample is evidence there are large keys; it is not\n  evidence that it is the largest key. Say which you mean.\n\nSCOPE\n- Separate observation from interpretation. State what the tools returned, then\n  any interpretation, clearly marked as such.\n- A queue with a backlog and zero consumers is a stopped/absent consumer, not a\n  slow broker. Check the consumer count before blaming throughput.\n- Unacked messages piling up is a consumer that is not acknowledging — a\n  different fault from a queue nothing is reading. Do not conflate them.\n- A node memory or disk alarm blocks publishers on the WHOLE broker via flow\n  control, not just the queue you were looking at. Report it as global.\n- Do not confuse a queue with an exchange, a vhost with a queue name, a channel\n  with a connection, or a Redis key with a queue.\n- RabbitMQ and Redis are different systems. Do not suggest a RabbitMQ policy on\n  a Redis target; the platform is in every result.\n```\n\n## Recommended setup for a local model\n\nStart with a connection that *cannot* write, verify, and widen the account's\npermission only when you trust the setup — the destructive operations here\ndestroy data rather than configuration: `purge_queue` discards messages that no\nundo token can bring back.\n\n```bash\n# e.g. connect Redis as an ACL user restricted to read commands, or give the\n# RabbitMQ management user only the `monitoring` tag. Then:\nqueue-aiops doctor\n```\n\nOptionally annotate the audit trail with who is operating and why — recorded on\nevery row, never required:\n\n```bash\nexport QUEUE_AUDIT_APPROVED_BY=\"your.name@example.com\"\nexport QUEUE_AUDIT_RATIONALE=\"draining the dead-letter queue, ticket OPS-881\"\n```\n\n## If your model still struggles\n\nSome behaviours are model-capacity limits rather than prompt problems:\n\n- **Multi-tool workflows time out or drift.** Prefer the RCA tools —\n  `rabbitmq_queue_backlog_rca` correlates queue depth, consumer count, rates and\n  node alarms inside one call, so the model does not have to chain\n  `list_queues`, `list_connections` and `node_health` and keep vhost/queue name\n  pairs straight.\n- **The model ignores later tool results in a long context.** The slowlog and\n  the queue list are the big payloads. Use `--count` / a vhost filter\n  deliberately rather than pulling everything.\n- **The model describes calls instead of making them.** This is usually a\n  runtime/tool-calling-format mismatch, not a prompt problem — check that your\n  client advertises the tools in the format your model was trained on.\n\nFeedback on running this with a specific local model is genuinely useful —\nopen an issue at\n[github.com/AIops-tools/Queue-AIops](https://github.com/AIops-tools/Queue-AIops/issues)\nwith the model, runtime, and what went wrong.\n\nFile v0.9.4:references/capabilities.md\n\n# queue-aiops — full capability reference\n\n## Platforms\n\n| Platform | Protocol | Auth | Default port |\n|----------|----------|------|:---:|\n| `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 |\n| `rabbitmq` | Management HTTP API (`/api/...`) via httpx (30s timeout) | HTTP Basic — management user (needs the `monitoring` or `management` tag) | 15672 |\n\nA name-keyed platform registry (`queue_aiops/platform.py`) maps each target's\n`platform` field to its protocol shape. New broker families are additive\nregistry entries — the ops/CLI/MCP layers don't change.\n\n### redis command surface (typed allow-list — no generic passthrough)\n\n`PING`, `INFO [section]`, `SLOWLOG GET`, `CLIENT LIST`, `CLIENT KILL ID/ADDR`,\n`CONFIG GET`, `CONFIG SET`, `MEMORY STATS`, `MEMORY USAGE`, `SCAN`\n(budgeted), `DBSIZE`. Never `KEYS *`.\n\nBig-key sampling budget (named constants in `ops/redis_reads.py`):\n`SCAN_BUDGET_KEYS=10000`, `SCAN_PAGE=500`, `MEMORY_SAMPLE_MAX=200`,\n`TOP_KEYS=20`. `coveragePct` reports how partial the walk was.\n\n### rabbitmq management-API paths (all interpolated segments percent-encoded)\n\n`/api/overview`, `/api/nodes`, `/api/whoami`, `/api/queues[/{vhost}[/{name}]]`,\n`/api/queues/{vhost}/{name}/contents` (purge), `/api/connections`,\n`/api/channels`, `/api/consumers`, `/api/policies[/{vhost}[/{name}]]`.\nThe default vhost `/` is sent as `%2F`.\n\n## Tools (28)\n\n### Overview (1)\n\n| Tool | Returns |\n|------|---------|\n| `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. |\n\n### redis reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `redis_server_info` | version, mode, role, uptime, clients, blocked clients, ops/sec, hit rate |\n| `redis_memory_stats` | usedBytes vs maxmemoryBytes (+ usedPctOfMax), maxmemory policy, fragmentation ratio, RSS/peak, key count |\n| `redis_clients` | clients (bounded 200) + grouped `bySource` (ip without port), busiest first |\n| `redis_slowlog(count?)` | slowlog entries, slowest first (durationUs, command folded to one string) |\n| `redis_config_get(pattern?)` | CONFIG GET glob → sorted parameter map |\n| `redis_keyspace` | per-db keys/expires/avgTtl + expiry coverage % |\n| `redis_big_keys(top?)` | SCAN-budgeted big-key sample, largest first, with budget + coveragePct |\n\n### rabbitmq reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `rabbitmq_overview` | version, cluster, queue/message totals, object counts, publish/deliver/ack rates, connection/channel churn rates |\n| `list_queues(vhost?)` | queues deepest-backlog first: messages/ready/unacked, consumers, rates, memory |\n| `queue_detail(vhost, name)` | one queue: counts, rates, durable/auto_delete/arguments, node, consumer utilisation |\n| `list_connections` | connections + grouped `byPeerHost` (connection + channel counts) |\n| `list_channels` | channels most-unacked first: unacked, prefetch, consumer count |\n| `list_policies(vhost?)` | policies: pattern, apply-to, priority, definition |\n| `node_health` | per node: mem used/limit + alarm, disk free/limit + alarm, fd/socket usage |\n\n### Flagship analyses (4) — transparent heuristics, injectable telemetry\n\n| Tool | Thresholds (named constants) | Verdicts |\n|------|------------------------------|----------|\n| `redis_memory_pressure_rca(used_pct?, telemetry?)` | `DEFAULT_USED_PCT=85`, `FRAG_HIGH_RATIO=1.5`, `FRAG_SWAP_RATIO=0.8`, `BIG_KEY_MIN_BYTES=10MiB` | noeviction near limit (writes will OOM) / eviction pressure / active eviction / fragmentation / likely swapping / oversized sampled keys |\n| `redis_latency_rca(slow_us?, telemetry?)` | `SLOW_US=10000`, `FORK_STALL_US=100000`, heavy-command set (O(N)/blocking) | slow command patterns (heavy ones get an incremental-variant action) / blocked clients / fork stall / delayed AOF fsync / persistence job running / dataset loading |\n| `rabbitmq_queue_backlog_rca(vhost?, top?, queues?, nodes?)` | `BACKLOG_MIN_MESSAGES=1000`, `UNACKED_PCT_HIGH=50`, `RATE_DEFICIT_FACTOR=1.2` | per queue: no consumers / unacked pileup / publish outpaces delivery / residual backlog; global: memory & disk watermark alarms (publishers blocked) |\n| `connection_churn_analysis(snapshot?, history?)` | `CHURN_RATE_HIGH=1/s`, `CHANNELS_PER_CONN_HIGH=20`, `REDIS_CONN_RATE_HIGH=5/s` | redis: reconnect-per-operation churn, maxclients rejections; rabbitmq: connection churn, channel-leak ratio, growth vs a prior snapshot; both: clients grouped by source |\n\nAll four accept injected telemetry for pure analysis (no live pull), and every\nfinding carries `cause`, `action`, and `evidence` numbers.\n\n### Governed writes (7)\n\n| Tool | Risk | Prior state captured | Undo |\n|------|:---:|----------------------|------|\n| `redis_config_set(parameter, value)` | medium | prior value via CONFIG GET (param name validated) | set the prior value back |\n| `redis_kill_client(client_id?/addr?)` | medium | the client's CLIENT LIST row (who/where/last command) | none — connection gone (clients reconnect) |\n| `declare_queue(vhost, name, durable?, auto_delete?, arguments?)` | medium | whether the queue existed | delete the queue — only when newly created |\n| `set_policy(vhost, name, pattern, definition, priority?, apply_to?)` | medium | the prior policy (or \"did not exist\") | restore prior policy, or delete-if-new |\n| `delete_policy(vhost, name)` | medium | the policy's full definition | re-create the captured policy |\n| `purge_queue(vhost, name)` | **high** | message count about to be destroyed | none — messages unrecoverable |\n| `delete_queue(vhost, name)` | **high** | full queue definition + message count | re-declare the captured definition (**messages NOT restored**) |\n\nEvery write takes `dry_run` (MCP) / `--dry-run` + double-confirm (CLI); the two\nhigh-risk writes (`purge_queue`, `delete_queue`) are gated by that same dry-run\npreview + double confirmation at the CLI, nothing more.\n\n### Undo (2)\n\n| Tool | Returns |\n|------|---------|\n| `undo_list(limit?)` | recorded undo descriptors, newest first, with their `_undo_id` |\n| `undo_apply(undo_id, dry_run?)` | replays the recorded inverse (governed like any other write) |\n\n## Environment variables\n\n| Variable | Purpose |\n|----------|---------|\n| `QUEUE_AIOPS_HOME` | Relocate `~/.queue-aiops` (audit/undo/config state) |\n| `QUEUE_AIOPS_CONFIG` | Explicit config.yaml path for the MCP server |\n| `QUEUE_AIOPS_MASTER_PASSWORD` | Unlock the encrypted secret store non-interactively |\n| `QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` | Optional approver/rationale annotations recorded on the audit row |\n| `QUEUE_MAX_TOOL_CALLS` / `QUEUE_MAX_TOOL_SECONDS` | Budget ceilings |\n| `QUEUE_RUNAWAY_MAX` / `QUEUE_RUNAWAY_WINDOW_SEC` | Runaway-loop breaker tuning |\n| `QUEUE_<TARGET>_SECRET` | Legacy plaintext secret fallback (deprecated) |\n\nFile v0.9.4:references/cli-reference.md\n\n# queue-aiops — CLI reference\n\nAll read commands print JSON. All write commands support `--dry-run` and\ndouble-confirm before executing through the governed MCP twins (audited).\n`--target/-t <name>` selects a target from config; omitted = the first target.\n\n## Top level\n\n```bash\nqueue-aiops init                 # onboarding wizard (targets + encrypted secrets)\nqueue-aiops doctor [--skip-auth] # config/secret/connectivity check (PING / /api/overview)\nqueue-aiops overview [-t T]      # one-shot health summary (platform-dispatched)\nqueue-aiops mcp                  # run the MCP server (stdio)\n```\n\n## Secrets\n\n```bash\nqueue-aiops secret set <target>    # add/update an encrypted secret\nqueue-aiops secret list            # names only — values are never printed\nqueue-aiops secret rm <target>\nqueue-aiops secret migrate         # legacy .env / env vars → encrypted store\nqueue-aiops secret rotate-password\n```\n\n## redis\n\n```bash\nqueue-aiops redis info                      # version, role, clients, ops/sec, hit rate\nqueue-aiops redis memory                    # used vs maxmemory, policy, fragmentation\nqueue-aiops redis clients                   # clients grouped by source\nqueue-aiops redis slowlog [-n 128]          # slowest entries first\nqueue-aiops redis config-get \"maxmemory*\"   # CONFIG GET glob\nqueue-aiops redis keyspace                  # per-db keys + expiry coverage\nqueue-aiops redis bigkeys [--top 20]        # SCAN-budgeted big-key sample\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops redis config-set maxmemory-policy allkeys-lru [--dry-run]\nqueue-aiops redis kill-client --id 77 [--dry-run]\nqueue-aiops redis kill-client --addr 10.0.0.5:5000 [--dry-run]\n```\n\n## rabbitmq\n\n```bash\nqueue-aiops rabbitmq overview                    # totals + rates + churn\nqueue-aiops rabbitmq queues [--vhost /]          # deepest backlog first\nqueue-aiops rabbitmq queue <name> [--vhost /]    # one queue's detail\nqueue-aiops rabbitmq connections                 # grouped by peer host\nqueue-aiops rabbitmq channels                    # most unacked first\nqueue-aiops rabbitmq policies [--vhost /]\nqueue-aiops rabbitmq nodes                       # memory/disk/fd + alarms\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops rabbitmq declare-queue <name> [--vhost /] [--durable/--transient] [--auto-delete]\nqueue-aiops rabbitmq purge <name> [--vhost /] [--dry-run]          # HIGH risk\nqueue-aiops rabbitmq delete-queue <name> [--vhost /] [--dry-run]   # HIGH risk\nqueue-aiops rabbitmq set-policy <name> '<pattern>' '{\"max-length\": 100000}' \\\n    [--vhost /] [--priority 0] [--apply-to queues] [--dry-run]\nqueue-aiops rabbitmq delete-policy <name> [--vhost /] [--dry-run]\n```\n\n`QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional — set them to\nrecord who ran a write and why on the audit row (never required, never block):\n\n```bash\nexport QUEUE_AUDIT_APPROVED_BY=\"alice\"\nexport QUEUE_AUDIT_RATIONALE=\"INC-1234: drain the poison-message queue\"\n```\n\n## analyze (flagship RCAs)\n\n```bash\nqueue-aiops analyze memory  [--used-pct 85]   # redis memory-pressure RCA\nqueue-aiops analyze latency [--slow-us 10000] # redis latency/slowlog RCA\nqueue-aiops analyze backlog [--vhost /] [--top 20]  # rabbitmq queue-backlog RCA\nqueue-aiops analyze churn                     # connection churn (both platforms)\n```\n\nFile v0.9.4:references/setup-guide.md\n\n# queue-aiops — setup guide\n\n## 1. Install\n\n```bash\nuv tool install queue-aiops     # or: pipx install queue-aiops / pip install queue-aiops\n```\n\nPython >= 3.11.\n\n## 2. Prepare the brokers\n\n### redis\n\nAny reachable redis 5.x–7.x instance works. Auth is optional:\n\n- **No password (lab)**: nothing to prepare — the wizard accepts an empty\n  password and connects without `AUTH`.\n- **Password**: the value of `requirepass` (or an ACL user's password). TLS\n  deployments (`rediss://`) are supported via the wizard's TLS prompt.\n\nThe tool only ever issues a typed allow-list of commands (INFO, SLOWLOG,\nCLIENT, CONFIG, MEMORY, SCAN, DBSIZE, PING) — reads are safe on production,\nand key sampling is SCAN-budgeted, never `KEYS *`.\n\n### rabbitmq\n\nEnable the management plugin and create (or reuse) a user with at least the\n`monitoring` tag (reads) — the `management`/`policymaker` tag is needed for\npolicy writes, and queue purge/delete needs configure permission on the vhost:\n\n```bash\nrabbitmq-plugins enable rabbitmq_management\nrabbitmqctl add_user queueops 'a-strong-password'\nrabbitmqctl set_user_tags queueops monitoring\nrabbitmqctl set_permissions -p / queueops \"\" \"\" \".*\"   # read-only example\n```\n\nThe management API listens on 15672 (HTTP) / 15671 (HTTPS) by default.\n\n## 3. Onboard\n\n```bash\nqueue-aiops init\n```\n\nThe wizard asks for:\n\n1. **Master password** — encrypts `~/.queue-aiops/secrets.enc` (Fernet +\n   scrypt). Export `QUEUE_AIOPS_MASTER_PASSWORD` for non-interactive/MCP use.\n2. **Targets** — name, platform (`redis`/`rabbitmq`), host, port (defaults\n   6379/15672), redis db index, TLS (verify defaults to **true**; answer No\n   for self-signed lab certs), rabbitmq management user, and the secret\n   (hidden prompt; empty = auth-less redis).\n3. It offers to run `doctor` to confirm connectivity right away.\n\nConfig lands in `~/.queue-aiops/config.yaml`:\n\n```yaml\ntargets:\n  - name: cache1\n    platform: redis\n    host: 10.0.0.10\n    port: 6379\n    username: \"\"\n    db: 0\n    use_tls: false\n    verify_ssl: true\n  - name: broker1\n    platform: rabbitmq\n    host: 10.0.0.20\n    port: 15672\n    username: queueops\n    db: 0\n    use_tls: false\n    verify_ssl: true\n```\n\n## 4. Verify\n\n```bash\nqueue-aiops doctor\n```\n\nChecks config, the encrypted store (and its 600 permissions), per-target\nsecrets (a missing redis secret is a *warning* — auth-less lab mode), and live\nconnectivity: `PING` for redis, `GET /api/overview` for rabbitmq. Exit code 0\n= healthy.\n\n## 5. Wire up MCP\n\n```json\n{\n  \"mcpServers\": {\n    \"queue-aiops\": {\n      \"command\": \"uvx\",\n      \"args\": [\"--from\", \"queue-aiops\", \"queue-aiops-mcp\"],\n      \"env\": {\n        \"QUEUE_AIOPS_MASTER_PASSWORD\": \"your-master-password\"\n      }\n    }\n  }\n}\n```\n\nMCP clients start the server with a minimal environment — put everything it\nneeds (`QUEUE_AIOPS_MASTER_PASSWORD`, a relocated `QUEUE_AIOPS_HOME`, and any\noptional `QUEUE_AUDIT_APPROVED_BY`/`QUEUE_AUDIT_RATIONALE` audit annotations) in\nthat `env` block.\n\n## Troubleshooting\n\n| Symptom | Fix |\n|---------|-----|\n| `No secret for target 'x'` | `queue-aiops secret set x` or re-run `init` (redis targets may legitimately have none) |\n| Redis `AUTH` errors | The stored password is wrong — `queue-aiops secret set <target>` |\n| 401/403 from the management API | Wrong user/password, or the user lacks the `monitoring`/`management` tag or vhost access |\n| 404 on a queue/policy | Stale name, or the vhost is wrong — remember the default vhost is `/` |\n| Write rejected by the broker | The connecting user lacks configure/write permission (or the Redis ACL forbids the command) — grant it, or connect a user that has it |\n| Master-password prompt in MCP | Export `QUEUE_AIOPS_MASTER_PASSWORD` in the MCP `env` block |\n\nFile v0.9.4:skill-card.md\n\n## Description:\n\nQueue AIops helps agents inspect and operate Redis caches and RabbitMQ brokers, including health overviews, memory and latency analysis, queue backlog RCA, connection churn analysis, governed broker writes, and undo-aware operations.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[zw008](https://clawhub.ai/user/zw008)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, operators, and site reliability engineers use this skill to diagnose Redis and RabbitMQ operational issues, inspect broker state, and perform audited broker changes. It is scoped to self-managed Redis and RabbitMQ deployments, not managed cloud queue services or unrelated infrastructure.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can expose an agent to production Redis and RabbitMQ operational state and credentials.\n\nMitigation: Use dedicated least-privilege broker accounts, prefer read-only credentials for diagnostics, enable TLS, and avoid placing the master password in synced configuration files.\n\nRisk: The skill exposes production-impacting actions such as purge, delete, config-set, policy changes, and kill-client.\n\nMitigation: Treat write operations as change-controlled actions, require human process outside the tool, use dry runs where available, and verify broker permissions limit unwanted writes.\n\nRisk: Some destructive operations cannot restore lost data, especially queue purge, client kill, and queue deletion messages.\n\nMitigation: Confirm queue state and business impact before execution, keep backups or recovery procedures where applicable, and use undo only for operations whose captured prior state is sufficient.\n\nRisk: Executable installation depends on external package resolution.\n\nMitigation: Pin or verify the executable package before use and install only from trusted release channels.\n\n## Reference(s):\n\n- [Queue AIops GitHub homepage](https://github.com/AIops-tools/Queue-AIops)\n- [Queue AIops ClawHub skill page](https://clawhub.ai/zw008/skills/queue-aiops)\n- [Capability reference](references/capabilities.md)\n- [CLI reference](references/cli-reference.md)\n- [Setup guide](references/setup-guide.md)\n- [Agent guardrails](references/agent-guardrails.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown guidance with inline shell commands, configuration snippets, and JSON-style operational results.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Outputs may include broker observations, RCA findings, risk-tiered write guidance, dry-run recommendations, audit context, and undo guidance.]\n\n## Skill Version(s):\n\n0.9.4 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.9.3: 7 files, 19903 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2806b), SKILL.md (17453b), _meta.json (130b)\n\nFile v0.9.3:SKILL.md\n\n---\nname: queue-aiops\nslug: queue-aiops\ndisplayName: \"Queue AIops\"\nsummary: \"Governed redis + rabbitmq ops: memory/latency/backlog/churn RCA, policies. 28 tools.\"\nlicense: MIT\nhomepage: https://github.com/AIops-tools/Queue-AIops\ntags: [aiops, mcp, governance, queue]\ndescription: >\n  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).\n  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.\n  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.\n  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.\ninstaller:\n  kind: uv\n  package: queue-aiops\nargument-hint: \"[a queue/key/client id, or describe your cache/broker task]\"\nallowed-tools:\n  - Bash\nmetadata: {\"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\"]}}\ncompatibility: >\n  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.\n  All write operations are audited to a local SQLite DB under ~/.queue-aiops/ (relocatable via QUEUE_AIOPS_HOME).\n  Credentials: the redis password (optional) or the rabbitmq management password is stored ENCRYPTED in ~/.queue-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'queue-aiops init' to onboard (it asks for the platform), or 'queue-aiops secret set <target>' to add one. The store is unlocked by a master password from QUEUE_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var QUEUE_<TARGET_NAME_UPPER>_SECRET is still honoured as a fallback with a deprecation warning (migrate with 'queue-aiops secret migrate'). The secret is presented as AUTH at connect time (redis) or HTTP Basic auth (rabbitmq) and held only in memory; secrets are never logged or echoed.\n  State-changing operations pass through the @governed_tool decorator (budget guard + audit + risk-tier labelling). purge_queue and delete_queue are risk=high with dry_run + double confirmation at the CLI; purge is irreversible (priorState = the message count about to be destroyed), and delete_queue's undo re-declares the captured queue definition — the messages are NOT restored. Reversible writes (redis_config_set, set_policy, delete_policy, declare_queue) capture the real fetched before-state and record an inverse undo descriptor.\n  Safety: the redis surface is a typed command allow-list (no generic passthrough) and big-key sampling is SCAN-based under a hard budget — never KEYS *. rabbitmq path segments (queue/policy names and the default vhost '/') are percent-encoded centrally.\n  Webhooks: none — no outbound network calls beyond the configured redis instances / rabbitmq management API.\n  Transitive dependencies: the redis Python client, httpx (HTTP client), and the MCP SDK. No post-install scripts or background services.\n---\n\n# Queue AIops\n\n> **Disclaimer**: Community-maintained open-source project, **not affiliated with, endorsed by, or sponsored by the Redis or RabbitMQ projects or their respective owners.** Redis and RabbitMQ are trademarks of their respective owners. Source at [github.com/AIops-tools/Queue-AIops](https://github.com/AIops-tools/Queue-AIops) under the MIT license.\n\nGoverned broker operations — **28 MCP tools** across **redis** (RESP client) and\n**rabbitmq** (management HTTP API), every one wrapped with the bundled\n`@governed_tool` harness: a local unified audit log under `~/.queue-aiops/`,\npolicy engine, token/runaway budget guard, undo-token recording, and\ndescriptive risk tiers. A per-target `platform` field selects the\nprotocol shape, so one config can span a mixed estate. The redis password /\nrabbitmq management password is stored **encrypted**\n(`~/.queue-aiops/secrets.enc`, Fernet + scrypt) — never plaintext on disk.\n\n> **Standalone**: the governance harness is bundled in the package\n> (`queue_aiops.governance`) — no external skill-family dependency. Behaviour is\n> covered by a mock-based test suite; `docs/VERIFICATION.md` is the checklist for a\n> live run (both platforms are free/self-hostable, so a lab container is enough).\n\n## What This Skill Does\n\n| Group | Tools | Count | R/W |\n|-------|-------|:-----:|:---:|\n| **Overview** | queue_overview | 1 | read |\n| **redis** | redis_server_info, redis_memory_stats, redis_clients, redis_slowlog, redis_config_get, redis_keyspace, redis_big_keys | 7 | read |\n| **rabbitmq** | rabbitmq_overview, list_queues, queue_detail, list_connections, list_channels, list_policies, node_health | 7 | read |\n| **Flagship analyses** | redis_memory_pressure_rca, redis_latency_rca, rabbitmq_queue_backlog_rca, connection_churn_analysis | 4 | read |\n| **Writes** | redis_config_set, redis_kill_client, declare_queue, set_policy, delete_policy | 5 | write (med) |\n| **Writes** | purge_queue, delete_queue | 2 | write (**high**) |\n| **Undo** | undo_list, undo_apply | 2 | read / write |\n\nThe four flagship analyses are transparent heuristics that report their numbers,\nnever a black-box verdict: `redis_memory_pressure_rca` reads used-vs-maxmemory +\neviction policy + fragmentation + the big-key sample into a cause + action;\n`redis_latency_rca` digests the SLOWLOG by command pattern and adds fork/AOF\nstall signals; `rabbitmq_queue_backlog_rca` classifies each deep queue (no\nconsumers / unacked pileup / rate deficit) and reports watermark alarms that\nblock all publishers; `connection_churn_analysis` works on both platforms and\npins churn to client sources.\n\n## Quick Install\n\n```bash\nuv tool install queue-aiops\nqueue-aiops init       # wizard: pick platform (redis/rabbitmq) + encrypted secret\nqueue-aiops doctor\n```\n\nOr as an OpenClaw plugin, which installs this skill and its MCP server together:\n\n```bash\nopenclaw plugins install clawhub:@zw008/queue-aiops\nopenclaw skills info queue-aiops          # expect: Visible to model: yes\n```\n\nNeeds `uvx` on `PATH`: the MCP server is fetched with uv, pinned to this release.\n\n## When to Use This Skill\n\n- Get a one-shot snapshot (`overview` / `redis_server_info` / `rabbitmq_overview`)\n- Investigate cache memory pressure (`analyze memory`) → cause + action\n  (raise maxmemory vs fix eviction policy vs split big keys)\n- Chase latency (`analyze latency`, `redis slowlog`) → O(N) command patterns,\n  blocked clients, fork/AOF stalls\n- Triage a growing queue (`analyze backlog`, `rabbitmq queues`) → per-queue\n  cause (no consumers / unacked pileup / slow consumers) + watermark alarms\n- Spot connection churn or leaks (`analyze churn`, `redis clients`,\n  `rabbitmq connections`) — clients grouped by source\n- Safely change state: `redis config-set` (undo = prior value), `rabbitmq\n  set-policy`/`delete-policy` (undo = prior policy), `declare-queue`, and the\n  high-risk `purge`/`delete-queue` (dry-run + double confirmation; messages are\n  not restorable)\n\n**Do NOT use when** the target is not a redis/rabbitmq broker — route\nhypervisor, storage, backup, cluster/orchestration, database, network,\nmonitoring-stack, or OT/industrial work to the appropriate other AIops-tools\nskill.\n\n## Related Skills — Skill Routing\n\n| If the user wants… | Use |\n|--------------------|-----|\n| redis / rabbitmq cache & broker ops | **queue-aiops** (this skill) |\n| A non-broker platform (hypervisor, storage, backup, cluster, database, network, monitoring stack, OT edge) | the appropriate **other AIops-tools** skill |\n| Managed cloud queue services / other broker products | out of scope for this tool |\n\n## Common Workflows\n\n### 1. Redis is near maxmemory and starting to evict\n\n1. `queue-aiops doctor` → confirm the broker is reachable and the credential (if any)\n   works before you read numbers off it.\n2. `queue-aiops redis memory` → used vs `maxmemory`, the eviction policy in force, and\n   the fragmentation ratio, straight from `INFO memory`.\n3. `queue-aiops analyze memory --used-pct 85` → ranked findings, each citing its measured\n   number: **noeviction near the limit** (the dangerous one — writes will start failing\n   with OOM rather than evicting), active eviction in progress, fragmentation versus real\n   swapping, and oversized keys.\n4. `queue-aiops redis bigkeys --count 500` → a SCAN-budgeted sample of the largest keys,\n   reported **with its coverage %** so you know how much of the keyspace was actually\n   examined. A low coverage number means \"no big key found\" is not yet an answer.\n5. `queue-aiops redis keyspace` → which database the growth is in, to point the fix at\n   the right workload.\n6. If the policy is the problem: `queue-aiops redis config-get maxmemory*` to read the\n   current values, then\n   `queue-aiops redis config-set maxmemory-policy allkeys-lru --dry-run` and re-run for\n   real (double-confirm; the prior value is captured from `CONFIG GET` as the undo\n   descriptor).\n7. **Failure branch**: switching a cache from `noeviction` to an eviction policy means\n   Redis will start **deleting data** — if that instance is being used as a datastore\n   rather than a cache, this is the wrong fix and you need memory instead. Reverse it\n   immediately with `queue-aiops undo list` → `undo apply <id>`, which restores the\n   **prior** policy rather than a default. Note `config-set` changes the running config\n   only; if it must survive a restart, persist it in the config file too — the undo store\n   cannot help you with a value the broker forgot on its own.\n\n### 2. Redis got slow\n\n1. `queue-aiops redis slowlog --limit 50` → the slowest entries the broker itself\n   recorded.\n2. `queue-aiops analyze latency --slow-us 10000` → the slowlog digested **by command\n   pattern**, with O(N) commands flagged and an incremental variant suggested\n   (`KEYS` → `SCAN`, `SMEMBERS` → `SSCAN`), plus blocked-client counts and fork/AOF stall\n   signals read out of `INFO persistence`.\n3. `queue-aiops redis info` → confirm whether the stalls line up with background saves\n   (a fork stall is a persistence problem, not a query problem).\n4. `queue-aiops redis clients` → who is connected, and how many are blocked;\n   `queue-aiops analyze churn` → whether clients are reconnecting constantly, which shows\n   up as latency but is really a client-configuration bug.\n5. If one client is pathological: `queue-aiops redis kill-client --addr <ip:port>\n   --dry-run` then for real (double-confirm).\n6. **Failure branch**: `kill-client` is **irreversible and records no undo** — a killed\n   connection cannot be un-killed, and a well-behaved client will simply reconnect,\n   which fixes nothing while your kill is audited as a write. If latency does not\n   improve, the cause is more likely the O(N) command pattern from step 2: fix the\n   caller, not the connection. Killing clients in a loop will trip the runaway budget\n   guard.\n\n### 3. A RabbitMQ queue keeps growing\n\n1. `queue-aiops rabbitmq overview` and `queue-aiops rabbitmq nodes` → check first for\n   **memory or disk watermark alarms**, which block every publisher on the node and make\n   every queue look broken at once.\n2. `queue-aiops rabbitmq queues --vhost /` → queues sorted deepest-backlog-first.\n3. `queue-aiops analyze backlog --vhost / --top 20` → the per-queue cause: **no consumers\n   attached**, consumers connected but **not acking** (an unacked pile-up), or a publish\n   rate simply outpacing delivery — each citing the measured counts.\n4. `queue-aiops rabbitmq queue <name>` → that queue's detail: consumer count, ready vs\n   unacked split, and its arguments.\n5. `queue-aiops rabbitmq connections` and `queue-aiops rabbitmq channels` → confirm\n   whether the consumers exist at all, and whether their prefetch is starving throughput.\n6. To cap unbounded growth while the consumer is fixed:\n   `queue-aiops rabbitmq set-policy backlog-cap '^orders\\.' '{\"max-length\": 100000}'\n   --apply-to queues --dry-run`, then re-run for real (reversible — the prior policy is\n   captured for undo).\n7. **Failure branch**: do **not** reach for `rabbitmq purge` as a first response — it is\n   **irreversible, risk=high, and destroys real messages**; if the cause from step 3 was\n   \"no consumers\", those messages are the backlog your consumers still need. Purge only\n   with explicit sign-off, a `--dry-run` read first, and the CLI double confirmation.\n   A `max-length` policy also **drops messages** once the cap is hit — if that is not\n   acceptable, `queue-aiops undo apply <id>` restores the prior policy and the real fix\n   is consumer capacity.\n\n### 4. Retire a queue, reversibly\n\n1. `queue-aiops overview` → the broker-wide picture across configured targets.\n2. `queue-aiops rabbitmq queue <name> --vhost /` → confirm it is genuinely idle: zero\n   consumers, zero ready, zero unacked. A queue with messages is not a queue you retire.\n3. `queue-aiops rabbitmq policies` → check no policy still targets its name pattern, so\n   you are not leaving a dangling rule behind.\n4. `queue-aiops rabbitmq delete-queue <name> --vhost / --dry-run` → preview.\n5. Re-run without `--dry-run` (double-confirm, risk=high) — the write\n   captures the queue's definition first, so the undo descriptor **re-declares exactly\n   that queue** (durability and auto-delete flags included).\n6. `queue-aiops rabbitmq queues` → confirm it is gone and nothing else changed.\n7. **Failure branch**: `queue-aiops undo apply <id>` re-declares the queue from the\n   captured definition — but it restores the queue, **not its messages**, which are gone\n   with it. Bindings created outside this tool are not captured either. If the queue\n   turns out to have been in use, expect to re-create bindings by hand; that asymmetry is\n   why step 2 (proving it is idle) matters more than the undo does.\n\n## Governance & Safety\n\nThe skill delivers reads and writes and records them; it does **not** decide\nwhether a write is permitted. That is your agent's judgement, or the permission\nof the account you connect it with (a Redis ACL user restricted to read\ncommands, a RabbitMQ management user with only the `monitoring` tag — writes\nthen fail at the broker). There is no read-only switch, policy file, or approval\ngate.\n\n- **Audit is the guarantee, and it is not bypassable.** Every operation — MCP\n  and CLI alike — is logged to `~/.queue-aiops/audit.db` (relocatable via\n  `QUEUE_AIOPS_HOME`): params (secrets redacted), result, status, duration, and\n  the risk tier. The CLI writes the same row the MCP path does.\n- `QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional annotations\n  recorded on the audit row (who/why); they are never required and never block.\n- **Runaway guard** — a safety backstop, not authorization: the same call looped\n  in a tight window trips a circuit breaker. Disable with `QUEUE_RUNAWAY_MAX=0`.\n- Writes support `--dry-run` / `dry_run=True` and double confirmation at the CLI;\n  CLI writes execute through the governed twins, so they are audited too.\n- Reversible writes capture the real fetched before-state and record an\n  inverse descriptor; `purge_queue` and `redis_kill_client` are irreversible\n  and record priorState only. `delete_queue`'s undo restores the queue\n  *definition*, never its messages — the descriptor says so.\n- Big-key sampling is SCAN-budgeted (never `KEYS *`); the redis surface is a\n  typed command allow-list; rabbitmq paths are centrally percent-encoded\n  (default vhost `/` included).\n\n## References\n\n- `references/capabilities.md` — full tool + platform + API/command reference\n- `references/cli-reference.md` — CLI command reference\n- `references/setup-guide.md` — onboarding, credentials, and connectivity\n\nFile v0.9.3:_meta.json\n\n{\n  \"ownerId\": \"kn7b067awq2s97bn3d7p5qfhw5827pxc\",\n  \"slug\": \"queue-aiops\",\n  \"version\": \"0.9.3\",\n  \"publishedAt\": 1789453191073\n}\n\nFile v0.9.3:references/agent-guardrails.md\n\n# Agent guardrails — running queue-aiops with a smaller / local model\n\nIf you drive these tools with a local model (Llama, Qwen, Mistral … via Goose,\nOllama, LM Studio, or any OpenAI-compatible runtime), you will get noticeably\nbetter results with a short system prompt. This page gives you one, and — more\nimportantly — tells you which guardrails you **no longer need to write**, because\nthe tool now enforces them itself.\n\nThe distinction matters. A guardrail in a prompt is a request. A guardrail in the\nharness is a guarantee. Anything below that we could move into the harness, we did.\n\n## Authorization is not this tool's job — decide it where it belongs\n\nWhether a write should happen is your decision, or the account's. The tool does\nnot gate it — there is no read-only switch and no approval prompt to configure.\nThe two right places to control read vs write:\n\n- **The account you connect with.** Give the Redis connection an ACL user\n  restricted to read commands, or the RabbitMQ management user only the\n  `monitoring` tag (no `management`/`policymaker`). A write then fails at the\n  broker, which is the only place the permission actually lives — a revoked\n  permission cannot be argued around by a model, but a skill-side flag can.\n- **Your agent's system prompt.** If you want an observe-only session, tell the\n  model not to call the write tools (they are clearly tagged `[WRITE]`).\n\nWhat the tool *does* guarantee is that you can always see what happened:\n\n## What the tool enforces — do not waste prompt budget on these\n\n| You might be tempted to prompt | Why you don't need to |\n|---|---|\n| \"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 `\"\"`. |\n| \"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. |\n| \"Preserve the ordering / tell me what's most urgent\" | `rabbitmq_queue_backlog_rca`, `redis_memory_pressure_rca`, `redis_latency_rca` and `connection_churn_analysis` rank findings worst-first, each carrying the measured number it was based on. Priority is in the payload, not implied by list position. |\n| \"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. |\n| \"Confirm before anything destructive\" | `delete_queue` and `purge_queue` require a `--dry-run`-able preview plus double confirmation at the CLI. |\n| \"Log what you did\" | Every governed call is audited to `~/.queue-aiops/audit.db` regardless of what the model says it did — and the CLI writes the same row the MCP path does, so there is no unaudited entry point. |\n| \"Don't get stuck retrying\" | The runaway guard trips a circuit breaker if the same call is hammered in a tight loop — a stuck agent is stopped rather than left to burn calls and time. |\n\n## What still needs a prompt\n\nThese are model-behaviour problems the harness cannot fix from the outside.\nCopy this into your agent's system prompt:\n\n```text\nYou operate a RabbitMQ broker or a Redis instance through the queue-aiops MCP\ntools.\n\nTOOL USE\n- Before answering any question about the current broker, you MUST call a tool.\n  Never answer from memory or assumption.\n- Actually invoke the tool. Do not describe the call you would make, and do not\n  emit an example JSON response in place of calling it.\n- If a tool call fails, report the real error verbatim. Never fill the gap with\n  a plausible-sounding answer.\n\nREADING RESULTS\n- Read the whole result before concluding. If a result contains a \"truncated\"\n  field that is true, say so and re-run with a higher limit. The slowest command\n  or the deepest queue may be the one just past the cut-off.\n- A null field means the broker did not report that value. Report it as \"not\n  available\" — never infer it.\n- Report values exactly as returned. Redis counters from INFO are cumulative\n  since the instance started — compare rates, never quote a raw total as\n  \"operations today\". SLOWLOG durations are microseconds.\n- \"coveragePct\" on a big-key sample is how much of the keyspace was walked. A\n  large key found in a 3% sample is evidence there are large keys; it is not\n  evidence that it is the largest key. Say which you mean.\n\nSCOPE\n- Separate observation from interpretation. State what the tools returned, then\n  any interpretation, clearly marked as such.\n- A queue with a backlog and zero consumers is a stopped/absent consumer, not a\n  slow broker. Check the consumer count before blaming throughput.\n- Unacked messages piling up is a consumer that is not acknowledging — a\n  different fault from a queue nothing is reading. Do not conflate them.\n- A node memory or disk alarm blocks publishers on the WHOLE broker via flow\n  control, not just the queue you were looking at. Report it as global.\n- Do not confuse a queue with an exchange, a vhost with a queue name, a channel\n  with a connection, or a Redis key with a queue.\n- RabbitMQ and Redis are different systems. Do not suggest a RabbitMQ policy on\n  a Redis target; the platform is in every result.\n```\n\n## Recommended setup for a local model\n\nStart with a connection that *cannot* write, verify, and widen the account's\npermission only when you trust the setup — the destructive operations here\ndestroy data rather than configuration: `purge_queue` discards messages that no\nundo token can bring back.\n\n```bash\n# e.g. connect Redis as an ACL user restricted to read commands, or give the\n# RabbitMQ management user only the `monitoring` tag. Then:\nqueue-aiops doctor\n```\n\nOptionally annotate the audit trail with who is operating and why — recorded on\nevery row, never required:\n\n```bash\nexport QUEUE_AUDIT_APPROVED_BY=\"your.name@example.com\"\nexport QUEUE_AUDIT_RATIONALE=\"draining the dead-letter queue, ticket OPS-881\"\n```\n\n## If your model still struggles\n\nSome behaviours are model-capacity limits rather than prompt problems:\n\n- **Multi-tool workflows time out or drift.** Prefer the RCA tools —\n  `rabbitmq_queue_backlog_rca` correlates queue depth, consumer count, rates and\n  node alarms inside one call, so the model does not have to chain\n  `list_queues`, `list_connections` and `node_health` and keep vhost/queue name\n  pairs straight.\n- **The model ignores later tool results in a long context.** The slowlog and\n  the queue list are the big payloads. Use `--count` / a vhost filter\n  deliberately rather than pulling everything.\n- **The model describes calls instead of making them.** This is usually a\n  runtime/tool-calling-format mismatch, not a prompt problem — check that your\n  client advertises the tools in the format your model was trained on.\n\nFeedback on running this with a specific local model is genuinely useful —\nopen an issue at\n[github.com/AIops-tools/Queue-AIops](https://github.com/AIops-tools/Queue-AIops/issues)\nwith the model, runtime, and what went wrong.\n\nFile v0.9.3:references/capabilities.md\n\n# queue-aiops — full capability reference\n\n## Platforms\n\n| Platform | Protocol | Auth | Default port |\n|----------|----------|------|:---:|\n| `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 |\n| `rabbitmq` | Management HTTP API (`/api/...`) via httpx (30s timeout) | HTTP Basic — management user (needs the `monitoring` or `management` tag) | 15672 |\n\nA name-keyed platform registry (`queue_aiops/platform.py`) maps each target's\n`platform` field to its protocol shape. New broker families are additive\nregistry entries — the ops/CLI/MCP layers don't change.\n\n### redis command surface (typed allow-list — no generic passthrough)\n\n`PING`, `INFO [section]`, `SLOWLOG GET`, `CLIENT LIST`, `CLIENT KILL ID/ADDR`,\n`CONFIG GET`, `CONFIG SET`, `MEMORY STATS`, `MEMORY USAGE`, `SCAN`\n(budgeted), `DBSIZE`. Never `KEYS *`.\n\nBig-key sampling budget (named constants in `ops/redis_reads.py`):\n`SCAN_BUDGET_KEYS=10000`, `SCAN_PAGE=500`, `MEMORY_SAMPLE_MAX=200`,\n`TOP_KEYS=20`. `coveragePct` reports how partial the walk was.\n\n### rabbitmq management-API paths (all interpolated segments percent-encoded)\n\n`/api/overview`, `/api/nodes`, `/api/whoami`, `/api/queues[/{vhost}[/{name}]]`,\n`/api/queues/{vhost}/{name}/contents` (purge), `/api/connections`,\n`/api/channels`, `/api/consumers`, `/api/policies[/{vhost}[/{name}]]`.\nThe default vhost `/` is sent as `%2F`.\n\n## Tools (28)\n\n### Overview (1)\n\n| Tool | Returns |\n|------|---------|\n| `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. |\n\n### redis reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `redis_server_info` | version, mode, role, uptime, clients, blocked clients, ops/sec, hit rate |\n| `redis_memory_stats` | usedBytes vs maxmemoryBytes (+ usedPctOfMax), maxmemory policy, fragmentation ratio, RSS/peak, key count |\n| `redis_clients` | clients (bounded 200) + grouped `bySource` (ip without port), busiest first |\n| `redis_slowlog(count?)` | slowlog entries, slowest first (durationUs, command folded to one string) |\n| `redis_config_get(pattern?)` | CONFIG GET glob → sorted parameter map |\n| `redis_keyspace` | per-db keys/expires/avgTtl + expiry coverage % |\n| `redis_big_keys(top?)` | SCAN-budgeted big-key sample, largest first, with budget + coveragePct |\n\n### rabbitmq reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `rabbitmq_overview` | version, cluster, queue/message totals, object counts, publish/deliver/ack rates, connection/channel churn rates |\n| `list_queues(vhost?)` | queues deepest-backlog first: messages/ready/unacked, consumers, rates, memory |\n| `queue_detail(vhost, name)` | one queue: counts, rates, durable/auto_delete/arguments, node, consumer utilisation |\n| `list_connections` | connections + grouped `byPeerHost` (connection + channel counts) |\n| `list_channels` | channels most-unacked first: unacked, prefetch, consumer count |\n| `list_policies(vhost?)` | policies: pattern, apply-to, priority, definition |\n| `node_health` | per node: mem used/limit + alarm, disk free/limit + alarm, fd/socket usage |\n\n### Flagship analyses (4) — transparent heuristics, injectable telemetry\n\n| Tool | Thresholds (named constants) | Verdicts |\n|------|------------------------------|----------|\n| `redis_memory_pressure_rca(used_pct?, telemetry?)` | `DEFAULT_USED_PCT=85`, `FRAG_HIGH_RATIO=1.5`, `FRAG_SWAP_RATIO=0.8`, `BIG_KEY_MIN_BYTES=10MiB` | noeviction near limit (writes will OOM) / eviction pressure / active eviction / fragmentation / likely swapping / oversized sampled keys |\n| `redis_latency_rca(slow_us?, telemetry?)` | `SLOW_US=10000`, `FORK_STALL_US=100000`, heavy-command set (O(N)/blocking) | slow command patterns (heavy ones get an incremental-variant action) / blocked clients / fork stall / delayed AOF fsync / persistence job running / dataset loading |\n| `rabbitmq_queue_backlog_rca(vhost?, top?, queues?, nodes?)` | `BACKLOG_MIN_MESSAGES=1000`, `UNACKED_PCT_HIGH=50`, `RATE_DEFICIT_FACTOR=1.2` | per queue: no consumers / unacked pileup / publish outpaces delivery / residual backlog; global: memory & disk watermark alarms (publishers blocked) |\n| `connection_churn_analysis(snapshot?, history?)` | `CHURN_RATE_HIGH=1/s`, `CHANNELS_PER_CONN_HIGH=20`, `REDIS_CONN_RATE_HIGH=5/s` | redis: reconnect-per-operation churn, maxclients rejections; rabbitmq: connection churn, channel-leak ratio, growth vs a prior snapshot; both: clients grouped by source |\n\nAll four accept injected telemetry for pure analysis (no live pull), and every\nfinding carries `cause`, `action`, and `evidence` numbers.\n\n### Governed writes (7)\n\n| Tool | Risk | Prior state captured | Undo |\n|------|:---:|----------------------|------|\n| `redis_config_set(parameter, value)` | medium | prior value via CONFIG GET (param name validated) | set the prior value back |\n| `redis_kill_client(client_id?/addr?)` | medium | the client's CLIENT LIST row (who/where/last command) | none — connection gone (clients reconnect) |\n| `declare_queue(vhost, name, durable?, auto_delete?, arguments?)` | medium | whether the queue existed | delete the queue — only when newly created |\n| `set_policy(vhost, name, pattern, definition, priority?, apply_to?)` | medium | the prior policy (or \"did not exist\") | restore prior policy, or delete-if-new |\n| `delete_policy(vhost, name)` | medium | the policy's full definition | re-create the captured policy |\n| `purge_queue(vhost, name)` | **high** | message count about to be destroyed | none — messages unrecoverable |\n| `delete_queue(vhost, name)` | **high** | full queue definition + message count | re-declare the captured definition (**messages NOT restored**) |\n\nEvery write takes `dry_run` (MCP) / `--dry-run` + double-confirm (CLI); the two\nhigh-risk writes (`purge_queue`, `delete_queue`) are gated by that same dry-run\npreview + double confirmation at the CLI, nothing more.\n\n### Undo (2)\n\n| Tool | Returns |\n|------|---------|\n| `undo_list(limit?)` | recorded undo descriptors, newest first, with their `_undo_id` |\n| `undo_apply(undo_id, dry_run?)` | replays the recorded inverse (governed like any other write) |\n\n## Environment variables\n\n| Variable | Purpose |\n|----------|---------|\n| `QUEUE_AIOPS_HOME` | Relocate `~/.queue-aiops` (audit/undo/config state) |\n| `QUEUE_AIOPS_CONFIG` | Explicit config.yaml path for the MCP server |\n| `QUEUE_AIOPS_MASTER_PASSWORD` | Unlock the encrypted secret store non-interactively |\n| `QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` | Optional approver/rationale annotations recorded on the audit row |\n| `QUEUE_MAX_TOOL_CALLS` / `QUEUE_MAX_TOOL_SECONDS` | Budget ceilings |\n| `QUEUE_RUNAWAY_MAX` / `QUEUE_RUNAWAY_WINDOW_SEC` | Runaway-loop breaker tuning |\n| `QUEUE_<TARGET>_SECRET` | Legacy plaintext secret fallback (deprecated) |\n\nFile v0.9.3:references/cli-reference.md\n\n# queue-aiops — CLI reference\n\nAll read commands print JSON. All write commands support `--dry-run` and\ndouble-confirm before executing through the governed MCP twins (audited).\n`--target/-t <name>` selects a target from config; omitted = the first target.\n\n## Top level\n\n```bash\nqueue-aiops init                 # onboarding wizard (targets + encrypted secrets)\nqueue-aiops doctor [--skip-auth] # config/secret/connectivity check (PING / /api/overview)\nqueue-aiops overview [-t T]      # one-shot health summary (platform-dispatched)\nqueue-aiops mcp                  # run the MCP server (stdio)\n```\n\n## Secrets\n\n```bash\nqueue-aiops secret set <target>    # add/update an encrypted secret\nqueue-aiops secret list            # names only — values are never printed\nqueue-aiops secret rm <target>\nqueue-aiops secret migrate         # legacy .env / env vars → encrypted store\nqueue-aiops secret rotate-password\n```\n\n## redis\n\n```bash\nqueue-aiops redis info                      # version, role, clients, ops/sec, hit rate\nqueue-aiops redis memory                    # used vs maxmemory, policy, fragmentation\nqueue-aiops redis clients                   # clients grouped by source\nqueue-aiops redis slowlog [-n 128]          # slowest entries first\nqueue-aiops redis config-get \"maxmemory*\"   # CONFIG GET glob\nqueue-aiops redis keyspace                  # per-db keys + expiry coverage\nqueue-aiops redis bigkeys [--top 20]        # SCAN-budgeted big-key sample\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops redis config-set maxmemory-policy allkeys-lru [--dry-run]\nqueue-aiops redis kill-client --id 77 [--dry-run]\nqueue-aiops redis kill-client --addr 10.0.0.5:5000 [--dry-run]\n```\n\n## rabbitmq\n\n```bash\nqueue-aiops rabbitmq overview                    # totals + rates + churn\nqueue-aiops rabbitmq queues [--vhost /]          # deepest backlog first\nqueue-aiops rabbitmq queue <name> [--vhost /]    # one queue's detail\nqueue-aiops rabbitmq connections                 # grouped by peer host\nqueue-aiops rabbitmq channels                    # most unacked first\nqueue-aiops rabbitmq policies [--vhost /]\nqueue-aiops rabbitmq nodes                       # memory/disk/fd + alarms\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops rabbitmq declare-queue <name> [--vhost /] [--durable/--transient] [--auto-delete]\nqueue-aiops rabbitmq purge <name> [--vhost /] [--dry-run]          # HIGH risk\nqueue-aiops rabbitmq delete-queue <name> [--vhost /] [--dry-run]   # HIGH risk\nqueue-aiops rabbitmq set-policy <name> '<pattern>' '{\"max-length\": 100000}' \\\n    [--vhost /] [--priority 0] [--apply-to queues] [--dry-run]\nqueue-aiops rabbitmq delete-policy <name> [--vhost /] [--dry-run]\n```\n\n`QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional — set them to\nrecord who ran a write and why on the audit row (never required, never block):\n\n```bash\nexport QUEUE_AUDIT_APPROVED_BY=\"alice\"\nexport QUEUE_AUDIT_RATIONALE=\"INC-1234: drain the poison-message queue\"\n```\n\n## analyze (flagship RCAs)\n\n```bash\nqueue-aiops analyze memory  [--used-pct 85]   # redis memory-pressure RCA\nqueue-aiops analyze latency [--slow-us 10000] # redis latency/slowlog RCA\nqueue-aiops analyze backlog [--vhost /] [--top 20]  # rabbitmq queue-backlog RCA\nqueue-aiops analyze churn                     # connection churn (both platforms)\n```\n\nFile v0.9.3:references/setup-guide.md\n\n# queue-aiops — setup guide\n\n## 1. Install\n\n```bash\nuv tool install queue-aiops     # or: pipx install queue-aiops / pip install queue-aiops\n```\n\nPython >= 3.11.\n\n## 2. Prepare the brokers\n\n### redis\n\nAny reachable redis 5.x–7.x instance works. Auth is optional:\n\n- **No password (lab)**: nothing to prepare — the wizard accepts an empty\n  password and connects without `AUTH`.\n- **Password**: the value of `requirepass` (or an ACL user's password). TLS\n  deployments (`rediss://`) are supported via the wizard's TLS prompt.\n\nThe tool only ever issues a typed allow-list of commands (INFO, SLOWLOG,\nCLIENT, CONFIG, MEMORY, SCAN, DBSIZE, PING) — reads are safe on production,\nand key sampling is SCAN-budgeted, never `KEYS *`.\n\n### rabbitmq\n\nEnable the management plugin and create (or reuse) a user with at least the\n`monitoring` tag (reads) — the `management`/`policymaker` tag is needed for\npolicy writes, and queue purge/delete needs configure permission on the vhost:\n\n```bash\nrabbitmq-plugins enable rabbitmq_management\nrabbitmqctl add_user queueops 'a-strong-password'\nrabbitmqctl set_user_tags queueops monitoring\nrabbitmqctl set_permissions -p / queueops \"\" \"\" \".*\"   # read-only example\n```\n\nThe management API listens on 15672 (HTTP) / 15671 (HTTPS) by default.\n\n## 3. Onboard\n\n```bash\nqueue-aiops init\n```\n\nThe wizard asks for:\n\n1. **Master password** — encrypts `~/.queue-aiops/secrets.enc` (Fernet +\n   scrypt). Export `QUEUE_AIOPS_MASTER_PASSWORD` for non-interactive/MCP use.\n2. **Targets** — name, platform (`redis`/`rabbitmq`), host, port (defaults\n   6379/15672), redis db index, TLS (verify defaults to **true**; answer No\n   for self-signed lab certs), rabbitmq management user, and the secret\n   (hidden prompt; empty = auth-less redis).\n3. It offers to run `doctor` to confirm connectivity right away.\n\nConfig lands in `~/.queue-aiops/config.yaml`:\n\n```yaml\ntargets:\n  - name: cache1\n    platform: redis\n    host: 10.0.0.10\n    port: 6379\n    username: \"\"\n    db: 0\n    use_tls: false\n    verify_ssl: true\n  - name: broker1\n    platform: rabbitmq\n    host: 10.0.0.20\n    port: 15672\n    username: queueops\n    db: 0\n    use_tls: false\n    verify_ssl: true\n```\n\n## 4. Verify\n\n```bash\nqueue-aiops doctor\n```\n\nChecks config, the encrypted store (and its 600 permissions), per-target\nsecrets (a missing redis secret is a *warning* — auth-less lab mode), and live\nconnectivity: `PING` for redis, `GET /api/overview` for rabbitmq. Exit code 0\n= healthy.\n\n## 5. Wire up MCP\n\n```json\n{\n  \"mcpServers\": {\n    \"queue-aiops\": {\n      \"command\": \"uvx\",\n      \"args\": [\"--from\", \"queue-aiops\", \"queue-aiops-mcp\"],\n      \"env\": {\n        \"QUEUE_AIOPS_MASTER_PASSWORD\": \"your-master-password\"\n      }\n    }\n  }\n}\n```\n\nMCP clients start the server with a minimal environment — put everything it\nneeds (`QUEUE_AIOPS_MASTER_PASSWORD`, a relocated `QUEUE_AIOPS_HOME`, and any\noptional `QUEUE_AUDIT_APPROVED_BY`/`QUEUE_AUDIT_RATIONALE` audit annotations) in\nthat `env` block.\n\n## Troubleshooting\n\n| Symptom | Fix |\n|---------|-----|\n| `No secret for target 'x'` | `queue-aiops secret set x` or re-run `init` (redis targets may legitimately have none) |\n| Redis `AUTH` errors | The stored password is wrong — `queue-aiops secret set <target>` |\n| 401/403 from the management API | Wrong user/password, or the user lacks the `monitoring`/`management` tag or vhost access |\n| 404 on a queue/policy | Stale name, or the vhost is wrong — remember the default vhost is `/` |\n| Write rejected by the broker | The connecting user lacks configure/write permission (or the Redis ACL forbids the command) — grant it, or connect a user that has it |\n| Master-password prompt in MCP | Export `QUEUE_AIOPS_MASTER_PASSWORD` in the MCP `env` block |\n\nFile v0.9.3:skill-card.md\n\n## Description:\n\nQueue AIops helps agents inspect and operate Redis and RabbitMQ brokers with health summaries, memory, latency, backlog and churn RCA, governed writes, audit records and undo descriptors.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[zw008](https://clawhub.ai/user/zw008)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and operations engineers use this skill to inspect Redis caches and RabbitMQ brokers, triage memory pressure, slow commands, queue backlog and connection churn, and perform governed broker changes when their credentials permit writes.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can perform destructive Redis and RabbitMQ writes, including queue purge, queue delete and client kill operations, without an enforced approval or read-only gate.\n\nMitigation: Use a read-only Redis ACL or RabbitMQ monitoring-only user by default, enable write credentials only for planned maintenance, run dry-run previews, and require human approval in the surrounding agent workflow before writes.\n\nRisk: RabbitMQ purge and delete operations can permanently remove messages, and delete undo restores queue definitions but not lost messages.\n\nMitigation: Confirm queue idleness, consumer state and business impact before destructive queue operations, and treat undo descriptors as configuration recovery rather than message recovery.\n\nRisk: Credential handling and installation choices can expose broker access if secrets or package versions are managed loosely.\n\nMitigation: Use HTTPS/TLS for RabbitMQ credentials, avoid hardcoding QUEUE_AIOPS_MASTER_PASSWORD in config files, keep secrets in the encrypted store, and pin the queue-aiops package version for installation and MCP startup.\n\n## Reference(s):\n\n- [Queue AIops homepage](https://github.com/AIops-tools/Queue-AIops)\n- [Capabilities reference](references/capabilities.md)\n- [CLI reference](references/cli-reference.md)\n- [Setup guide](references/setup-guide.md)\n- [Agent guardrails](references/agent-guardrails.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown guidance with command examples and structured operational findings]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May describe broker observations, RCA findings, dry-run steps, audit context, undo behavior and credential or MCP configuration.]\n\n## Skill Version(s):\n\n0.9.3 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.9.2: 7 files, 19819 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2604b), SKILL.md (17453b), _meta.json (130b)\n\nFile v0.9.2:SKILL.md\n\n---\nname: queue-aiops\nslug: queue-aiops\ndisplayName: \"Queue AIops\"\nsummary: \"Governed redis + rabbitmq ops: memory/latency/backlog/churn RCA, policies. 28 tools.\"\nlicense: MIT\nhomepage: https://github.com/AIops-tools/Queue-AIops\ntags: [aiops, mcp, governance, queue]\ndescription: >\n  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).\n  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.\n  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.\n  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.\ninstaller:\n  kind: uv\n  package: queue-aiops\nargument-hint: \"[a queue/key/client id, or describe your cache/broker task]\"\nallowed-tools:\n  - Bash\nmetadata: {\"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\"]}}\ncompatibility: >\n  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.\n  All write operations are audited to a local SQLite DB under ~/.queue-aiops/ (relocatable via QUEUE_AIOPS_HOME).\n  Credentials: the redis password (optional) or the rabbitmq management password is stored ENCRYPTED in ~/.queue-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'queue-aiops init' to onboard (it asks for the platform), or 'queue-aiops secret set <target>' to add one. The store is unlocked by a master password from QUEUE_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var QUEUE_<TARGET_NAME_UPPER>_SECRET is still honoured as a fallback with a deprecation warning (migrate with 'queue-aiops secret migrate'). The secret is presented as AUTH at connect time (redis) or HTTP Basic auth (rabbitmq) and held only in memory; secrets are never logged or echoed.\n  State-changing operations pass through the @governed_tool decorator (budget guard + audit + risk-tier labelling). purge_queue and delete_queue are risk=high with dry_run + double confirmation at the CLI; purge is irreversible (priorState = the message count about to be destroyed), and delete_queue's undo re-declares the captured queue definition — the messages are NOT restored. Reversible writes (redis_config_set, set_policy, delete_policy, declare_queue) capture the real fetched before-state and record an inverse undo descriptor.\n  Safety: the redis surface is a typed command allow-list (no generic passthrough) and big-key sampling is SCAN-based under a hard budget — never KEYS *. rabbitmq path segments (queue/policy names and the default vhost '/') are percent-encoded centrally.\n  Webhooks: none — no outbound network calls beyond the configured redis instances / rabbitmq management API.\n  Transitive dependencies: the redis Python client, httpx (HTTP client), and the MCP SDK. No post-install scripts or background services.\n---\n\n# Queue AIops\n\n> **Disclaimer**: Community-maintained open-source project, **not affiliated with, endorsed by, or sponsored by the Redis or RabbitMQ projects or their respective owners.** Redis and RabbitMQ are trademarks of their respective owners. Source at [github.com/AIops-tools/Queue-AIops](https://github.com/AIops-tools/Queue-AIops) under the MIT license.\n\nGoverned broker operations — **28 MCP tools** across **redis** (RESP client) and\n**rabbitmq** (management HTTP API), every one wrapped with the bundled\n`@governed_tool` harness: a local unified audit log under `~/.queue-aiops/`,\npolicy engine, token/runaway budget guard, undo-token recording, and\ndescriptive risk tiers. A per-target `platform` field selects the\nprotocol shape, so one config can span a mixed estate. The redis password /\nrabbitmq management password is stored **encrypted**\n(`~/.queue-aiops/secrets.enc`, Fernet + scrypt) — never plaintext on disk.\n\n> **Standalone**: the governance harness is bundled in the package\n> (`queue_aiops.governance`) — no external skill-family dependency. Behaviour is\n> covered by a mock-based test suite; `docs/VERIFICATION.md` is the checklist for a\n> live run (both platforms are free/self-hostable, so a lab container is enough).\n\n## What This Skill Does\n\n| Group | Tools | Count | R/W |\n|-------|-------|:-----:|:---:|\n| **Overview** | queue_overview | 1 | read |\n| **redis** | redis_server_info, redis_memory_stats, redis_clients, redis_slowlog, redis_config_get, redis_keyspace, redis_big_keys | 7 | read |\n| **rabbitmq** | rabbitmq_overview, list_queues, queue_detail, list_connections, list_channels, list_policies, node_health | 7 | read |\n| **Flagship analyses** | redis_memory_pressure_rca, redis_latency_rca, rabbitmq_queue_backlog_rca, connection_churn_analysis | 4 | read |\n| **Writes** | redis_config_set, redis_kill_client, declare_queue, set_policy, delete_policy | 5 | write (med) |\n| **Writes** | purge_queue, delete_queue | 2 | write (**high**) |\n| **Undo** | undo_list, undo_apply | 2 | read / write |\n\nThe four flagship analyses are transparent heuristics that report their numbers,\nnever a black-box verdict: `redis_memory_pressure_rca` reads used-vs-maxmemory +\neviction policy + fragmentation + the big-key sample into a cause + action;\n`redis_latency_rca` digests the SLOWLOG by command pattern and adds fork/AOF\nstall signals; `rabbitmq_queue_backlog_rca` classifies each deep queue (no\nconsumers / unacked pileup / rate deficit) and reports watermark alarms that\nblock all publishers; `connection_churn_analysis` works on both platforms and\npins churn to client sources.\n\n## Quick Install\n\n```bash\nuv tool install queue-aiops\nqueue-aiops init       # wizard: pick platform (redis/rabbitmq) + encrypted secret\nqueue-aiops doctor\n```\n\nOr as an OpenClaw plugin, which installs this skill and its MCP server together:\n\n```bash\nopenclaw plugins install clawhub:@zw008/queue-aiops\nopenclaw skills info queue-aiops          # expect: Visible to model: yes\n```\n\nNeeds `uvx` on `PATH`: the MCP server is fetched with uv, pinned to this release.\n\n## When to Use This Skill\n\n- Get a one-shot snapshot (`overview` / `redis_server_info` / `rabbitmq_overview`)\n- Investigate cache memory pressure (`analyze memory`) → cause + action\n  (raise maxmemory vs fix eviction policy vs split big keys)\n- Chase latency (`analyze latency`, `redis slowlog`) → O(N) command patterns,\n  blocked clients, fork/AOF stalls\n- Triage a growing queue (`analyze backlog`, `rabbitmq queues`) → per-queue\n  cause (no consumers / unacked pileup / slow consumers) + watermark alarms\n- Spot connection churn or leaks (`analyze churn`, `redis clients`,\n  `rabbitmq connections`) — clients grouped by source\n- Safely change state: `redis config-set` (undo = prior value), `rabbitmq\n  set-policy`/`delete-policy` (undo = prior policy), `declare-queue`, and the\n  high-risk `purge`/`delete-queue` (dry-run + double confirmation; messages are\n  not restorable)\n\n**Do NOT use when** the target is not a redis/rabbitmq broker — route\nhypervisor, storage, backup, cluster/orchestration, database, network,\nmonitoring-stack, or OT/industrial work to the appropriate other AIops-tools\nskill.\n\n## Related Skills — Skill Routing\n\n| If the user wants… | Use |\n|--------------------|-----|\n| redis / rabbitmq cache & broker ops | **queue-aiops** (this skill) |\n| A non-broker platform (hypervisor, storage, backup, cluster, database, network, monitoring stack, OT edge) | the appropriate **other AIops-tools** skill |\n| Managed cloud queue services / other broker products | out of scope for this tool |\n\n## Common Workflows\n\n### 1. Redis is near maxmemory and starting to evict\n\n1. `queue-aiops doctor` → confirm the broker is reachable and the credential (if any)\n   works before you read numbers off it.\n2. `queue-aiops redis memory` → used vs `maxmemory`, the eviction policy in force, and\n   the fragmentation ratio, straight from `INFO memory`.\n3. `queue-aiops analyze memory --used-pct 85` → ranked findings, each citing its measured\n   number: **noeviction near the limit** (the dangerous one — writes will start failing\n   with OOM rather than evicting), active eviction in progress, fragmentation versus real\n   swapping, and oversized keys.\n4. `queue-aiops redis bigkeys --count 500` → a SCAN-budgeted sample of the largest keys,\n   reported **with its coverage %** so you know how much of the keyspace was actually\n   examined. A low coverage number means \"no big key found\" is not yet an answer.\n5. `queue-aiops redis keyspace` → which database the growth is in, to point the fix at\n   the right workload.\n6. If the policy is the problem: `queue-aiops redis config-get maxmemory*` to read the\n   current values, then\n   `queue-aiops redis config-set maxmemory-policy allkeys-lru --dry-run` and re-run for\n   real (double-confirm; the prior value is captured from `CONFIG GET` as the undo\n   descriptor).\n7. **Failure branch**: switching a cache from `noeviction` to an eviction policy means\n   Redis will start **deleting data** — if that instance is being used as a datastore\n   rather than a cache, this is the wrong fix and you need memory instead. Reverse it\n   immediately with `queue-aiops undo list` → `undo apply <id>`, which restores the\n   **prior** policy rather than a default. Note `config-set` changes the running config\n   only; if it must survive a restart, persist it in the config file too — the undo store\n   cannot help you with a value the broker forgot on its own.\n\n### 2. Redis got slow\n\n1. `queue-aiops redis slowlog --limit 50` → the slowest entries the broker itself\n   recorded.\n2. `queue-aiops analyze latency --slow-us 10000` → the slowlog digested **by command\n   pattern**, with O(N) commands flagged and an incremental variant suggested\n   (`KEYS` → `SCAN`, `SMEMBERS` → `SSCAN`), plus blocked-client counts and fork/AOF stall\n   signals read out of `INFO persistence`.\n3. `queue-aiops redis info` → confirm whether the stalls line up with background saves\n   (a fork stall is a persistence problem, not a query problem).\n4. `queue-aiops redis clients` → who is connected, and how many are blocked;\n   `queue-aiops analyze churn` → whether clients are reconnecting constantly, which shows\n   up as latency but is really a client-configuration bug.\n5. If one client is pathological: `queue-aiops redis kill-client --addr <ip:port>\n   --dry-run` then for real (double-confirm).\n6. **Failure branch**: `kill-client` is **irreversible and records no undo** — a killed\n   connection cannot be un-killed, and a well-behaved client will simply reconnect,\n   which fixes nothing while your kill is audited as a write. If latency does not\n   improve, the cause is more likely the O(N) command pattern from step 2: fix the\n   caller, not the connection. Killing clients in a loop will trip the runaway budget\n   guard.\n\n### 3. A RabbitMQ queue keeps growing\n\n1. `queue-aiops rabbitmq overview` and `queue-aiops rabbitmq nodes` → check first for\n   **memory or disk watermark alarms**, which block every publisher on the node and make\n   every queue look broken at once.\n2. `queue-aiops rabbitmq queues --vhost /` → queues sorted deepest-backlog-first.\n3. `queue-aiops analyze backlog --vhost / --top 20` → the per-queue cause: **no consumers\n   attached**, consumers connected but **not acking** (an unacked pile-up), or a publish\n   rate simply outpacing delivery — each citing the measured counts.\n4. `queue-aiops rabbitmq queue <name>` → that queue's detail: consumer count, ready vs\n   unacked split, and its arguments.\n5. `queue-aiops rabbitmq connections` and `queue-aiops rabbitmq channels` → confirm\n   whether the consumers exist at all, and whether their prefetch is starving throughput.\n6. To cap unbounded growth while the consumer is fixed:\n   `queue-aiops rabbitmq set-policy backlog-cap '^orders\\.' '{\"max-length\": 100000}'\n   --apply-to queues --dry-run`, then re-run for real (reversible — the prior policy is\n   captured for undo).\n7. **Failure branch**: do **not** reach for `rabbitmq purge` as a first response — it is\n   **irreversible, risk=high, and destroys real messages**; if the cause from step 3 was\n   \"no consumers\", those messages are the backlog your consumers still need. Purge only\n   with explicit sign-off, a `--dry-run` read first, and the CLI double confirmation.\n   A `max-length` policy also **drops messages** once the cap is hit — if that is not\n   acceptable, `queue-aiops undo apply <id>` restores the prior policy and the real fix\n   is consumer capacity.\n\n### 4. Retire a queue, reversibly\n\n1. `queue-aiops overview` → the broker-wide picture across configured targets.\n2. `queue-aiops rabbitmq queue <name> --vhost /` → confirm it is genuinely idle: zero\n   consumers, zero ready, zero unacked. A queue with messages is not a queue you retire.\n3. `queue-aiops rabbitmq policies` → check no policy still targets its name pattern, so\n   you are not leaving a dangling rule behind.\n4. `queue-aiops rabbitmq delete-queue <name> --vhost / --dry-run` → preview.\n5. Re-run without `--dry-run` (double-confirm, risk=high) — the write\n   captures the queue's definition first, so the undo descriptor **re-declares exactly\n   that queue** (durability and auto-delete flags included).\n6. `queue-aiops rabbitmq queues` → confirm it is gone and nothing else changed.\n7. **Failure branch**: `queue-aiops undo apply <id>` re-declares the queue from the\n   captured definition — but it restores the queue, **not its messages**, which are gone\n   with it. Bindings created outside this tool are not captured either. If the queue\n   turns out to have been in use, expect to re-create bindings by hand; that asymmetry is\n   why step 2 (proving it is idle) matters more than the undo does.\n\n## Governance & Safety\n\nThe skill delivers reads and writes and records them; it does **not** decide\nwhether a write is permitted. That is your agent's judgement, or the permission\nof the account you connect it with (a Redis ACL user restricted to read\ncommands, a RabbitMQ management user with only the `monitoring` tag — writes\nthen fail at the broker). There is no read-only switch, policy file, or approval\ngate.\n\n- **Audit is the guarantee, and it is not bypassable.** Every operation — MCP\n  and CLI alike — is logged to `~/.queue-aiops/audit.db` (relocatable via\n  `QUEUE_AIOPS_HOME`): params (secrets redacted), result, status, duration, and\n  the risk tier. The CLI writes the same row the MCP path does.\n- `QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional annotations\n  recorded on the audit row (who/why); they are never required and never block.\n- **Runaway guard** — a safety backstop, not authorization: the same call looped\n  in a tight window trips a circuit breaker. Disable with `QUEUE_RUNAWAY_MAX=0`.\n- Writes support `--dry-run` / `dry_run=True` and double confirmation at the CLI;\n  CLI writes execute through the governed twins, so they are audited too.\n- Reversible writes capture the real fetched before-state and record an\n  inverse descriptor; `purge_queue` and `redis_kill_client` are irreversible\n  and record priorState only. `delete_queue`'s undo restores the queue\n  *definition*, never its messages — the descriptor says so.\n- Big-key sampling is SCAN-budgeted (never `KEYS *`); the redis surface is a\n  typed command allow-list; rabbitmq paths are centrally percent-encoded\n  (default vhost `/` included).\n\n## References\n\n- `references/capabilities.md` — full tool + platform + API/command reference\n- `references/cli-reference.md` — CLI command reference\n- `references/setup-guide.md` — onboarding, credentials, and connectivity\n\nFile v0.9.2:_meta.json\n\n{\n  \"ownerId\": \"kn7b067awq2s97bn3d7p5qfhw5827pxc\",\n  \"slug\": \"queue-aiops\",\n  \"version\": \"0.9.2\",\n  \"publishedAt\": 1789224232143\n}\n\nFile v0.9.2:references/agent-guardrails.md\n\n# Agent guardrails — running queue-aiops with a smaller / local model\n\nIf you drive these tools with a local model (Llama, Qwen, Mistral … via Goose,\nOllama, LM Studio, or any OpenAI-compatible runtime), you will get noticeably\nbetter results with a short system prompt. This page gives you one, and — more\nimportantly — tells you which guardrails you **no longer need to write**, because\nthe tool now enforces them itself.\n\nThe distinction matters. A guardrail in a prompt is a request. A guardrail in the\nharness is a guarantee. Anything below that we could move into the harness, we did.\n\n## Authorization is not this tool's job — decide it where it belongs\n\nWhether a write should happen is your decision, or the account's. The tool does\nnot gate it — there is no read-only switch and no approval prompt to configure.\nThe two right places to control read vs write:\n\n- **The account you connect with.** Give the Redis connection an ACL user\n  restricted to read commands, or the RabbitMQ management user only the\n  `monitoring` tag (no `management`/`policymaker`). A write then fails at the\n  broker, which is the only place the permission actually lives — a revoked\n  permission cannot be argued around by a model, but a skill-side flag can.\n- **Your agent's system prompt.** If you want an observe-only session, tell the\n  model not to call the write tools (they are clearly tagged `[WRITE]`).\n\nWhat the tool *does* guarantee is that you can always see what happened:\n\n## What the tool enforces — do not waste prompt budget on these\n\n| You might be tempted to prompt | Why you don't need to |\n|---|---|\n| \"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 `\"\"`. |\n| \"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. |\n| \"Preserve the ordering / tell me what's most urgent\" | `rabbitmq_queue_backlog_rca`, `redis_memory_pressure_rca`, `redis_latency_rca` and `connection_churn_analysis` rank findings worst-first, each carrying the measured number it was based on. Priority is in the payload, not implied by list position. |\n| \"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. |\n| \"Confirm before anything destructive\" | `delete_queue` and `purge_queue` require a `--dry-run`-able preview plus double confirmation at the CLI. |\n| \"Log what you did\" | Every governed call is audited to `~/.queue-aiops/audit.db` regardless of what the model says it did — and the CLI writes the same row the MCP path does, so there is no unaudited entry point. |\n| \"Don't get stuck retrying\" | The runaway guard trips a circuit breaker if the same call is hammered in a tight loop — a stuck agent is stopped rather than left to burn calls and time. |\n\n## What still needs a prompt\n\nThese are model-behaviour problems the harness cannot fix from the outside.\nCopy this into your agent's system prompt:\n\n```text\nYou operate a RabbitMQ broker or a Redis instance through the queue-aiops MCP\ntools.\n\nTOOL USE\n- Before answering any question about the current broker, you MUST call a tool.\n  Never answer from memory or assumption.\n- Actually invoke the tool. Do not describe the call you would make, and do not\n  emit an example JSON response in place of calling it.\n- If a tool call fails, report the real error verbatim. Never fill the gap with\n  a plausible-sounding answer.\n\nREADING RESULTS\n- Read the whole result before concluding. If a result contains a \"truncated\"\n  field that is true, say so and re-run with a higher limit. The slowest command\n  or the deepest queue may be the one just past the cut-off.\n- A null field means the broker did not report that value. Report it as \"not\n  available\" — never infer it.\n- Report values exactly as returned. Redis counters from INFO are cumulative\n  since the instance started — compare rates, never quote a raw total as\n  \"operations today\". SLOWLOG durations are microseconds.\n- \"coveragePct\" on a big-key sample is how much of the keyspace was walked. A\n  large key found in a 3% sample is evidence there are large keys; it is not\n  evidence that it is the largest key. Say which you mean.\n\nSCOPE\n- Separate observation from interpretation. State what the tools returned, then\n  any interpretation, clearly marked as such.\n- A queue with a backlog and zero consumers is a stopped/absent consumer, not a\n  slow broker. Check the consumer count before blaming throughput.\n- Unacked messages piling up is a consumer that is not acknowledging — a\n  different fault from a queue nothing is reading. Do not conflate them.\n- A node memory or disk alarm blocks publishers on the WHOLE broker via flow\n  control, not just the queue you were looking at. Report it as global.\n- Do not confuse a queue with an exchange, a vhost with a queue name, a channel\n  with a connection, or a Redis key with a queue.\n- RabbitMQ and Redis are different systems. Do not suggest a RabbitMQ policy on\n  a Redis target; the platform is in every result.\n```\n\n## Recommended setup for a local model\n\nStart with a connection that *cannot* write, verify, and widen the account's\npermission only when you trust the setup — the destructive operations here\ndestroy data rather than configuration: `purge_queue` discards messages that no\nundo token can bring back.\n\n```bash\n# e.g. connect Redis as an ACL user restricted to read commands, or give the\n# RabbitMQ management user only the `monitoring` tag. Then:\nqueue-aiops doctor\n```\n\nOptionally annotate the audit trail with who is operating and why — recorded on\nevery row, never required:\n\n```bash\nexport QUEUE_AUDIT_APPROVED_BY=\"your.name@example.com\"\nexport QUEUE_AUDIT_RATIONALE=\"draining the dead-letter queue, ticket OPS-881\"\n```\n\n## If your model still struggles\n\nSome behaviours are model-capacity limits rather than prompt problems:\n\n- **Multi-tool workflows time out or drift.** Prefer the RCA tools —\n  `rabbitmq_queue_backlog_rca` correlates queue depth, consumer count, rates and\n  node alarms inside one call, so the model does not have to chain\n  `list_queues`, `list_connections` and `node_health` and keep vhost/queue name\n  pairs straight.\n- **The model ignores later tool results in a long context.** The slowlog and\n  the queue list are the big payloads. Use `--count` / a vhost filter\n  deliberately rather than pulling everything.\n- **The model describes calls instead of making them.** This is usually a\n  runtime/tool-calling-format mismatch, not a prompt problem — check that your\n  client advertises the tools in the format your model was trained on.\n\nFeedback on running this with a specific local model is genuinely useful —\nopen an issue at\n[github.com/AIops-tools/Queue-AIops](https://github.com/AIops-tools/Queue-AIops/issues)\nwith the model, runtime, and what went wrong.\n\nFile v0.9.2:references/capabilities.md\n\n# queue-aiops — full capability reference\n\n## Platforms\n\n| Platform | Protocol | Auth | Default port |\n|----------|----------|------|:---:|\n| `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 |\n| `rabbitmq` | Management HTTP API (`/api/...`) via httpx (30s timeout) | HTTP Basic — management user (needs the `monitoring` or `management` tag) | 15672 |\n\nA name-keyed platform registry (`queue_aiops/platform.py`) maps each target's\n`platform` field to its protocol shape. New broker families are additive\nregistry entries — the ops/CLI/MCP layers don't change.\n\n### redis command surface (typed allow-list — no generic passthrough)\n\n`PING`, `INFO [section]`, `SLOWLOG GET`, `CLIENT LIST`, `CLIENT KILL ID/ADDR`,\n`CONFIG GET`, `CONFIG SET`, `MEMORY STATS`, `MEMORY USAGE`, `SCAN`\n(budgeted), `DBSIZE`. Never `KEYS *`.\n\nBig-key sampling budget (named constants in `ops/redis_reads.py`):\n`SCAN_BUDGET_KEYS=10000`, `SCAN_PAGE=500`, `MEMORY_SAMPLE_MAX=200`,\n`TOP_KEYS=20`. `coveragePct` reports how partial the walk was.\n\n### rabbitmq management-API paths (all interpolated segments percent-encoded)\n\n`/api/overview`, `/api/nodes`, `/api/whoami`, `/api/queues[/{vhost}[/{name}]]`,\n`/api/queues/{vhost}/{name}/contents` (purge), `/api/connections`,\n`/api/channels`, `/api/consumers`, `/api/policies[/{vhost}[/{name}]]`.\nThe default vhost `/` is sent as `%2F`.\n\n## Tools (28)\n\n### Overview (1)\n\n| Tool | Returns |\n|------|---------|\n| `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. |\n\n### redis reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `redis_server_info` | version, mode, role, uptime, clients, blocked clients, ops/sec, hit rate |\n| `redis_memory_stats` | usedBytes vs maxmemoryBytes (+ usedPctOfMax), maxmemory policy, fragmentation ratio, RSS/peak, key count |\n| `redis_clients` | clients (bounded 200) + grouped `bySource` (ip without port), busiest first |\n| `redis_slowlog(count?)` | slowlog entries, slowest first (durationUs, command folded to one string) |\n| `redis_config_get(pattern?)` | CONFIG GET glob → sorted parameter map |\n| `redis_keyspace` | per-db keys/expires/avgTtl + expiry coverage % |\n| `redis_big_keys(top?)` | SCAN-budgeted big-key sample, largest first, with budget + coveragePct |\n\n### rabbitmq reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `rabbitmq_overview` | version, cluster, queue/message totals, object counts, publish/deliver/ack rates, connection/channel churn rates |\n| `list_queues(vhost?)` | queues deepest-backlog first: messages/ready/unacked, consumers, rates, memory |\n| `queue_detail(vhost, name)` | one queue: counts, rates, durable/auto_delete/arguments, node, consumer utilisation |\n| `list_connections` | connections + grouped `byPeerHost` (connection + channel counts) |\n| `list_channels` | channels most-unacked first: unacked, prefetch, consumer count |\n| `list_policies(vhost?)` | policies: pattern, apply-to, priority, definition |\n| `node_health` | per node: mem used/limit + alarm, disk free/limit + alarm, fd/socket usage |\n\n### Flagship analyses (4) — transparent heuristics, injectable telemetry\n\n| Tool | Thresholds (named constants) | Verdicts |\n|------|------------------------------|----------|\n| `redis_memory_pressure_rca(used_pct?, telemetry?)` | `DEFAULT_USED_PCT=85`, `FRAG_HIGH_RATIO=1.5`, `FRAG_SWAP_RATIO=0.8`, `BIG_KEY_MIN_BYTES=10MiB` | noeviction near limit (writes will OOM) / eviction pressure / active eviction / fragmentation / likely swapping / oversized sampled keys |\n| `redis_latency_rca(slow_us?, telemetry?)` | `SLOW_US=10000`, `FORK_STALL_US=100000`, heavy-command set (O(N)/blocking) | slow command patterns (heavy ones get an incremental-variant action) / blocked clients / fork stall / delayed AOF fsync / persistence job running / dataset loading |\n| `rabbitmq_queue_backlog_rca(vhost?, top?, queues?, nodes?)` | `BACKLOG_MIN_MESSAGES=1000`, `UNACKED_PCT_HIGH=50`, `RATE_DEFICIT_FACTOR=1.2` | per queue: no consumers / unacked pileup / publish outpaces delivery / residual backlog; global: memory & disk watermark alarms (publishers blocked) |\n| `connection_churn_analysis(snapshot?, history?)` | `CHURN_RATE_HIGH=1/s`, `CHANNELS_PER_CONN_HIGH=20`, `REDIS_CONN_RATE_HIGH=5/s` | redis: reconnect-per-operation churn, maxclients rejections; rabbitmq: connection churn, channel-leak ratio, growth vs a prior snapshot; both: clients grouped by source |\n\nAll four accept injected telemetry for pure analysis (no live pull), and every\nfinding carries `cause`, `action`, and `evidence` numbers.\n\n### Governed writes (7)\n\n| Tool | Risk | Prior state captured | Undo |\n|------|:---:|----------------------|------|\n| `redis_config_set(parameter, value)` | medium | prior value via CONFIG GET (param name validated) | set the prior value back |\n| `redis_kill_client(client_id?/addr?)` | medium | the client's CLIENT LIST row (who/where/last command) | none — connection gone (clients reconnect) |\n| `declare_queue(vhost, name, durable?, auto_delete?, arguments?)` | medium | whether the queue existed | delete the queue — only when newly created |\n| `set_policy(vhost, name, pattern, definition, priority?, apply_to?)` | medium | the prior policy (or \"did not exist\") | restore prior policy, or delete-if-new |\n| `delete_policy(vhost, name)` | medium | the policy's full definition | re-create the captured policy |\n| `purge_queue(vhost, name)` | **high** | message count about to be destroyed | none — messages unrecoverable |\n| `delete_queue(vhost, name)` | **high** | full queue definition + message count | re-declare the captured definition (**messages NOT restored**) |\n\nEvery write takes `dry_run` (MCP) / `--dry-run` + double-confirm (CLI); the two\nhigh-risk writes (`purge_queue`, `delete_queue`) are gated by that same dry-run\npreview + double confirmation at the CLI, nothing more.\n\n### Undo (2)\n\n| Tool | Returns |\n|------|---------|\n| `undo_list(limit?)` | recorded undo descriptors, newest first, with their `_undo_id` |\n| `undo_apply(undo_id, dry_run?)` | replays the recorded inverse (governed like any other write) |\n\n## Environment variables\n\n| Variable | Purpose |\n|----------|---------|\n| `QUEUE_AIOPS_HOME` | Relocate `~/.queue-aiops` (audit/undo/config state) |\n| `QUEUE_AIOPS_CONFIG` | Explicit config.yaml path for the MCP server |\n| `QUEUE_AIOPS_MASTER_PASSWORD` | Unlock the encrypted secret store non-interactively |\n| `QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` | Optional approver/rationale annotations recorded on the audit row |\n| `QUEUE_MAX_TOOL_CALLS` / `QUEUE_MAX_TOOL_SECONDS` | Budget ceilings |\n| `QUEUE_RUNAWAY_MAX` / `QUEUE_RUNAWAY_WINDOW_SEC` | Runaway-loop breaker tuning |\n| `QUEUE_<TARGET>_SECRET` | Legacy plaintext secret fallback (deprecated) |\n\nFile v0.9.2:references/cli-reference.md\n\n# queue-aiops — CLI reference\n\nAll read commands print JSON. All write commands support `--dry-run` and\ndouble-confirm before executing through the governed MCP twins (audited).\n`--target/-t <name>` selects a target from config; omitted = the first target.\n\n## Top level\n\n```bash\nqueue-aiops init                 # onboarding wizard (targets + encrypted secrets)\nqueue-aiops doctor [--skip-auth] # config/secret/connectivity check (PING / /api/overview)\nqueue-aiops overview [-t T]      # one-shot health summary (platform-dispatched)\nqueue-aiops mcp                  # run the MCP server (stdio)\n```\n\n## Secrets\n\n```bash\nqueue-aiops secret set <target>    # add/update an encrypted secret\nqueue-aiops secret list            # names only — values are never printed\nqueue-aiops secret rm <target>\nqueue-aiops secret migrate         # legacy .env / env vars → encrypted store\nqueue-aiops secret rotate-password\n```\n\n## redis\n\n```bash\nqueue-aiops redis info                      # version, role, clients, ops/sec, hit rate\nqueue-aiops redis memory                    # used vs maxmemory, policy, fragmentation\nqueue-aiops redis clients                   # clients grouped by source\nqueue-aiops redis slowlog [-n 128]          # slowest entries first\nqueue-aiops redis config-get \"maxmemory*\"   # CONFIG GET glob\nqueue-aiops redis keyspace                  # per-db keys + expiry coverage\nqueue-aiops redis bigkeys [--top 20]        # SCAN-budgeted big-key sample\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops redis config-set maxmemory-policy allkeys-lru [--dry-run]\nqueue-aiops redis kill-client --id 77 [--dry-run]\nqueue-aiops redis kill-client --addr 10.0.0.5:5000 [--dry-run]\n```\n\n## rabbitmq\n\n```bash\nqueue-aiops rabbitmq overview                    # totals + rates + churn\nqueue-aiops rabbitmq queues [--vhost /]          # deepest backlog first\nqueue-aiops rabbitmq queue <name> [--vhost /]    # one queue's detail\nqueue-aiops rabbitmq connections                 # grouped by peer host\nqueue-aiops rabbitmq channels                    # most unacked first\nqueue-aiops rabbitmq policies [--vhost /]\nqueue-aiops rabbitmq nodes                       # memory/disk/fd + alarms\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops rabbitmq declare-queue <name> [--vhost /] [--durable/--transient] [--auto-delete]\nqueue-aiops rabbitmq purge <name> [--vhost /] [--dry-run]          # HIGH risk\nqueue-aiops rabbitmq delete-queue <name> [--vhost /] [--dry-run]   # HIGH risk\nqueue-aiops rabbitmq set-policy <name> '<pattern>' '{\"max-length\": 100000}' \\\n    [--vhost /] [--priority 0] [--apply-to queues] [--dry-run]\nqueue-aiops rabbitmq delete-policy <name> [--vhost /] [--dry-run]\n```\n\n`QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional — set them to\nrecord who ran a write and why on the audit row (never required, never block):\n\n```bash\nexport QUEUE_AUDIT_APPROVED_BY=\"alice\"\nexport QUEUE_AUDIT_RATIONALE=\"INC-1234: drain the poison-message queue\"\n```\n\n## analyze (flagship RCAs)\n\n```bash\nqueue-aiops analyze memory  [--used-pct 85]   # redis memory-pressure RCA\nqueue-aiops analyze latency [--slow-us 10000] # redis latency/slowlog RCA\nqueue-aiops analyze backlog [--vhost /] [--top 20]  # rabbitmq queue-backlog RCA\nqueue-aiops analyze churn                     # connection churn (both platforms)\n```\n\nFile v0.9.2:references/setup-guide.md\n\n# queue-aiops — setup guide\n\n## 1. Install\n\n```bash\nuv tool install queue-aiops     # or: pipx install queue-aiops / pip install queue-aiops\n```\n\nPython >= 3.11.\n\n## 2. Prepare the brokers\n\n### redis\n\nAny reachable redis 5.x–7.x instance works. Auth is optional:\n\n- **No password (lab)**: nothing to prepare — the wizard accepts an empty\n  password and connects without `AUTH`.\n- **Password**: the value of `requirepass` (or an ACL user's password). TLS\n  deployments (`rediss://`) are supported via the wizard's TLS prompt.\n\nThe tool only ever issues a typed allow-list of commands (INFO, SLOWLOG,\nCLIENT, CONFIG, MEMORY, SCAN, DBSIZE, PING) — reads are safe on production,\nand key sampling is SCAN-budgeted, never `KEYS *`.\n\n### rabbitmq\n\nEnable the management plugin and create (or reuse) a user with at least the\n`monitoring` tag (reads) — the `management`/`policymaker` tag is needed for\npolicy writes, and queue purge/delete needs configure permission on the vhost:\n\n```bash\nrabbitmq-plugins enable rabbitmq_management\nrabbitmqctl add_user queueops 'a-strong-password'\nrabbitmqctl set_user_tags queueops monitoring\nrabbitmqctl set_permissions -p / queueops \"\" \"\" \".*\"   # read-only example\n```\n\nThe management API listens on 15672 (HTTP) / 15671 (HTTPS) by default.\n\n## 3. Onboard\n\n```bash\nqueue-aiops init\n```\n\nThe wizard asks for:\n\n1. **Master password** — encrypts `~/.queue-aiops/secrets.enc` (Fernet +\n   scrypt). Export `QUEUE_AIOPS_MASTER_PASSWORD` for non-interactive/MCP use.\n2. **Targets** — name, platform (`redis`/`rabbitmq`), host, port (defaults\n   6379/15672), redis db index, TLS (verify defaults to **true**; answer No\n   for self-signed lab certs), rabbitmq management user, and the secret\n   (hidden prompt; empty = auth-less redis).\n3. It offers to run `doctor` to confirm connectivity right away.\n\nConfig lands in `~/.queue-aiops/config.yaml`:\n\n```yaml\ntargets:\n  - name: cache1\n    platform: redis\n    host: 10.0.0.10\n    port: 6379\n    username: \"\"\n    db: 0\n    use_tls: false\n    verify_ssl: true\n  - name: broker1\n    platform: rabbitmq\n    host: 10.0.0.20\n    port: 15672\n    username: queueops\n    db: 0\n    use_tls: false\n    verify_ssl: true\n```\n\n## 4. Verify\n\n```bash\nqueue-aiops doctor\n```\n\nChecks config, the encrypted store (and its 600 permissions), per-target\nsecrets (a missing redis secret is a *warning* — auth-less lab mode), and live\nconnectivity: `PING` for redis, `GET /api/overview` for rabbitmq. Exit code 0\n= healthy.\n\n## 5. Wire up MCP\n\n```json\n{\n  \"mcpServers\": {\n    \"queue-aiops\": {\n      \"command\": \"uvx\",\n      \"args\": [\"--from\", \"queue-aiops\", \"queue-aiops-mcp\"],\n      \"env\": {\n        \"QUEUE_AIOPS_MASTER_PASSWORD\": \"your-master-password\"\n      }\n    }\n  }\n}\n```\n\nMCP clients start the server with a minimal environment — put everything it\nneeds (`QUEUE_AIOPS_MASTER_PASSWORD`, a relocated `QUEUE_AIOPS_HOME`, and any\noptional `QUEUE_AUDIT_APPROVED_BY`/`QUEUE_AUDIT_RATIONALE` audit annotations) in\nthat `env` block.\n\n## Troubleshooting\n\n| Symptom | Fix |\n|---------|-----|\n| `No secret for target 'x'` | `queue-aiops secret set x` or re-run `init` (redis targets may legitimately have none) |\n| Redis `AUTH` errors | The stored password is wrong — `queue-aiops secret set <target>` |\n| 401/403 from the management API | Wrong user/password, or the user lacks the `monitoring`/`management` tag or vhost access |\n| 404 on a queue/policy | Stale name, or the vhost is wrong — remember the default vhost is `/` |\n| Write rejected by the broker | The connecting user lacks configure/write permission (or the Redis ACL forbids the command) — grant it, or connect a user that has it |\n| Master-password prompt in MCP | Export `QUEUE_AIOPS_MASTER_PASSWORD` in the MCP `env` block |\n\nFile v0.9.2:skill-card.md\n\n## Description:\n\nQueue AIops helps agents operate Redis caches and RabbitMQ brokers with read diagnostics, transparent RCA workflows, governed broker writes, audit logging, and undo support where available.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[zw008](https://clawhub.ai/user/zw008)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, SREs, and operations engineers use this skill to inspect Redis and RabbitMQ health, triage memory, latency, backlog, and churn issues, and run audited broker changes when authorized.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can perform destructive Redis and RabbitMQ administration actions without an enforceable approval or read-only gate.\n\nMitigation: Install with least-privilege broker accounts first, expose write tools only in supervised sessions, and require operator review before destructive actions.\n\nRisk: Queue purge, queue deletion, and client kill operations can cause data loss or service disruption that undo records cannot fully reverse.\n\nMitigation: Use dry-run previews, confirm the target queue or client from live broker data, and keep destructive operations limited to sessions with an accountable human operator.\n\nRisk: Broker credentials and master passwords can expose production queues or caches if shared broadly.\n\nMitigation: Avoid putting the master password in shared config, use read-only credentials where possible, pin the reviewed package version, and enable TLS for non-local brokers.\n\n## Reference(s):\n\n- [Queue AIops ClawHub page](https://clawhub.ai/zw008/skills/queue-aiops)\n- [Queue AIops homepage](https://github.com/AIops-tools/Queue-AIops)\n- [Capabilities reference](references/capabilities.md)\n- [CLI reference](references/cli-reference.md)\n- [Setup guide](references/setup-guide.md)\n- [Agent guardrails](references/agent-guardrails.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with inline shell commands and JSON-like broker observations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include broker observations, RCA findings, dry-run write plans, audit context, and undo guidance.]\n\n## Skill Version(s):\n\n0.9.2 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.9.1: 7 files, 19975 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2925b), SKILL.md (17459b), _meta.json (130b)\n\nFile v0.9.1:SKILL.md\n\n---\nname: queue-aiops\nslug: queue-aiops\ndisplayName: \"Queue AIops\"\nsummary: \"Governed redis + rabbitmq ops: memory/latency/backlog/churn RCA, policies. 28 tools.\"\nlicense: MIT\nhomepage: https://github.com/AIops-tools/Queue-AIops\ntags: [aiops, mcp, governance, queue]\ndescription: >\n  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).\n  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.\n  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.\n  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.\ninstaller:\n  kind: uv\n  package: queue-aiops\nargument-hint: \"[a queue/key/client id, or describe your cache/broker task]\"\nallowed-tools:\n  - Bash\nmetadata: {\"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\"]}}\ncompatibility: >\n  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.\n  All write operations are audited to a local SQLite DB under ~/.queue-aiops/ (relocatable via QUEUE_AIOPS_HOME).\n  Credentials: the redis password (optional) or the rabbitmq management password is stored ENCRYPTED in ~/.queue-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'queue-aiops init' to onboard (it asks for the platform), or 'queue-aiops secret set <target>' to add one. The store is unlocked by a master password from QUEUE_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var QUEUE_<TARGET_NAME_UPPER>_SECRET is still honoured as a fallback with a deprecation warning (migrate with 'queue-aiops secret migrate'). The secret is presented as AUTH at connect time (redis) or HTTP Basic auth (rabbitmq) and held only in memory; secrets are never logged or echoed.\n  State-changing operations pass through the @governed_tool decorator (budget guard + audit + risk-tier labelling). purge_queue and delete_queue are risk=high with dry_run + double confirmation at the CLI; purge is irreversible (priorState = the message count about to be destroyed), and delete_queue's undo re-declares the captured queue definition — the messages are NOT restored. Reversible writes (redis_config_set, set_policy, delete_policy, declare_queue) capture the real fetched before-state and record an inverse undo descriptor.\n  Safety: the redis surface is a typed command allow-list (no generic passthrough) and big-key sampling is SCAN-based under a hard budget — never KEYS *. rabbitmq path segments (queue/policy names and the default vhost '/') are percent-encoded centrally.\n  Webhooks: none — no outbound network calls beyond the configured redis instances / rabbitmq management API.\n  Transitive dependencies: the redis Python client, httpx (HTTP client), and the MCP SDK. No post-install scripts or background services.\n---\n\n# Queue AIops\n\n> **Disclaimer**: Community-maintained open-source project, **not affiliated with, endorsed by, or sponsored by the Redis or RabbitMQ projects or their respective owners.** Redis and RabbitMQ are trademarks of their respective owners. Source at [github.com/AIops-tools/Queue-AIops](https://github.com/AIops-tools/Queue-AIops) under the MIT license.\n\nGoverned broker operations — **28 MCP tools** across **redis** (RESP client) and\n**rabbitmq** (management HTTP API), every one wrapped with the bundled\n`@governed_tool` harness: a local unified audit log under `~/.queue-aiops/`,\npolicy engine, token/runaway budget guard, undo-token recording, and\ndescriptive risk tiers. A per-target `platform` field selects the\nprotocol shape, so one config can span a mixed estate. The redis password /\nrabbitmq management password is stored **encrypted**\n(`~/.queue-aiops/secrets.enc`, Fernet + scrypt) — never plaintext on disk.\n\n> **Standalone**: the governance harness is bundled in the package\n> (`queue_aiops.governance`) — no external skill-family dependency. Behaviour is\n> covered by a mock-based test suite; `docs/VERIFICATION.md` is the checklist for a\n> live run (both platforms are free/self-hostable, so a lab container is enough).\n\n## What This Skill Does\n\n| Group | Tools | Count | R/W |\n|-------|-------|:-----:|:---:|\n| **Overview** | queue_overview | 1 | read |\n| **redis** | redis_server_info, redis_memory_stats, redis_clients, redis_slowlog, redis_config_get, redis_keyspace, redis_big_keys | 7 | read |\n| **rabbitmq** | rabbitmq_overview, list_queues, queue_detail, list_connections, list_channels, list_policies, node_health | 7 | read |\n| **Flagship analyses** | redis_memory_pressure_rca, redis_latency_rca, rabbitmq_queue_backlog_rca, connection_churn_analysis | 4 | read |\n| **Writes** | redis_config_set, redis_kill_client, declare_queue, set_policy, delete_policy | 5 | write (med) |\n| **Writes** | purge_queue, delete_queue | 2 | write (**high**) |\n| **Undo** | undo_list, undo_apply | 2 | read / write |\n\nThe four flagship analyses are transparent heuristics that report their numbers,\nnever a black-box verdict: `redis_memory_pressure_rca` reads used-vs-maxmemory +\neviction policy + fragmentation + the big-key sample into a cause + action;\n`redis_latency_rca` digests the SLOWLOG by command pattern and adds fork/AOF\nstall signals; `rabbitmq_queue_backlog_rca` classifies each deep queue (no\nconsumers / unacked pileup / rate deficit) and reports watermark alarms that\nblock all publishers; `connection_churn_analysis` works on both platforms and\npins churn to client sources.\n\n## Quick Install\n\n```bash\nuv tool install queue-aiops\nqueue-aiops init       # wizard: pick platform (redis/rabbitmq) + encrypted secret\nqueue-aiops doctor\n```\n\nOr as an OpenClaw plugin, which installs this skill and its MCP server together:\n\n```bash\nopenclaw plugins install clawhub:@aiops-tools/queue-aiops\nopenclaw skills info queue-aiops          # expect: Visible to model: yes\n```\n\nNeeds `uvx` on `PATH`: the MCP server is fetched with uv, pinned to this release.\n\n## When to Use This Skill\n\n- Get a one-shot snapshot (`overview` / `redis_server_info` / `rabbitmq_overview`)\n- Investigate cache memory pressure (`analyze memory`) → cause + action\n  (raise maxmemory vs fix eviction policy vs split big keys)\n- Chase latency (`analyze latency`, `redis slowlog`) → O(N) command patterns,\n  blocked clients, fork/AOF stalls\n- Triage a growing queue (`analyze backlog`, `rabbitmq queues`) → per-queue\n  cause (no consumers / unacked pileup / slow consumers) + watermark alarms\n- Spot connection churn or leaks (`analyze churn`, `redis clients`,\n  `rabbitmq connections`) — clients grouped by source\n- Safely change state: `redis config-set` (undo = prior value), `rabbitmq\n  set-policy`/`delete-policy` (undo = prior policy), `declare-queue`, and the\n  high-risk `purge`/`delete-queue` (dry-run + double confirmation; messages are\n  not restorable)\n\n**Do NOT use when** the target is not a redis/rabbitmq broker — route\nhypervisor, storage, backup, cluster/orchestration, database, network,\nmonitoring-stack, or OT/industrial work to the appropriate other AIops-tools\nskill.\n\n## Related Skills — Skill Routing\n\n| If the user wants… | Use |\n|--------------------|-----|\n| redis / rabbitmq cache & broker ops | **queue-aiops** (this skill) |\n| A non-broker platform (hypervisor, storage, backup, cluster, database, network, monitoring stack, OT edge) | the appropriate **other AIops-tools** skill |\n| Managed cloud queue services / other broker products | out of scope for this tool |\n\n## Common Workflows\n\n### 1. Redis is near maxmemory and starting to evict\n\n1. `queue-aiops doctor` → confirm the broker is reachable and the credential (if any)\n   works before you read numbers off it.\n2. `queue-aiops redis memory` → used vs `maxmemory`, the eviction policy in force, and\n   the fragmentation ratio, straight from `INFO memory`.\n3. `queue-aiops analyze memory --used-pct 85` → ranked findings, each citing its measured\n   number: **noeviction near the limit** (the dangerous one — writes will start failing\n   with OOM rather than evicting), active eviction in progress, fragmentation versus real\n   swapping, and oversized keys.\n4. `queue-aiops redis bigkeys --count 500` → a SCAN-budgeted sample of the largest keys,\n   reported **with its coverage %** so you know how much of the keyspace was actually\n   examined. A low coverage number means \"no big key found\" is not yet an answer.\n5. `queue-aiops redis keyspace` → which database the growth is in, to point the fix at\n   the right workload.\n6. If the policy is the problem: `queue-aiops redis config-get maxmemory*` to read the\n   current values, then\n   `queue-aiops redis config-set maxmemory-policy allkeys-lru --dry-run` and re-run for\n   real (double-confirm; the prior value is captured from `CONFIG GET` as the undo\n   descriptor).\n7. **Failure branch**: switching a cache from `noeviction` to an eviction policy means\n   Redis will start **deleting data** — if that instance is being used as a datastore\n   rather than a cache, this is the wrong fix and you need memory instead. Reverse it\n   immediately with `queue-aiops undo list` → `undo apply <id>`, which restores the\n   **prior** policy rather than a default. Note `config-set` changes the running config\n   only; if it must survive a restart, persist it in the config file too — the undo store\n   cannot help you with a value the broker forgot on its own.\n\n### 2. Redis got slow\n\n1. `queue-aiops redis slowlog --limit 50` → the slowest entries the broker itself\n   recorded.\n2. `queue-aiops analyze latency --slow-us 10000` → the slowlog digested **by command\n   pattern**, with O(N) commands flagged and an incremental variant suggested\n   (`KEYS` → `SCAN`, `SMEMBERS` → `SSCAN`), plus blocked-client counts and fork/AOF stall\n   signals read out of `INFO persistence`.\n3. `queue-aiops redis info` → confirm whether the stalls line up with background saves\n   (a fork stall is a persistence problem, not a query problem).\n4. `queue-aiops redis clients` → who is connected, and how many are blocked;\n   `queue-aiops analyze churn` → whether clients are reconnecting constantly, which shows\n   up as latency but is really a client-configuration bug.\n5. If one client is pathological: `queue-aiops redis kill-client --addr <ip:port>\n   --dry-run` then for real (double-confirm).\n6. **Failure branch**: `kill-client` is **irreversible and records no undo** — a killed\n   connection cannot be un-killed, and a well-behaved client will simply reconnect,\n   which fixes nothing while your kill is audited as a write. If latency does not\n   improve, the cause is more likely the O(N) command pattern from step 2: fix the\n   caller, not the connection. Killing clients in a loop will trip the runaway budget\n   guard.\n\n### 3. A RabbitMQ queue keeps growing\n\n1. `queue-aiops rabbitmq overview` and `queue-aiops rabbitmq nodes` → check first for\n   **memory or disk watermark alarms**, which block every publisher on the node and make\n   every queue look broken at once.\n2. `queue-aiops rabbitmq queues --vhost /` → queues sorted deepest-backlog-first.\n3. `queue-aiops analyze backlog --vhost / --top 20` → the per-queue cause: **no consumers\n   attached**, consumers connected but **not acking** (an unacked pile-up), or a publish\n   rate simply outpacing delivery — each citing the measured counts.\n4. `queue-aiops rabbitmq queue <name>` → that queue's detail: consumer count, ready vs\n   unacked split, and its arguments.\n5. `queue-aiops rabbitmq connections` and `queue-aiops rabbitmq channels` → confirm\n   whether the consumers exist at all, and whether their prefetch is starving throughput.\n6. To cap unbounded growth while the consumer is fixed:\n   `queue-aiops rabbitmq set-policy backlog-cap '^orders\\.' '{\"max-length\": 100000}'\n   --apply-to queues --dry-run`, then re-run for real (reversible — the prior policy is\n   captured for undo).\n7. **Failure branch**: do **not** reach for `rabbitmq purge` as a first response — it is\n   **irreversible, risk=high, and destroys real messages**; if the cause from step 3 was\n   \"no consumers\", those messages are the backlog your consumers still need. Purge only\n   with explicit sign-off, a `--dry-run` read first, and the CLI double\n\nArchive v0.9.0: 7 files, 19733 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2768b), SKILL.md (17149b), _meta.json (130b)\n\nArchive v0.8.0: 7 files, 19739 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2636b), SKILL.md (17251b), _meta.json (130b)\n\nArchive v0.7.0: 7 files, 19730 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2646b), SKILL.md (17251b), _meta.json (130b)\n\nArchive v0.6.0: 7 files, 19712 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2683b), SKILL.md (17251b), _meta.json (130b)\n\nArchive v0.5.0: 7 files, 19671 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2728b), SKILL.md (17251b), _meta.json (130b)\n\nArchive v0.4.0: 7 files, 19661 bytes\n\nFiles: references/agent-guardrails.md (7352b), references/capabilities.md (7112b), references/cli-reference.md (3389b), references/setup-guide.md (3760b), skill-card.md (2555b), SKILL.md (17251b), _meta.json (130b)","readmeExcerpt":"Skill: queue-aiops Owner: zw008 Summary: 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 flag","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"uv tool install queue-aiops\nqueue-aiops init       # wizard: pick platform (redis/rabbitmq) + encrypted secret\nqueue-aiops doctor"},{"language":"bash","snippet":"openclaw plugins install clawhub:@zw008/queue-aiops\nopenclaw skills info queue-aiops          # expect: Visible to model: yes"},{"language":"text","snippet":"You operate a RabbitMQ broker or a Redis instance through the queue-aiops MCP\ntools.\n\nTOOL USE\n- Before answering any question about the current broker, you MUST call a tool.\n  Never answer from memory or assumption.\n- Actually invoke the tool. Do not describe the call you would make, and do not\n  emit an example JSON response in place of calling it.\n- If a tool call fails, report the real error verbatim. Never fill the gap with\n  a plausible-sounding answer.\n\nREADING RESULTS\n- Read the whole result before concluding. If a result contains a \"truncated\"\n  field that is true, say so and re-run with a higher limit. The slowest command\n  or the deepest queue may be the one just past the cut-off.\n- A null field means the broker did not report that value. Report it as \"not\n  available\" — never infer it.\n- Report values exactly as returned. Redis counters from INFO are cumulative\n  since the instance started — compare rates, never quote a raw total as\n  \"operations today\". SLOWLOG durations are microseconds.\n- \"coveragePct\" on a big-key sample is how much of the keyspace was walked. A\n  large key found in a 3% sample is evidence there are large keys; it is not\n  evidence that it is the largest key. Say which you mean.\n\nSCOPE\n- Separate observation from interpretation. State what the tools returned, then\n  any interpretation, clearly marked as such.\n- A queue with a backlog and zero consumers is a stopped/absent consumer, not a\n  slow broker. Check the consumer count before blaming throughput.\n- Unacked messages piling up is a consumer that is not acknowledging — a\n  different fault from a queue nothing is reading. Do not conflate them.\n- A node memory or disk alarm blocks publishers on the WHOLE broker via flow\n  control, not just the queue you were looking at. Report it as global.\n- Do not confuse a queue with an exchange, a vhost with a queue name, a channel\n  with a connection, or a Redis key with a queue.\n- RabbitMQ and Redis are different systems. Do not suggest a Rab"},{"language":"bash","snippet":"# e.g. connect Redis as an ACL user restricted to read commands, or give the\n# RabbitMQ management user only the `monitoring` tag. Then:\nqueue-aiops doctor"},{"language":"bash","snippet":"export QUEUE_AUDIT_APPROVED_BY=\"your.name@example.com\"\nexport QUEUE_AUDIT_RATIONALE=\"draining the dead-letter queue, ticket OPS-881\""},{"language":"bash","snippet":"queue-aiops init                 # onboarding wizard (targets + encrypted secrets)\nqueue-aiops doctor [--skip-auth] # config/secret/connectivity check (PING / /api/overview)\nqueue-aiops overview [-t T]      # one-shot health summary (platform-dispatched)\nqueue-aiops mcp                  # run the MCP server (stdio)"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: queue-aiops\nslug: queue-aiops\ndisplayName: \"Queue AIops\"\nsummary: \"Governed redis + rabbitmq ops: memory/latency/backlog/churn RCA, policies. 28 tools.\"\nlicense: MIT\nhomepage: https://github.com/AIops-tools/Queue-AIops\ntags: [aiops, mcp, governance, queue]\ndescription: >\n  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).\n  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.\n  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.\n  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.\ninstaller:\n  kind: uv\n  package: queue-aiops\nargument-hint: \"[a queue/key/client id, or describe your cache/broker task]\"\nallowed-tools:\n  - Bash\nmetadata: {\"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\"]}}\ncompatibility: >\n  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.\n  All write operations are audited to a local SQLite DB under ~/.queue-aiops/ (relocatable via QUEUE_AIOPS_HOME).\n  Credentials: the redis password (optional) or the rabbitmq management password is stored ENCRYP"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7b067awq2s97bn3d7p5qfhw5827pxc\",\n  \"slug\": \"queue-aiops\",\n  \"version\": \"0.9.4\",\n  \"publishedAt\": 1789562000585\n}"},{"path":"references/agent-guardrails.md","content":"# Agent guardrails — running queue-aiops with a smaller / local model\n\nIf you drive these tools with a local model (Llama, Qwen, Mistral … via Goose,\nOllama, LM Studio, or any OpenAI-compatible runtime), you will get noticeably\nbetter results with a short system prompt. This page gives you one, and — more\nimportantly — tells you which guardrails you **no longer need to write**, because\nthe tool now enforces them itself.\n\nThe distinction matters. A guardrail in a prompt is a request. A guardrail in the\nharness is a guarantee. Anything below that we could move into the harness, we did.\n\n## Authorization is not this tool's job — decide it where it belongs\n\nWhether a write should happen is your decision, or the account's. The tool does\nnot gate it — there is no read-only switch and no approval prompt to configure.\nThe two right places to control read vs write:\n\n- **The account you connect with.** Give the Redis connection an ACL user\n  restricted to read commands, or the RabbitMQ management user only the\n  `monitoring` tag (no `management`/`policymaker`). A write then fails at the\n  broker, which is the only place the permission actually lives — a revoked\n  permission cannot be argued around by a model, but a skill-side flag can.\n- **Your agent's system prompt.** If you want an observe-only session, tell the\n  model not to call the write tools (they are clearly tagged `[WRITE]`).\n\nWhat the tool *does* guarantee is that you can always see what happened:\n\n## What the tool enforces — do not waste prompt budget on these\n\n| You might be tempted to prompt | Why you don't need to |\n|---|---|\n| \"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 `\"\"`. |\n| \"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. |\n| \"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. |\n| \"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. |\n| \"Confirm before anything destructive\" | `delete_queue` and `purge_queue` require a `--dry-run`-able preview plus double confirmation at the CLI. |\n| \"Log what you did\" | Every governed call is audited to `~/.queue-aiops/audit.db` regardless o"},{"path":"references/capabilities.md","content":"# queue-aiops — full capability reference\n\n## Platforms\n\n| Platform | Protocol | Auth | Default port |\n|----------|----------|------|:---:|\n| `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 |\n| `rabbitmq` | Management HTTP API (`/api/...`) via httpx (30s timeout) | HTTP Basic — management user (needs the `monitoring` or `management` tag) | 15672 |\n\nA name-keyed platform registry (`queue_aiops/platform.py`) maps each target's\n`platform` field to its protocol shape. New broker families are additive\nregistry entries — the ops/CLI/MCP layers don't change.\n\n### redis command surface (typed allow-list — no generic passthrough)\n\n`PING`, `INFO [section]`, `SLOWLOG GET`, `CLIENT LIST`, `CLIENT KILL ID/ADDR`,\n`CONFIG GET`, `CONFIG SET`, `MEMORY STATS`, `MEMORY USAGE`, `SCAN`\n(budgeted), `DBSIZE`. Never `KEYS *`.\n\nBig-key sampling budget (named constants in `ops/redis_reads.py`):\n`SCAN_BUDGET_KEYS=10000`, `SCAN_PAGE=500`, `MEMORY_SAMPLE_MAX=200`,\n`TOP_KEYS=20`. `coveragePct` reports how partial the walk was.\n\n### rabbitmq management-API paths (all interpolated segments percent-encoded)\n\n`/api/overview`, `/api/nodes`, `/api/whoami`, `/api/queues[/{vhost}[/{name}]]`,\n`/api/queues/{vhost}/{name}/contents` (purge), `/api/connections`,\n`/api/channels`, `/api/consumers`, `/api/policies[/{vhost}[/{name}]]`.\nThe default vhost `/` is sent as `%2F`.\n\n## Tools (28)\n\n### Overview (1)\n\n| Tool | Returns |\n|------|---------|\n| `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. |\n\n### redis reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `redis_server_info` | version, mode, role, uptime, clients, blocked clients, ops/sec, hit rate |\n| `redis_memory_stats` | usedBytes vs maxmemoryBytes (+ usedPctOfMax), maxmemory policy, fragmentation ratio, RSS/peak, key count |\n| `redis_clients` | clients (bounded 200) + grouped `bySource` (ip without port), busiest first |\n| `redis_slowlog(count?)` | slowlog entries, slowest first (durationUs, command folded to one string) |\n| `redis_config_get(pattern?)` | CONFIG GET glob → sorted parameter map |\n| `redis_keyspace` | per-db keys/expires/avgTtl + expiry coverage % |\n| `redis_big_keys(top?)` | SCAN-budgeted big-key sample, largest first, with budget + coveragePct |\n\n### rabbitmq reads (7)\n\n| Tool | Returns |\n|------|---------|\n| `rabbitmq_overview` | version, cluster, queue/message totals, object counts, publish/deliver/ack rates, connection/channel churn rates |\n| `list_queues(vhost?)` | queues deepest-backlog first: messages/ready/unacked, consumers, rates, memory |\n| `queue_detail(vhost, name)` | one queue: counts, rates, durable/auto_delet"},{"path":"references/cli-reference.md","content":"# queue-aiops — CLI reference\n\nAll read commands print JSON. All write commands support `--dry-run` and\ndouble-confirm before executing through the governed MCP twins (audited).\n`--target/-t <name>` selects a target from config; omitted = the first target.\n\n## Top level\n\n```bash\nqueue-aiops init                 # onboarding wizard (targets + encrypted secrets)\nqueue-aiops doctor [--skip-auth] # config/secret/connectivity check (PING / /api/overview)\nqueue-aiops overview [-t T]      # one-shot health summary (platform-dispatched)\nqueue-aiops mcp                  # run the MCP server (stdio)\n```\n\n## Secrets\n\n```bash\nqueue-aiops secret set <target>    # add/update an encrypted secret\nqueue-aiops secret list            # names only — values are never printed\nqueue-aiops secret rm <target>\nqueue-aiops secret migrate         # legacy .env / env vars → encrypted store\nqueue-aiops secret rotate-password\n```\n\n## redis\n\n```bash\nqueue-aiops redis info                      # version, role, clients, ops/sec, hit rate\nqueue-aiops redis memory                    # used vs maxmemory, policy, fragmentation\nqueue-aiops redis clients                   # clients grouped by source\nqueue-aiops redis slowlog [-n 128]          # slowest entries first\nqueue-aiops redis config-get \"maxmemory*\"   # CONFIG GET glob\nqueue-aiops redis keyspace                  # per-db keys + expiry coverage\nqueue-aiops redis bigkeys [--top 20]        # SCAN-budgeted big-key sample\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops redis config-set maxmemory-policy allkeys-lru [--dry-run]\nqueue-aiops redis kill-client --id 77 [--dry-run]\nqueue-aiops redis kill-client --addr 10.0.0.5:5000 [--dry-run]\n```\n\n## rabbitmq\n\n```bash\nqueue-aiops rabbitmq overview                    # totals + rates + churn\nqueue-aiops rabbitmq queues [--vhost /]          # deepest backlog first\nqueue-aiops rabbitmq queue <name> [--vhost /]    # one queue's detail\nqueue-aiops rabbitmq connections                 # grouped by peer host\nqueue-aiops rabbitmq channels                    # most unacked first\nqueue-aiops rabbitmq policies [--vhost /]\nqueue-aiops rabbitmq nodes                       # memory/disk/fd + alarms\n\n# writes (dry-run + double-confirm; audited via the governed twins)\nqueue-aiops rabbitmq declare-queue <name> [--vhost /] [--durable/--transient] [--auto-delete]\nqueue-aiops rabbitmq purge <name> [--vhost /] [--dry-run]          # HIGH risk\nqueue-aiops rabbitmq delete-queue <name> [--vhost /] [--dry-run]   # HIGH risk\nqueue-aiops rabbitmq set-policy <name> '<pattern>' '{\"max-length\": 100000}' \\\n    [--vhost /] [--priority 0] [--apply-to queues] [--dry-run]\nqueue-aiops rabbitmq delete-policy <name> [--vhost /] [--dry-run]\n```\n\n`QUEUE_AUDIT_APPROVED_BY` / `QUEUE_AUDIT_RATIONALE` are optional — set them to\nrecord who ran a write and why on the audit row (never required, never block):\n\n```bash\nexport QUEUE_AUDIT_APPROVED_BY=\"alice\"\nexport QUEUE_AUDIT_RATIONALE=\"INC-1234: drain t"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2150,"uniquenessScore":41,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T15:46:14.615Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T15:46:14.615Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T21:40:26.018Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"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!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"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","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}