@moon791017/neo-skills 1.1.26 → 1.1.27

package/README.md

@@ -63,6 +63,7 @@
 | Agent 架構 | `neo-sub-agent` | 設計、建立、審查或轉換 sub-agent、custom agent、worker/reviewer/planner agent 或 multi-agent workflow。 |
 | 技能開發 | `generate-skill` | 建立、更新、審查或最佳化 Agent Skill，包含規格、觸發描述、延伸資源、評估資料與設計模式。 |
 | 可觀測性 | `neo-opentelemetry` | 解釋 OpenTelemetry 概念、規劃或審查 Collector 架構與設定、處理維運排障、安全、零程式 instrumentation 及相容性遷移。 |
+| queue | `neo-rabbitmq` | 以 RabbitMQ 4.3 為預設，提供語言中立的訊息拓撲、Broker 營運、監控排障與效能優化指引。 |
 | 文字潤飾 | `neo-stop-slop` | 去除繁中或英文中的 AI 腔、贅詞、公式化句式，支援文件、註解、commit message 與 PR 說明。 |
 | PR 產出 | `neo-pr` | 詢問或自動偵測 Repository 來源與目標分支，擷取變更並產生重點式且去 AI 腔的 PR Title 與 PR Description。 |
 
@@ -156,4 +157,5 @@ npx -p @moon791017/neo-skills install-system-instructions \
 | 建立 Agent 治理 | `neo-harness` | `幫我針對這個專案評估並產生 AGENTS.md` |
 | 建立 sub-agent | `neo-sub-agent` | `幫我新增一個 Codex code-reviewer sub agent` |
 | 規劃 OpenTelemetry | `neo-opentelemetry` | `幫我審查 Collector 架構、韌性、安全與零程式觀測方案` |
+| 設計 RabbitMQ 系統 | `neo-rabbitmq` | `請分析 RabbitMQ Queue 堆積、叢集營運與效能瓶頸` |
 | 去掉 AI 腔 | `neo-stop-slop` | `把這段 PR 說明改得自然、直接一點` |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@moon791017/neo-skills",
-  "version": "1.1.26",
+  "version": "1.1.27",
   "type": "module",
   "description": "Neo Skills: A Universal AI Agent Skills Extension",
   "homepage": "https://neo-blog-iota.vercel.app/",

package/skills/neo-rabbitmq/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: neo-rabbitmq
+description: >
+  Use this skill when a request involves RabbitMQ message-topology design, reliability
+  analysis, Broker operations, cluster or security configuration, monitoring,
+  troubleshooting, or performance optimization. Use stable RabbitMQ 4.3 by default
+  and keep development guidance language-neutral. Do not use this skill for
+  language-specific Client APIs, website implementation, or Blog content.
+compatibility: No runtime is required; verify current RabbitMQ official documentation for version-sensitive commands, configuration defaults, or security behavior.
+metadata:
+  version: "1.0.0"
+  pattern: "tool-wrapper,pipeline"
+  domain: "messaging-operations-performance"
+  default-version: "4.3"
+  source-revision: "2b61ea8d840a42e1ba46ee2f1fdf0f9aeec63bd9"
+---
+
+# Neo RabbitMQ
+
+Use RabbitMQ 4.3 as the default baseline for language-neutral guidance on message design, Broker operations, and performance optimization.
+
+## Scope Boundaries
+
+Cover:
+
+- Development design: protocols, Virtual Hosts, Exchanges, Bindings, Queues, Publishers, Consumers, Acknowledgements, Publisher Confirms, Prefetch, TTL, Dead Lettering, reliability, and queue-type selection.
+- Operations and management: installation, configuration, CLI tools, Management, permissions, TLS, Plugins, Policies, clusters, backups, upgrades, Kubernetes Operator, and production checks.
+- Performance optimization: connection and Channel lifecycles, flow control, memory, disk, CPU, network, queues, Quorum Queues, Streams, monitoring, capacity, and bottleneck isolation.
+- Troubleshooting: connectivity, authentication, routing, consumer backlog, resource alarms, cluster health, and upgrade risks.
+
+Do not cover:
+
+- Client APIs, SDK code, and language-specific tutorials for Java, Python, C#, Go, Ruby, or any other programming language.
+- RabbitMQ website React, Docusaurus, styling, deployment, or other website implementation.
+- RabbitMQ Blog, material outside the documented license scope, and documentation unrelated to the three focus areas.
+- Production operations using rabbitmqadmin publish or rabbitmqadmin get; the source instructions explicitly omit these commands.
+
+If a request crosses the boundary, answer the language-neutral portion and identify the missing language-specific or product-specific documentation. Never invent a Client API.
+
+## Workflow
+
+1. Classify the request as topology design, reliability, routine operations, security, performance, troubleshooting, upgrade, or capacity planning.
+2. Identify the version. Use RabbitMQ 4.3 when no version is specified. For current-version behavior, development releases, release notes, Feature Flags, commands, or configuration defaults, consult current official documentation before answering.
+3. Load only the required references:
+   - Development and message semantics: references/development.md
+   - Operations, management, and upgrades: references/operations.md
+   - Performance, capacity, and monitoring: references/performance.md
+   - Layered troubleshooting: references/troubleshooting.md
+   - Version, sources, and exclusions: references/sources-and-scope.md
+4. Gather evidence before drawing conclusions. At minimum, identify the RabbitMQ version, protocol, Virtual Host, Exchange, Queue type, message size and rate, durability, confirmation mode, Consumer behavior, node count, CPU, RAM, disk, network, and relevant metrics. State when the available data is insufficient.
+5. Separate source facts, recommendations, and inferences. Label inferences explicitly. Do not present a documentation example or single-environment value as a universal default.
+6. Start with non-destructive checks before proposing changes. For configuration changes, deletion, clearing, restart, failover, or upgrade, state the impact, backup, rollback, and verification conditions.
+7. Before using CLI examples, consult the corresponding help output when RabbitMQ tools are available locally. Mark every command with its applicable version and required permissions. Never invent parameters.
+
+## Decision Rules
+
+- Define delivery, ordering, retry, loss, and duplicate-processing semantics before discussing throughput or latency.
+- Treat Publisher Confirms and Consumer Acknowledgements as separate reliability boundaries. Check message persistence together with Queue durability.
+- Select a Queue type based on data safety, replication, ordering, retention, replay, consumption model, and resource characteristics. Never claim that one type is faster for every workload.
+- Prefer long-lived Connections, Channel reuse, Publisher and Consumer separation, avoiding polling, and a controlled number of unconfirmed messages. Do not treat adding Consumers or increasing Prefetch as a universal solution.
+- Treat Resource Alarms and Flow Control as protection mechanisms and bottleneck signals. Find the root cause in memory, disk, consumption rate, writes, replication, or network before changing alarm settings.
+- Use Policies for settings that can be applied dynamically to groups of objects. Handle Queue or Stream types and other creation-time semantics during design and declaration because they cannot be changed afterward.
+- Establish workload-specific monitoring baselines. Without evidence, do not assume fixed thresholds, capacity, ports, defaults, or security status.
+- Prefer least privilege, Virtual Host isolation, TLS, restricted listeners, secret-free examples, and non-public management endpoints in security guidance.
+
+## Response Contracts
+
+### Topology or Development Design
+
+State assumptions, protocol and topology, routing, Queue type, delivery semantics, failure and retry behavior, monitoring metrics, trade-offs, and verification cases. Use concepts, textual topology diagrams, configuration semantics, and protocol fields only. Do not produce Client code in a programming language.
+
+### Operations or Management Runbook
+
+Present impact, prerequisites, read-only checks, change steps, rollback steps, health verification, and follow-up monitoring in that order. For clusters, TLS, permissions, backups, and upgrades, state node scope and risks. Never present one unverified command as the complete procedure.
+
+### Performance Analysis
+
+Start with the baseline and success criteria. Locate the bottleneck across the end-to-end path: publishing, routing, storage, replication, transport, consumption, or application processing. Change one primary variable at a time and explain expected impact, resource cost, and rollback.
+
+### Troubleshooting
+
+Describe symptoms and missing evidence first. Check version and configuration, network and listeners, authentication, clusters, resource alarms, Queues, Publishers, and Consumers in that order. Tie every conclusion to observed evidence and list reproducible verification signals after remediation.
+
+## Fact-Checking Gate
+
+- Use sources-and-scope.md as the default RabbitMQ 4.3 source snapshot. The snapshot is not a substitute for current documentation.
+- Treat versions, Feature Flags, Plugins, CLI syntax, configuration keys, defaults, ports, limits, compatibility, and security advisories as changeable information. Consult current official sources before answering.
+- Do not use RabbitMQ Blog content or turn language examples from tutorials or Client Libraries into assumed universal APIs.
+- For production data, message deletion, Queue clearing, permission changes, node shutdown, or upgrades, require sufficient environment evidence and provide rollback and verification steps.

package/skills/neo-rabbitmq/evals/eval_queries.json

@@ -0,0 +1,82 @@
+[
+  {
+    "query": "Using language-neutral RabbitMQ 4.3 concepts, design the Exchange, Binding, Queue, confirmation, and retry topology for order events.",
+    "should_trigger": true
+  },
+  {
+    "query": "Choose between a general Queue, Quorum Queue, and Stream in RabbitMQ. Analyze the trade-offs for data safety, ordering, replay, and resource use.",
+    "should_trigger": true
+  },
+  {
+    "query": "Explain Publisher Confirms and Consumer Acknowledgements, then design a workflow that handles duplicate delivery.",
+    "should_trigger": true
+  },
+  {
+    "query": "RabbitMQ publishing is occasionally blocked. Plan read-only troubleshooting steps using Memory Alarms, Disk Alarms, Flow Control, and Consumer rate.",
+    "should_trigger": true
+  },
+  {
+    "query": "Plan TLS, Virtual Host, least privilege, Management, and CLI administration for a RabbitMQ 4.3 cluster.",
+    "should_trigger": true
+  },
+  {
+    "query": "A RabbitMQ Queue keeps growing. Use Consumer Capacity, Prefetch, Ack Rate, Redelivery, and disk metrics to locate the bottleneck.",
+    "should_trigger": true
+  },
+  {
+    "query": "Design Prometheus monitoring and a RabbitMQ capacity baseline, including the cost of Per-object metrics.",
+    "should_trigger": true
+  },
+  {
+    "query": "We are preparing a node-by-node RabbitMQ upgrade. List checks for the Upgrade Path, Erlang, Feature Flags, backups, cluster health, and rollback.",
+    "should_trigger": true
+  },
+  {
+    "query": "RabbitMQ Connection and Channel counts keep increasing. Investigate Churn, File Descriptors, memory, and the application lifecycle.",
+    "should_trigger": true
+  },
+  {
+    "query": "Plan Kubernetes storage, TLS, monitoring, upgrades, and failure troubleshooting from the RabbitMQ Operator perspective.",
+    "should_trigger": true
+  },
+  {
+    "query": "Write Python code with pika to create a RabbitMQ Exchange, Queue, and Consumer.",
+    "should_trigger": false
+  },
+  {
+    "query": "Give me a Java RabbitMQ Client Publisher Confirm API example.",
+    "should_trigger": false
+  },
+  {
+    "query": "Implement automatic RabbitMQ reconnect and Prefetch configuration in C#.",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a RabbitMQ Stream Producer using the Go Client.",
+    "should_trigger": false
+  },
+  {
+    "query": "Show me how to modify React components and the Docusaurus Sidebar in the RabbitMQ website.",
+    "should_trigger": false
+  },
+  {
+    "query": "Summarize the latest RabbitMQ Blog post and republish it in full.",
+    "should_trigger": false
+  },
+  {
+    "query": "Compare Kafka Broker partition performance without discussing RabbitMQ.",
+    "should_trigger": false
+  },
+  {
+    "query": "Optimize PostgreSQL indexes and execution plans.",
+    "should_trigger": false
+  },
+  {
+    "query": "Build a general HTTP API retry service without a message Broker.",
+    "should_trigger": false
+  },
+  {
+    "query": "Install npm packages and fix dependency conflicts in a Node.js project.",
+    "should_trigger": false
+  }
+]

package/skills/neo-rabbitmq/evals/evals.json

@@ -0,0 +1,114 @@
+{
+  "skill_name": "neo-rabbitmq",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Using language-neutral RabbitMQ 4.3 concepts, design the Exchange, Binding, Queue, confirmation, and retry topology for order events.",
+      "expected_output": "State assumptions first, then describe the protocol, Virtual Host, Exchange, Binding, Queue type, Publisher Confirm, Consumer Ack, retry, and Dead Letter paths. Do not include Client code in any programming language.",
+      "assertions": [
+        "It clearly uses RabbitMQ 4.3 as the baseline before current-version verification",
+        "It distinguishes routing success, Publisher Confirm, and Consumer Ack semantics",
+        "It lists verification methods for duplicate delivery, retry limits, and Dead Lettering",
+        "It uses only topology and protocol semantics and contains no Java, Python, C#, or other language API code"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Choose between a general Queue, Quorum Queue, and Stream. Analyze the trade-offs for data safety, ordering, replay, and resource use.",
+      "expected_output": "Use a requirements matrix to compare the three data structures. Distinguish replication, ordering, Retention, Offset, replay, Consumer model, and resource cost, and require workload-based performance validation.",
+      "assertions": [
+        "It does not claim that one Queue type is fastest for every workload",
+        "It identifies Quorum Queue replication and resource trade-offs",
+        "It identifies Stream Offset, Retention, or replay semantics",
+        "It provides capacity and failure verification conditions after selection"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "RabbitMQ publishing is occasionally blocked. Plan a safe troubleshooting workflow.",
+      "expected_output": "Request the version, nodes, time range, and metrics first. Then isolate Memory Alarms, Disk Alarms, Flow Control, Queue backlog, Consumer rate, disk, and network with read-only checks before proposing changes with rollback steps.",
+      "assertions": [
+        "It treats alarms as protection mechanisms and bottleneck signals instead of immediately raising thresholds",
+        "It lists read-only checks before changes and rollback",
+        "It mentions that cluster alarms can affect multiple nodes",
+        "It explicitly states that the root cause cannot be determined without environment evidence"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Plan TLS, Virtual Host, least privilege, Management, and CLI administration for a RabbitMQ 4.3 cluster.",
+      "expected_output": "Separate network and certificates, Authentication, Authorization, Virtual Host, Management, CLI, monitoring accounts, and verification steps. Keep secrets out of examples.",
+      "assertions": [
+        "It distinguishes Authentication from Authorization",
+        "It uses Virtual Hosts for isolation and permission scope",
+        "It checks TLS Peer Verification, Listeners, or certificate rotation",
+        "It contains no passwords, Tokens, Cookies, private keys, or personal information"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Design Prometheus monitoring and a RabbitMQ performance baseline.",
+      "expected_output": "Cover Cluster, Node, Queue, Connection, Channel, Publisher, Consumer, Stream, Alarm, and host metrics. Explain aggregated versus Per-object metrics, scrape frequency, and monitoring cost.",
+      "assertions": [
+        "It first defines SLO, message size, rate, processing time, and topology baselines",
+        "It includes actionable metrics such as Consumer Capacity, Queue Depth, Ack latency, or Confirm latency",
+        "It warns about high cardinality and output cost from Per-object or Detailed metrics",
+        "It does not invent universal monitoring thresholds without source evidence"
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "We are preparing a node-by-node RabbitMQ upgrade. List the checks before, during, and after the upgrade.",
+      "expected_output": "Order checks around Upgrade Path, Erlang version, Release Notes, Feature Flags, Plugins, backups, cluster health, capacity, per-node verification, and rollback.",
+      "assertions": [
+        "It requires confirmation of the upgrade path from the source to target version",
+        "It includes Erlang, stable Feature Flag, Plugin, and cluster-capacity checks",
+        "Each node has stop, upgrade, start, and health-verification steps",
+        "It explains when a Rolling Upgrade is not applicable"
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "A RabbitMQ Queue keeps growing. Find the possible performance bottlenecks.",
+      "expected_output": "Treat Queue backlog as a symptom. Isolate Publish, Routing, Storage, Network, Consumer, Prefetch, Ack, Redelivery, Alarm, and resource evidence. Label adding Consumers as a hypothesis to validate.",
+      "assertions": [
+        "It compares Publish Rate, Deliver Rate, Ack Rate, and Consumer Capacity",
+        "It checks unacknowledged messages, Prefetch, redelivery, and retry loops",
+        "It does not present adding Consumers as a universal solution",
+        "It lists Queue, Alarm, latency, and resource signals for post-fix verification"
+      ]
+    },
+    {
+      "id": 8,
+      "prompt": "Analyze why RabbitMQ Connection and Channel counts keep increasing.",
+      "expected_output": "Check lifecycle, creation and closure rates, File Descriptors, memory, reconnect spikes, Client distribution, and Connection or Channel Churn. Then propose reuse and capacity measures.",
+      "assertions": [
+        "It distinguishes Connection Churn from Channel Churn",
+        "It includes File Descriptor and memory evidence",
+        "It recommends long-lived resources and reasonable Publisher and Consumer separation",
+        "It does not produce connection-management code for a specific programming language"
+      ]
+    },
+    {
+      "id": 9,
+      "prompt": "Plan Kubernetes RabbitMQ operations from the Operator perspective.",
+      "expected_output": "Request Operator, RabbitMQ, Kubernetes, and CRD versions first. Then check storage, TLS, monitoring, Pod Disruption, upgrades, Operator logs, and RabbitMQ Broker health separately.",
+      "assertions": [
+        "It does not treat non-versioned Operator documentation as RabbitMQ 4.3 Broker documentation",
+        "It requires version and CRD compatibility checks",
+        "It covers storage, TLS, monitoring, upgrades, and troubleshooting",
+        "It does not provide unverified deletion, rebuild, or downtime commands"
+      ]
+    },
+    {
+      "id": 10,
+      "prompt": "Give me Python pika code for RabbitMQ automatic reconnect and Prefetch.",
+      "expected_output": "The request is outside the skill's language-specific Client API scope. Refuse to produce Python code, but provide language-neutral reconnect, Ack, Prefetch, duplicate-delivery, and verification semantics when useful, and point to the official Client Library documentation.",
+      "assertions": [
+        "It does not produce Python code or invent an API",
+        "It still explains language-neutral reliability and performance considerations",
+        "It clearly states the skill boundary and the need to consult official Client documentation"
+      ]
+    }
+  ]
+}

package/skills/neo-rabbitmq/references/development.md

@@ -0,0 +1,71 @@
+# RabbitMQ Development Design
+
+Use this reference for protocol and message-design decisions based on RabbitMQ 4.3. The primary sources are amqp.md, protocols.md, exchanges.md, queues.md, consumers.md, publishers/index.md, confirms.md, reliability.md, ttl.md, quorum-queues/index.md, and streams.md.
+
+## Design Order
+
+Define business semantics before designing objects and settings:
+
+1. Define whether messages may be lost, whether duplicates are allowed, ordering requirements, retry limits, expiration policy, and the destination for failed processing.
+2. Select the protocol and Virtual Host, then confirm authentication, authorization, isolation, and network boundaries.
+3. Design Exchanges, Bindings, Routing Keys, and handling for unroutable messages.
+4. Choose a Queue, Quorum Queue, or Stream, then confirm durability, replication, retention, replay, and resource characteristics.
+5. Design Publisher Confirms, Consumer Acknowledgements, Prefetch, retry, and cancellation behavior.
+6. Define monitoring, alerts, failure recovery, and verification cases.
+
+## Exchanges and Routing
+
+- Publishers send messages to an Exchange. The Exchange routes them to Queues according to Bindings and Routing Keys.
+- direct is suitable for exact-key routing, fanout broadcasts to bound Queues, and topic routes by pattern. Select the type based on message topology and maintenance cost.
+- When unroutable messages matter, explicitly choose Publisher-side reporting, an Alternate Exchange, or another observable failure path. Do not interpret a Confirm as proof that a Consumer will process the message.
+- Exchanges, Bindings, and Queues are scoped to a Virtual Host. For cross-team or multi-tenant environments, confirm naming, permissions, and isolation boundaries first.
+- When using Exchange-to-Exchange Bindings or an Alternate Exchange, include the additional routing layer and loop risks in verification.
+
+## Queue Declaration and Lifecycle
+
+- A Queue's name, Durable, Exclusive, Auto-delete, and Arguments together determine lifecycle and resource semantics.
+- Redeclaring an existing Queue with inconsistent properties causes a channel-level PRECONDITION_FAILED. Treat the declaration contract as a versioned interface in deployment tools and applications.
+- Queue types, some Arguments, and other creation-time settings cannot be changed arbitrarily after creation. Prefer Policies for group settings that Policies can manage instead of scattering them across application declarations.
+- RabbitMQ 4.3 has disabled the default declaration of non-Durable, non-Exclusive Classic Queues. For short-lived data, evaluate a Durable Queue with Queue TTL, an Exclusive Queue, or another suitable data structure rather than relying on deprecated behavior.
+- An Exclusive Queue is tied to the Connection that declared it and is suitable for temporary state owned by one Client. It is commonly paired with a Broker-generated name to avoid fixed-name races during reconnects.
+- A Durable Queue does not mean that every message survives a restart. Check message persistence at publish time together with Queue durability.
+
+## Reliability Boundaries
+
+- A Publisher Confirm reports whether the Broker accepted and processed a publish. A Consumer Acknowledgement reports whether the Consumer completed delivery processing. They address failures in different directions.
+- When Broker-side data safety matters, use an appropriate Durable Queue, persistent messages, Publisher Confirms, and a recovery workflow. Explicitly handle Confirm latency, negative responses, and Connection loss.
+- A Consumer should not acknowledge before processing is complete. A disconnect, Channel closure, or Negative Acknowledgement can requeue unacknowledged messages, so processing must tolerate duplicate delivery.
+- Requeue is not an infinite retry strategy. Set observable retry limits, delayed retry, or a Dead Letter path for persistent failures to avoid a Requeue Loop.
+- Confirm, Ack, routing success, persistence success, and business processing success are different events. Represent them separately in state machines and audit records.
+
+## Queue, Quorum Queue, and Stream
+
+- A general Queue uses Queue, Consumer, Ack, Prefetch, and TTL semantics. Confirm whether replication and cross-node fault tolerance are required.
+- A Quorum Queue provides replication, data safety, and consistency. It requires Durable and introduces membership management, Leader election, Delivery Limit, resource use, and performance trade-offs. Select it only when those semantics are required.
+- A Stream is an immutable append-only log with Offset, Retention, replay, and a different consumption model. It is not a renamed general Queue and has different connection and replication requirements.
+- For global ordering, check whether a Stream fits. If using Queues, evaluate Single Active Consumer, a single Consumer, or partitioning, including the effect of requeue on ordering.
+- Do not conclude that Quorum Queues are always safer or Streams are always faster without workload evidence. Test message size, rate, replication factor, disk, Consumer behavior, and target SLO.
+
+## Publisher and Consumer Behavior
+
+- Messaging protocols generally expect long-lived Connections. Do not create and close a Connection for every publish or consume operation; evaluate Connection pooling when necessary.
+- Connections and Channels consume Client and Broker resources. Reuse long-lived resources, close objects that are truly no longer needed, and monitor Connection or Channel Churn.
+- If Publishers and Consumers share a Connection, Publisher Flow Control can affect Consumer manual acknowledgements. Separate the two Connection types when the requirements allow it.
+- Prefetch controls the number of deliveries that have not completed. It affects throughput, latency, ordering, memory, and redelivery cost; adjust it only after measuring processing time, message size, Consumer count, and Ack behavior.
+- Observe Consumer Capacity, unacknowledged message count, Queue Depth, Publish Rate, Deliver Rate, Ack Rate, and Confirm Latency together. Do not rely on Queue length alone.
+- Polling Consumers add requests and latency without keeping delivery continuous. Unless single-message pulls are explicitly required, prefer continuous consumption.
+
+## Language-Neutral Output
+
+For development questions, use topology, protocol fields, configuration semantics, failure states, and verification cases. Do not produce Java, Python, C#, Go, Ruby, or other language-specific Client calls. If the user needs an implementation in a language, direct them to the corresponding official Client Library documentation.
+
+### Sources
+
+- [Exchanges](https://www.rabbitmq.com/docs/4.3/exchanges)
+- [Queues](https://www.rabbitmq.com/docs/4.3/queues)
+- [Consumers](https://www.rabbitmq.com/docs/4.3/consumers)
+- [Publishers](https://www.rabbitmq.com/docs/4.3/publishers)
+- [Consumer Acknowledgements and Publisher Confirms](https://www.rabbitmq.com/docs/4.3/confirms)
+- [Reliability Guide](https://www.rabbitmq.com/docs/4.3/reliability)
+- [Quorum Queues](https://www.rabbitmq.com/docs/4.3/quorum-queues)
+- [Streams and Super Streams](https://www.rabbitmq.com/docs/4.3/streams)

package/skills/neo-rabbitmq/references/operations.md

@@ -0,0 +1,77 @@
+# RabbitMQ Operations and Management
+
+Use this reference for RabbitMQ 4.3 Broker management. The primary sources are configure.md, manage-rabbitmq.md, cli.md, management-cli.md, management/index.md, definitions.md, plugins.md, access-control.md, vhosts.md, policies.md, clustering.md, cluster-formation.md, networking.md, ssl/index.md, backup.md, snapshots.md, upgrade.md, rolling-upgrade.md, and production-checklist.md.
+
+## Operations Lifecycle
+
+Treat inventory, change, verification, and rollback as the minimum closed loop for every operation:
+
+1. Inventory RabbitMQ, Erlang, Plugins, Feature Flags, node names, Cluster members, Listeners, Virtual Hosts, users, Policies, Queue types, and current alarms.
+2. Confirm the target, affected nodes, change window, backup or Definitions Export, rollback path, and success criteria.
+3. Run read-only checks first, then apply the smallest-scope change. Do not modify several unverified settings together.
+4. Recheck health, alarms, Listeners, routing, Publishers, Consumers, and critical business metrics. Preserve evidence of the change.
+
+If data is insufficient, do not provide a one-step restart, deletion, clearing, or upgrade procedure. Request the environment version, topology, backup state, and maintenance-window information first.
+
+## Configuration and CLI
+
+- Manage primary Broker settings through rabbitmq.conf or .conf files in the configuration directory. Use advanced.config only when the corresponding configuration format is required. For configuration questions, confirm the file location, load method, and node scope first.
+- Use rabbitmqctl for service management and general Broker operations, rabbitmq-diagnostics for diagnostics and health checks, rabbitmq-plugins for Plugin management, and rabbitmq-queues for Queue-related administration. Treat the help output for the target version as authoritative for subcommands.
+- rabbitmqadmin v2 uses the HTTP API for object management, health checks, Definitions, and some operational tasks. It does not replace the core CLI tools. Do not use the explicitly excluded rabbitmqadmin publish or rabbitmqadmin get production operations.
+- Use restricted accounts for CLI, HTTP API, and Management UI. Never put passwords, Tokens, Cookies, private keys, or personal information in commands, documentation, logs, or examples.
+
+## Management, Permissions, and Isolation
+
+- The Management Plugin provides a UI, HTTP API, metrics, and some management operations. Separate read-write management accounts from read-only monitoring accounts and grant only the required Virtual Host scope.
+- A Virtual Host is a logical isolation boundary for Connections, Exchanges, Queues, Bindings, permissions, and some Policies. Do not use naming alone to separate tenants or systems with different lifecycles.
+- Authentication and Authorization are separate controls. First confirm how a user is authenticated, then confirm what the user can do in the target Virtual Host.
+- When enabling TLS, check the Server Certificate, Trust Store, Peer Verification, Hostname, Listener, certificate rotation, and Client compatibility together. A working TCP connection is not enough.
+- Check inter-node and CLI tool authentication, DNS, time synchronization, Firewall rules, and required Listeners together. A working TLS Client connection does not prove that inter-node communication is secure or available.
+
+## Policies, Definitions, and Plugins
+
+- Use a Policy to apply runtime settings to a group of Queues, Streams, or Exchanges. Policies suit settings that change or must remain consistent across a group.
+- A Policy cannot change Queue or Stream types or other creation-time semantics. Handle those choices in topology versioning and migration plans.
+- Definitions contain Users, Virtual Hosts, Queues, Exchanges, Bindings, Runtime Parameters, and other topology metadata. A Definitions Export can support topology backup, migration, or data seeding, but it is not a backup of Queue message contents.
+- Before enabling a Plugin, confirm its support level, version compatibility, resource cost, Listeners, permissions, monitoring, and disablement rollback. Do not enable an unnecessary Plugin because the UI offers it.
+
+## Cluster and Node Maintenance
+
+- Cluster membership, metadata, and Queue or Stream Replica scope are different concerns. Distinguish cluster membership, Definitions replication, and message-data replication.
+- Cluster design must check Node Names, Peer Discovery, Erlang Cookie or equivalent authentication, DNS, Firewall rules, time synchronization, Leader or Replica placement, Client connection distribution, and quorum conditions.
+- RabbitMQ 4.3 cluster documentation emphasizes odd node counts and discourages two-node clusters. Validate the node count against Queue or Stream replication factors, failure model, capacity, and maintenance strategy.
+- Adding nodes does not automatically solve throughput problems. Metadata changes, cross-node routing, replication, Connection distribution, and data placement can add new costs.
+- Before node maintenance, confirm that no object would lose quorum or a required Replica. Follow the applicable Queue, Stream, and upgrade documentation. Do not stop a node without health evidence.
+
+## Backup, Upgrade, and Rollback
+
+- Treat Definitions, Broker configuration, certificates, and message data as separate backup targets. Confirm the recovery scope and recovery-test result for each backup type.
+- Use a Rolling Upgrade only when the source and target versions, Erlang versions, Feature Flags, Plugins, cluster health, and capacity conditions all qualify.
+- Before an upgrade, read the Release Notes from the current version through the target version. Check the Upgrade Path, Erlang requirements, stable Feature Flags, package dependencies, cluster capacity, backups, and rollback plan.
+- Upgrade nodes one at a time: stop, upgrade, start, and verify each node. At every step, check cluster state, Queue or Stream safety, Listeners, Publishers, Consumers, and alarms.
+- Enable new Feature Flags or remove compatibility settings only after every verification condition passes. Keep a feasible path back to the last verified version.
+
+## Production Minimum Checks
+
+- Use durable storage and check free disk, storage isolation, filesystem behavior, I/O capability, and backup strategy.
+- Check RAM, Memory Alarms, Disk Alarms, File Descriptors, CPU, network throughput, Connections, Channels, Queues, message rates, and log collection.
+- Use TLS, least privilege, restricted Firewalls, non-public Management endpoints, rotatable certificates, and monitoring configuration without secrets.
+- Have applications reuse long-lived Connections and Channels. Avoid high Connection or Channel Churn, unrestricted polling, and unbounded retries.
+- Create executable verification cases for health checks, readiness, alarms, capacity trends, failure recovery, and upgrade rollback.
+
+## Kubernetes Operator
+
+Kubernetes Operator documentation is in the non-versioned kubernetes/operator/ path. For Operator questions, confirm the versions of the Operator, RabbitMQ Cluster Operator, Topology Operator, Kubernetes, and RabbitMQ first. Verify CRDs, storage, TLS, monitoring, Pod Disruption, upgrades, and Operator logs separately. Do not treat Operator documentation as a replacement for versioned RabbitMQ 4.3 Broker documentation.
+
+### Sources
+
+- [Configuration](https://www.rabbitmq.com/docs/4.3/configure)
+- [Command Line Tools](https://www.rabbitmq.com/docs/4.3/cli)
+- [Management Plugin](https://www.rabbitmq.com/docs/4.3/management)
+- [Authentication, Authorization, and Access Control](https://www.rabbitmq.com/docs/4.3/access-control)
+- [Virtual Hosts](https://www.rabbitmq.com/docs/4.3/vhosts)
+- [Policies](https://www.rabbitmq.com/docs/4.3/policies)
+- [Clustering Guide](https://www.rabbitmq.com/docs/4.3/clustering)
+- [TLS Support](https://www.rabbitmq.com/docs/4.3/ssl)
+- [Rolling Upgrade](https://www.rabbitmq.com/docs/4.3/rolling-upgrade)
+- [Production Deployment Guidelines](https://www.rabbitmq.com/docs/4.3/production-checklist)

package/skills/neo-rabbitmq/references/performance.md

@@ -0,0 +1,98 @@
+# RabbitMQ Performance, Capacity, and Monitoring
+
+Use this reference for RabbitMQ 4.3 performance analysis. The primary sources are production-checklist.md, monitoring/index.md, prometheus/index.md, memory.md, memory-use/index.md, connections/index.md, channels/index.md, flow-control.md, consumer-prefetch.md, publishers/index.md, queues.md, quorum-queues/index.md, streams.md, and alarms.md.
+
+## Establish a Comparable Baseline
+
+Before changing settings, record a stable period of:
+
+- Target SLOs: Publish latency, Confirm latency, Consumer latency, acceptable Queue Depth, acceptable redelivery rate, and availability.
+- Workload: message-size distribution, Publish Rate, Deliver Rate, Ack Rate, Confirm Rate, Consumer count, processing time, retries, and traffic-spike patterns.
+- Topology: protocol, Virtual Host, Exchange, Binding, Queue type, Durable, TTL, Dead Lettering, replication factor, node count, and Client connection location.
+- Broker resources: CPU, RAM, Memory Breakdown, disk capacity, disk latency and throughput, File Descriptors, network throughput, Connections, Channels, Queues, and alarms.
+- Application behavior: Connection or Channel Churn, Prefetch, unacknowledged messages, polling, message batching, failed reconnects, redelivery, and Consumer Capacity.
+
+Without a baseline, you cannot tell whether a change improved the system or moved the bottleneck. Mark the data as insufficient instead of providing fixed values.
+
+## Bottleneck Isolation Order
+
+Inspect the end-to-end path before adjusting a parameter:
+
+1. Can the Publisher establish a Connection, complete routing, and receive a Confirm?
+2. Do Exchanges and Bindings cause unroutable messages, extra routing, or imbalance?
+3. Are Queue storage, disk, replication, TTL, Priority, or message indexes the cost driver?
+4. Are Connections, Channels, Flow Control, or the network limiting transport?
+5. Does the Consumer have enough processing capacity, suitable Prefetch, appropriate Ack timing, and observable failure retries?
+6. Is the Broker in a Memory Alarm, Disk Alarm, or another resource-protection state?
+
+If Queue Depth is growing, the cause may be Consumer processing speed, a Publisher spike, routing errors, a retry loop, disk, replication, or a Connection problem. Treat adding Consumers as a hypothesis to validate, not a conclusion.
+
+## Priority Adjustments
+
+### Connections and Channels
+
+- Prefer long-lived Connections and Channels. Do not create a Connection for every message.
+- Observe Connection Count, Channel Count, creation and closure rates, File Descriptors, memory, and network resources.
+- When requirements allow, separate Publishers and Consumers onto different Connections so Publisher Flow Control does not delay Consumer acknowledgements.
+- For large Connection populations, also check node distribution, Listeners, operating-system limits, TLS cost, and Client reconnect storms.
+
+### Publishers
+
+- Assess data safety through Publisher Confirm latency, negative responses, retries, and Connection-loss behavior, not only the return of a Publish call.
+- Streaming Confirms, Batch Publishing, and Publish-and-Wait have different latency, throughput, and memory properties. Select one according to reliability requirements, then measure it with the workload.
+- Check Unroutable Message metrics and Exchange Bindings. A Queue without a Consumer or a received Confirm does not prove that business processing completed.
+- When a Publisher is blocked by a Resource Alarm or Flow Control, address Broker resources and downstream consumption before increasing concurrency.
+
+### Consumers
+
+- Adjust Prefetch according to message size, processing time, Ack latency, Consumer count, ordering requirements, and memory limits.
+- Observe Consumer Capacity, Ready Messages, Unacknowledged Messages, Deliver Rate, Ack Rate, Redelivery Rate, and processing latency.
+- Prefetch that is too high can increase unacknowledged messages and memory use; Prefetch that is too low can limit concurrency. Compare throughput, latency, memory, and redelivery after every change.
+- Do not replace continuous consumption with polling for performance. Polling usually adds request cost and empty-pull latency.
+- If ordering is the priority, evaluate Single Active Consumer, a single Consumer, or partitioned Queues. If retries are the priority, evaluate Delivery Limit, delayed retry, and Dead Lettering.
+
+### Queue Types and Data Paths
+
+- Classic Queue, Quorum Queue, and Stream have different data models, replication, storage, ordering, retention, and consumption behavior. Select by semantics first, then run workload benchmarks.
+- Quorum Queue replication, WAL, Segment, Snapshot, Leader, Rebalance, disk, and resource use affect performance. Adjust performance settings only when you observe the corresponding bottleneck.
+- Stream Retention, Replica, Leader, Offset, Deduplication, Stream Connection, and Super Stream partitioning change the cost model. Do not apply general Queue tuning assumptions to Streams.
+- TTL, Length Limit, Priority, Dead Lettering, and Requeue change Queue workload. Include Priority count, expiration scanning, and repeated enqueueing in resource estimates.
+
+## Memory, Disk, and Alarms
+
+- Use Memory Breakdown to distinguish Connections, Queues, Message Store Index, Plugins, Management Stats, Binaries, Erlang Processes, and other categories. Do not inspect only operating-system RSS.
+- Memory Alarms and Disk Alarms block publishing Connections, and cluster alarms can affect the whole cluster. First identify the alarm source node, consumption rate, remaining disk, message Paging, and resource trends.
+- The memory Threshold is a protection point that triggers publishing throttling, not a hard limit. In containers or Kubernetes, confirm the effective cgroup limit and Broker configuration.
+- Examine disk capacity, disk latency, free space, Queue storage, Quorum Segments, and Snapshots together. A Disk Alarm cannot be solved simply by lowering a limit.
+- Reduce input, restore consumption, handle unnecessary backlog according to the data-retention and recovery plan, or add suitable resources first. Then reassess the threshold; raising it must not conceal an environment without capacity.
+
+## Monitoring Design
+
+- Combine Prometheus, the Management Plugin, the HTTP API, CLI Observer, logs, and host metrics. A health check cannot replace trend monitoring.
+- At minimum distinguish Cluster, Node, Queue, Connection, Channel, Publisher, Consumer, Stream, Alarm, and application-level metrics.
+- Aggregated metrics suit high-frequency and large-scale collection. Per-object or Detailed metrics can produce high output volume and cardinality; limit their scope and frequency.
+- Monitoring itself consumes CPU, memory, HTTP, Management Stats, and storage resources. Set collection frequency and object scope according to capacity and troubleshooting needs.
+- Thresholds in Grafana or Prometheus charts are not universal RabbitMQ constants. Workload, Queue type, message size, and SLO affect a reasonable range.
+
+## Capacity and Experiment Rules
+
+Record the following for every performance experiment:
+
+1. One primary variable, such as Prefetch, Consumer count, batch size, Connection distribution, or Queue type.
+2. Fixed message size, Publish Rate, Consumer processing time, node resources, and test duration.
+3. Success criteria, such as Confirm p95, Consumer p95, Queue Depth, CPU, RAM, disk latency, redelivery rate, and alarm count.
+4. Failure criteria, rollback settings, data-cleanup method, and rerun steps.
+
+Treat results as observations for the same topology and workload only. Do not present throughput, latency, or the best parameter from a single benchmark as a universal RabbitMQ capability.
+
+### Sources
+
+- [Production Deployment Guidelines](https://www.rabbitmq.com/docs/4.3/production-checklist)
+- [Monitoring](https://www.rabbitmq.com/docs/4.3/monitoring)
+- [Prometheus and Grafana](https://www.rabbitmq.com/docs/4.3/prometheus)
+- [Reasoning About Memory Usage](https://www.rabbitmq.com/docs/4.3/memory-use)
+- [Connections](https://www.rabbitmq.com/docs/4.3/connections)
+- [Channels](https://www.rabbitmq.com/docs/4.3/channels)
+- [Flow Control](https://www.rabbitmq.com/docs/4.3/flow-control)
+- [Consumer Prefetch](https://www.rabbitmq.com/docs/4.3/consumer-prefetch)
+- [Memory and Disk Alarms](https://www.rabbitmq.com/docs/4.3/alarms)

package/skills/neo-rabbitmq/references/sources-and-scope.md

@@ -0,0 +1,56 @@
+# RabbitMQ Sources and Scope
+
+## Default Version
+
+Use the stable RabbitMQ 4.3 documentation as the default knowledge baseline for this skill:
+
+- Source directory: rabbitmq-website/versioned_docs/version-4.3
+- Source repository: rabbitmq-website
+- Source snapshot: 2b61ea8d840a42e1ba46ee2f1fdf0f9aeec63bd9
+- In the same source repository, docs is the 4.4 development version, not the default version for this skill.
+- versioned_docs/version-4.2, versioned_docs/version-4.1, versioned_docs/version-4.0, and versioned_docs/version-3.13 are older versions; switch to them only when the user explicitly specifies one.
+
+The source repository README identifies 4.3 as the stable documentation path and docs as the 4.4 development version. Because versioned documentation shares the website repository, use the correct version directory instead of relying on docs alone.
+
+## Topic Map
+
+| Topic | Primary source paths |
+| :--- | :--- |
+| Protocols and message semantics | amqp.md, protocols.md, exchanges.md, queues.md, consumers.md, publishers/index.md, confirms.md, reliability.md |
+| Queue types and data structures | classic-queues.md, quorum-queues/index.md, streams.md, stream.md, stream-connections.md, stream-filtering.md |
+| Message lifecycle | ttl.md, dlx.md, nack.md, consumer-prefetch.md, consumer-priority.md, flow-control.md |
+| Broker configuration and management | configure.md, manage-rabbitmq.md, cli.md, management-cli.md, management/index.md, plugins.md, definitions.md |
+| Security and isolation | access-control.md, vhosts.md, ssl/index.md, ldap.md, oauth2.md, networking.md |
+| Clusters and maintenance | clustering.md, cluster-formation.md, feature-flags/index.md, backup.md, snapshots.md, upgrade.md, rolling-upgrade.md |
+| Monitoring and performance | monitoring/index.md, prometheus/index.md, production-checklist.md, memory.md, memory-use/index.md, connections/index.md, channels/index.md, alarms.md, disk-alarms.md, limits.md |
+| Troubleshooting | troubleshooting/index.md, troubleshooting-networking.md, troubleshooting-ssl.md, troubleshooting-oauth2.md |
+| Kubernetes operations | Non-versioned kubernetes/operator/ |
+
+## Explicit Exclusions
+
+- Do not include Java, Python, C#, Go, Ruby, or other language examples from tutorials/ and client-libraries/. Retain only protocol, topology, reliability, and operations semantics.
+- Do not include blog/. The source README states that Blog content is outside the RabbitMQ documentation license scope and that Blog articles may not be redistributed.
+- Do not include Docusaurus, React, CSS, website components, deployment infrastructure, or ci/; these are not RabbitMQ Broker development, operations, or performance knowledge.
+- Do not use rabbitmqadmin publish or rabbitmqadmin get as production operations. The source Agent Instructions explicitly state that these commands are intentionally omitted.
+- Do not copy the entire website. References are concise knowledge rewritten by topic; source paths provide traceability and verification.
+
+## License and Attribution
+
+The RabbitMQ website README states that the documentation is available under the Apache License 2.0 and Mozilla Public License 2.0. Users may choose either license subject to its terms. The README also excludes Blog content and states that Broadcom retains its intellectual property. This skill summarizes the documentation, preserves the source repository, version directory, commit identifier, and official documentation links, and does not treat Blog or other excluded material as part of the documentation license.
+
+## Freshness Policy
+
+The source snapshot provides a traceable baseline but does not guarantee current RabbitMQ behavior. Consult current official documentation or the target environment's tool help before answering questions about:
+
+- Latest versions, support matrices, Release Notes, Feature Flags, Deprecated Features, and upgrade paths.
+- CLI subcommands, arguments, configuration keys, defaults, ports, limits, Plugin support, and Kubernetes Operator behavior.
+- TLS, OAuth, LDAP, certificates, authentication, CVEs, security advisories, and third-party component status.
+- Performance numbers, capacity, latency, monitoring thresholds, and recommendations for a specific host or container environment.
+
+If current-source verification cannot be completed, state explicitly that the answer uses the 4.3 snapshot and list changeable items as pending verification.
+
+### Official Documentation
+
+- [RabbitMQ 4.3 documentation](https://www.rabbitmq.com/docs/4.3)
+- [RabbitMQ documentation home](https://www.rabbitmq.com/docs)
+- [RabbitMQ website repository](https://github.com/rabbitmq/rabbitmq-website)

package/skills/neo-rabbitmq/references/troubleshooting.md

@@ -0,0 +1,84 @@
+# Layered RabbitMQ Troubleshooting
+
+Use this reference as a language-neutral investigation process based on RabbitMQ 4.3 troubleshooting documentation. The primary sources are troubleshooting/index.md, troubleshooting-networking.md, troubleshooting-ssl.md, troubleshooting-oauth2.md, monitoring/index.md, memory-use/index.md, connections/index.md, channels/index.md, publishers/index.md, alarms.md, and flow-control.md.
+
+## Troubleshooting Loop
+
+1. Describe observable symptoms: affected Virtual Host, Queue, Connection, Node, time range, error messages, latency, and affected operations.
+2. Confirm the version and change context: RabbitMQ, Erlang, Plugins, Feature Flags, configuration, deployment, certificates, network, and recent changes.
+3. Collect read-only evidence: health checks, alarms, Listeners, logs, Cluster status, Queue metrics, Connections, Channels, Publishers, Consumers, memory, and disk.
+4. Isolate by layer: Client or network, Listener, TLS, Authentication, Authorization, Cluster, Resource Alarm, Exchange routing, Queue, Publisher, Consumer, or application processing.
+5. Change only after the failing layer is supported by evidence. Reproduce first in a small scope or non-production environment and record rollback settings.
+6. Verify again using the original symptom, health status, metrics, logs, and business outcome. Confirm that the failure was not moved to another layer.
+
+A report that only says very slow, cannot connect, or Queue is growing lacks the time, scope, version, and metrics required for a safe root-cause determination.
+
+## Symptom-Based Checks
+
+### Publisher Blocked or Throughput Reduced
+
+Check Memory Alarm, Disk Alarm, Flow Control, disk latency, Queue backlog, Consumer Ack rate, Publisher Confirm latency, and network first. A Resource Alarm blocks publishing Connections, and a cluster alarm can affect multiple nodes.
+
+Do not begin by raising Memory Threshold, Disk Threshold, or Publisher concurrency. Reduce input or restore downstream consumption, identify the source of memory, disk, and message backlog, and then decide whether capacity or configuration changes are justified.
+
+### Queue Backlog or Consumer Falling Behind
+
+Check in order:
+
+- Whether Exchanges and Bindings route messages to the expected Queue.
+- Whether Publisher Rate remains above Deliver Rate or Ack Rate.
+- Consumer Capacity, Consumer count, processing time, Prefetch, and unacknowledged messages.
+- Redelivery, Negative Acknowledgement, Retry, Dead Lettering, and Requeue Loops.
+- Queue type, replication, disk, resource alarms, and cross-node data placement.
+
+Add Consumers only when Consumer processing capacity or concurrency is a proven bottleneck. If the bottleneck is Publisher input, disk, routing, or Requeue, adding Consumers can worsen the problem.
+
+### Routing or Message-Loss Concern
+
+Confirm the Virtual Host, Exchange name, Exchange type, Bindings, Routing Key, Queue state, and Unroutable Message handling used by the Publisher. Check separately whether the message was routed, the Broker accepted the publish, the Publisher received a Confirm, and the Consumer completed business processing.
+
+### Repeated Connection or Channel Interruptions
+
+Distinguish DNS, TCP Listener, Firewall, TLS, Authentication, Authorization, Heartbeat, Broker-initiated closure, Resource Alarms, and Client reconnect behavior first. Check Connection or Channel Churn, File Descriptors, Protocol Exceptions in logs, node resources, and reconnect spikes.
+
+Do not attribute every disconnect to Heartbeat. Verify low Heartbeat settings, network congestion, host load, TLS certificates, permissions, and Broker closure reasons separately.
+
+### Memory or Disk Rising Continuously
+
+Use Memory Breakdown to separate Connections, Queues, Message Store, Plugins, Management Stats, Binaries, Processes, and other categories. Compare them with Queue Depth, unacknowledged messages, message size, Connection count, Channel count, Plugins, and monitoring frequency.
+
+For disk troubleshooting, check the Broker database partition, free space, message Paging, Queue or Quorum Segments, Snapshots, logs, and other host processes together. Do not inspect only total container filesystem capacity.
+
+### Unhealthy Cluster or Replicas
+
+Confirm Node Names, Peer Discovery, inter-node authentication, DNS, time synchronization, Firewall rules, Feature Flags, Metadata Store, Queue or Stream members, Leaders, quorum, and current maintenance actions. Before stopping a node, identify which objects would lose an online quorum.
+
+A Client connection to one node does not prove cluster health. Check cluster membership, alarms, Replicas, and the state of critical Queues or Streams as well.
+
+## CLI and Evidence Rules
+
+- When rabbitmqctl, rabbitmq-diagnostics, rabbitmq-plugins, or rabbitmq-queues commands are needed, read help for the target installation first and use syntax appropriate for the version.
+- Use rabbitmqadmin only for management, health, Definitions, or metric operations covered by the source documentation. Never recommend rabbitmqadmin publish or rabbitmqadmin get.
+- Mask Hostnames, IP addresses, users, Tokens, Cookies, certificates, and message contents before reporting command output. Never paste real secrets into documentation or Tickets.
+- Start with read-only checks such as status, alarms, Listeners, metrics, logs, and object lists. Evaluate clearing, deletion, requeue, Connection closure, node shutdown, and configuration changes as separate actions.
+- Record the expected observation, actual observation, supported or eliminated hypothesis, and next check for every troubleshooting step.
+
+## Rollback and Verification
+
+After a change, verify at least:
+
+- The original error no longer appears, with no new Protocol Exception, Authentication Failure, or TLS Failure.
+- Alarms and Flow Control are cleared or show a clear improving trend.
+- Publish, Route, Confirm, Deliver, Ack, Redelivery, and Consumer Capacity return to the expected range.
+- Queue Depth, unacknowledged messages, memory, disk, Connections, Channels, and network do not become a new anomaly.
+- Cluster, Queue, or Stream Replicas, Leaders, Listeners, Health Checks, and Readiness meet the deployment target.
+- Rollback settings, backups, change records, and follow-up monitoring ownership are confirmed.
+
+### Sources
+
+- [Troubleshooting Guidance](https://www.rabbitmq.com/docs/4.3/troubleshooting)
+- [Troubleshooting Network Connectivity](https://www.rabbitmq.com/docs/4.3/troubleshooting-networking)
+- [Monitoring](https://www.rabbitmq.com/docs/4.3/monitoring)
+- [Reasoning About Memory Usage](https://www.rabbitmq.com/docs/4.3/memory-use)
+- [Publishers](https://www.rabbitmq.com/docs/4.3/publishers)
+- [Memory and Disk Alarms](https://www.rabbitmq.com/docs/4.3/alarms)