@moon791017/neo-skills 1.1.25 → 1.1.27

package/README.md

@@ -38,6 +38,8 @@
 | 類別 | Skill | 使用時機 |
 | :--- | :--- | :--- |
 | Agent 治理 | `neo-harness` | 掃描專案環境，自動產生或升級專屬且合規的 AGENTS.md 檔，整合 Harness 評估、閉環 Workflow 與編排架構。 |
+| 資訊安全 | `neo-iso-27001` | 依 ISO/IEC 27001 進行 ISMS 範圍、風險、證據、差距分析、稽核準備與改善計畫。 |
+| 隱私管理 | `neo-iso-27701` | 依 ISO/IEC 27701 進行 PIMS、PII 角色、處理活動、隱私風險、證據與稽核準備。 |
 | DevOps | `neo-azure-pipelines` | 建立、審查、除錯或現代化 Azure Pipelines YAML，尤其是 .NET build、Azure App Service 或 IIS 部署。 |
 | 需求釐清 | `neo-clarification` | 將模糊、情緒化、片段式、截圖式需求轉成規格、驗收條件或釐清問題。 |
 | Code Review | `neo-code-review` | 進行程式碼審查、PR/diff review、bug 風險掃描、安全性、效能或可維護性檢查。 |
@@ -61,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。 |
 
@@ -154,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.25",
+  "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-iso-27001/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: neo-iso-27001
+description: >
+  Use this skill when the user needs to establish, review, or improve an ISO/IEC 27001 ISMS,
+  perform information security risk discovery, define scope, create an evidence matrix,
+  conduct a gap analysis, draft a Statement of Applicability, prepare for an internal audit,
+  or create an improvement plan. Use neo-iso-27701 when the main concern is PII, privacy
+  management, or PIMS. Do not use this skill for legal advice or certification guarantees.
+license: MIT
+compatibility: Requires an Agent Skills client with Markdown and file-reading support; network access for current-version checks; and user-provided licensed documents for precise clause-level analysis.
+metadata:
+  version: "1.0.0"
+  pattern: "tool-wrapper,pipeline,reviewer"
+  domain: "information-security-management"
+  source-snapshot: "2026-08-12"
+---
+
+# Neo ISO/IEC 27001
+
+Provide evidence-based assistance for establishing, improving, or reviewing an information
+security management system (ISMS). Read `references/sources-and-scope.md` first, then follow
+the workflow below.
+
+## Scope and hard boundaries
+
+In scope:
+
+- ISMS implementation roadmaps, scope definition, and interested-party inventories.
+- Information security risk registers, treatment plans, and residual-risk tracking.
+- Evidence matrices, gap analyses, internal-audit preparation, and corrective actions.
+- Organization-specific Statement of Applicability (SoA) working drafts.
+
+Out of scope:
+
+- Guarantees about legal, regulatory, privacy-policy, or certification outcomes.
+- Clause-by-clause requirements, control lists, or verbatim reproduction without a licensed standard document.
+- Direct deployment of technical controls unless the user separately provides the technical requirements and authorized scope.
+
+## Version gate
+
+1. Use `ISO/IEC 27001:2022` as the default version baseline and check `ISO/IEC 27001:2022/Amd 1:2024` as an associated amendment.
+2. When answering about the "latest" or "current" version or new amendments, recheck official sources instead of treating this snapshot as current status.
+3. If the user provides only 2013-edition material, label it historical and do not mix it unmarked with 2022-edition requirements.
+4. Use precise clause-level analysis only with licensed local documents supplied by the user; otherwise provide only high-level workflows and items requiring verification.
+
+## Evidence-driven workflow
+
+Execute these steps in order. Do not invent organizational facts when evidence is missing:
+
+1. **Define the request and scope**: Confirm the organization, business processes, locations, systems, information assets, suppliers, interested parties, target version, and certification goal. Ask only the most specific necessary follow-up questions when key information is missing.
+2. **Build an evidence inventory**: For each policy, procedure, record, configuration, audit result, or interview note, record an identifier, source, owner, date, coverage, and reliability. Do not place passwords, tokens, or unnecessary personal data in the output.
+3. **Separate facts from judgments**: Label content as "verified fact," "evidence-based inference," or "insufficient data." Without organizational evidence, do not claim that a requirement is or is not satisfied.
+4. **Analyze risks and gaps**: Use the risk method supplied by the organization; if none is supplied, clearly label the method as a working assumption. Link every finding to evidence, impact, priority, owner, due date, and verification method.
+5. **Produce actionable drafts**: As requested, produce a scope statement, risk register, SoA working draft, evidence matrix, audit finding, or corrective-action plan. Mark every working draft with its version and approval status.
+6. **Run a delivery check**: Confirm that the output contains no invented clauses, certification conclusions, legal conclusions, or control evidence. Confirm that every high-risk action has an owner, due date, and verification signal.
+
+## Work-product format
+
+Unless the user requests a single fact, use this structure for assessments and reviews:
+
+```markdown
+## Conclusion
+## Applicable scope and version
+## Verified evidence
+## Risks and gaps
+## Improvement and corrective-action plan
+## Missing information and limitations
+## Sources and verification date
+```
+
+Each finding must include at least an identifier, evidence, problem, impact, priority, recommended action, owner, due date, and verification method. If a field cannot be completed, write "To be confirmed" instead of guessing.
+
+## Worksheet fields
+
+- **Scope table**: Organization, processes, locations, systems, information assets, exclusions, exclusion rationale, approver, and version.
+- **Risk register**: Risk identifier, scenario, asset or process, existing measures, risk method, treatment option, owner, due date, residual risk, and evidence.
+- **SoA working draft**: Requirement or control identifier, applicability status, organizational rationale, implementation evidence, owner, review date, referenced version, and approval status. Do not invent identifiers without a licensed standard.
+- **Evidence matrix**: Criteria source, evidence identifier, evidence owner, coverage period, evidence status, gap, remediation action, and verification method.
+
+## Routing to neo-iso-27701
+
+- Use `neo-iso-27701` when the main issue is PII processing, privacy responsibility, PIMS, or privacy evidence.
+- When information security and privacy are both in scope, complete the analyses separately and integrate them with explicit cross-references. Do not present one standard's conclusion as the other standard's conclusion.
+- The independent management-system status of 27701 does not mean that the organization has necessarily established 27001; verify the actual scope and evidence first.
+
+## Common pitfalls
+
+- Do not mix 2022-edition and 2013-edition documents, risk methods, or control mappings without labeling them.
+- An SoA is an organizational scope and risk-decision work product; do not infer it solely from a technology stack or industry name.
+- Implementing an ISMS, preparing for an audit, and obtaining third-party certification are different states; describe them separately.
+- Having a policy does not equal having effective evidence; check execution records, owners, coverage periods, and sampling results.
+- Every conclusion about the latest version must include a verification date and source; if network access is unavailable, state that current status cannot be confirmed.

package/skills/neo-iso-27001/evals/eval_queries.json

@@ -0,0 +1,86 @@
+[
+  {
+    "query": "Using ISO/IEC 27001:2022, inventory our current policies, risk register, and audit records and produce a gap analysis.",
+    "should_trigger": true
+  },
+  {
+    "query": "We need to establish an ISMS. Help define the organizational scope, information assets, and interested parties for our cloud product.",
+    "should_trigger": true
+  },
+  {
+    "query": "Design an ISO 27001 evidence matrix in which every evidence item has an owner, date, and remediation status.",
+    "should_trigger": true
+  },
+  {
+    "query": "I am preparing for an ISO/IEC 27001 internal audit. Give me a working format for findings and corrective actions.",
+    "should_trigger": true
+  },
+  {
+    "query": "Which ISO 27001 version should we check now? Verify the 2022 edition and the 2024 amendment.",
+    "should_trigger": true
+  },
+  {
+    "query": "Based on our risk register, plan an ISMS implementation and management-review improvement roadmap.",
+    "should_trigger": true
+  },
+  {
+    "query": "Review this SoA draft and identify items without a rationale, owner, or implementation evidence.",
+    "should_trigger": true
+  },
+  {
+    "query": "A customer requested ISO 27001 evidence, but we have only a few policy documents. Explain which verifiable evidence is still missing.",
+    "should_trigger": true
+  },
+  {
+    "query": "Compare the gaps between our current ISMS and the target certification scope, and classify recommendations as high, medium, or low priority.",
+    "should_trigger": true
+  },
+  {
+    "query": "We also process personal data. Complete the information-security scope analysis first, then identify which issues should be routed to the PIMS skill.",
+    "should_trigger": true
+  },
+  {
+    "query": "List every ISO/IEC 27001:2022 clause and Annex A control verbatim. I have not provided the official standard document.",
+    "should_trigger": true
+  },
+  {
+    "query": "Write an ASP.NET Core middleware that encrypts every API response.",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a vulnerability scanner in Python to scan our Kubernetes cluster.",
+    "should_trigger": false
+  },
+  {
+    "query": "Explain the PIMS and processor responsibilities in ISO/IEC 27701.",
+    "should_trigger": false
+  },
+  {
+    "query": "Help me create an audit plan for an ISO 9001 quality management system.",
+    "should_trigger": false
+  },
+  {
+    "query": "List the complete original text of every ISO/IEC 27002 control.",
+    "should_trigger": false
+  },
+  {
+    "query": "Determine whether we comply with GDPR and provide legal advice for the company.",
+    "should_trigger": false
+  },
+  {
+    "query": "Compare the current prices and discounts of three cloud providers.",
+    "should_trigger": false
+  },
+  {
+    "query": "Design a React login page that meets accessibility standards.",
+    "should_trigger": false
+  },
+  {
+    "query": "Convert a Git diff into a Conventional Commits message.",
+    "should_trigger": false
+  },
+  {
+    "query": "Answer with only the three English words in the CIA triad; do not perform any management-system analysis.",
+    "should_trigger": false
+  }
+]

package/skills/neo-iso-27001/evals/evals.json

@@ -0,0 +1,38 @@
+{
+  "skill_name": "neo-iso-27001",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We are a 40-person SaaS company whose scope includes product, support, and cloud operations. We have an asset inventory, risk register, and three months of access records, but no SoA. Using ISO/IEC 27001:2022, produce an implementation gap analysis and a 90-day improvement plan.",
+      "expected_output": "An evidence-driven gap analysis in English that first lists the organizational scope and assumptions, then verified evidence, gaps, priorities, owners, and due dates, while labeling the SoA as an approval-pending working draft.",
+      "assertions": [
+        "The output contains sections for organizational scope, evidence, gaps, and an improvement plan",
+        "Each major action includes an owner, due date, and verification method, or is explicitly marked to be confirmed",
+        "The output does not claim that the company has obtained or will necessarily obtain certification",
+        "Unavailable SoA content is labeled as a working draft or insufficient data"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "What is the current ISO 27001 baseline? Tell me the status of the 2022 edition and the 2024 amendment, including the verification date and sources.",
+      "expected_output": "The answer lists ISO/IEC 27001:2022 and ISO/IEC 27001:2022/Amd 1:2024, includes the verification date and official sources, and identifies details that public metadata cannot establish.",
+      "assertions": [
+        "The answer mentions ISO/IEC 27001:2022",
+        "The answer mentions ISO/IEC 27001:2022/Amd 1:2024",
+        "The answer includes official source links and a verification date",
+        "The answer does not reproduce standard clauses or a complete control catalogue"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "List every ISO/IEC 27001:2022 clause and Annex A control and tell me which ones are definitely applicable. I have not provided the official standard document.",
+      "expected_output": "A safe and honest limitation statement that refuses to reproduce restricted full text or guess applicability, and provides an evidence-inventory and SoA workflow that can be used after licensed documents are supplied.",
+      "assertions": [
+        "The answer refuses to provide complete clauses or a complete control catalogue",
+        "The answer explains that definite applicability cannot be determined without the official standard document",
+        "The answer provides an actionable alternative workflow",
+        "The answer requests licensed documents or organizational evidence"
+      ]
+    }
+  ]
+}

package/skills/neo-iso-27001/references/sources-and-scope.md

@@ -0,0 +1,23 @@
+# ISO/IEC 27001 Sources and Scope
+
+## Version snapshot
+
+- Baseline document: `ISO/IEC 27001:2022`, Edition 3, published in 2022-10.
+- Amendment: `ISO/IEC 27001:2022/Amd 1:2024`, published in 2024-02, titled Climate action changes.
+- Snapshot verification date: 2026-08-12.
+- The 2013 edition is historical material only in this skill and is not the current baseline.
+
+## Sources to verify
+
+- [ISO/IEC 27001:2022 official page](https://www.iso.org/standard/27001)
+- [ISO/IEC 27001:2022/Amd 1:2024 official page](https://www.iso.org/standard/88435.html)
+- [ISO Open Data](https://www.iso.org/open-data.html)
+- [ODC-By 1.0 license for ISO Deliverables Metadata](https://opendatacommons.org/licenses/by/1-0/)
+
+## Usage rules
+
+1. This file stores only version metadata, source links, and original workflows. It does not store the full ISO standard, paid PDFs, verbatim clauses, or a complete control catalogue.
+2. Use `ISO Open Data` to verify standard metadata; attribute ISO and the ODC-By 1.0 license when using it.
+3. When the user provides a licensed document, the Agent may read the local document and cite clause identifiers within that license's scope. Do not copy long passages or the full document into a response or the repository.
+4. When the user asks about the latest version, amendments, certification transition, or applicability, recheck official sources and the user's organizational evidence.
+5. Official version pages are entry points for version verification but do not replace the formal standard document held by the user.

package/skills/neo-iso-27701/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: neo-iso-27701
+description: >
+  Use this skill when the user needs to establish, review, or improve an ISO/IEC 27701 PIMS,
+  inventory PII processing, analyze controller and processor responsibilities, create a privacy
+  risk or evidence matrix, conduct a gap analysis, prepare for an audit, or create an improvement
+  plan. Use neo-iso-27001 when the main concern is ISMS or information security risk. Do not treat
+  PIMS as a legal-compliance guarantee for any specific privacy law.
+license: MIT
+compatibility: Requires an Agent Skills client with Markdown and file-reading support; network access for current-version and regulatory checks; and user-provided licensed documents for precise clause-level analysis.
+metadata:
+  version: "1.0.0"
+  pattern: "tool-wrapper,pipeline,reviewer"
+  domain: "privacy-information-management"
+  source-snapshot: "2026-08-12"
+---
+
+# Neo ISO/IEC 27701
+
+Provide evidence-based assistance for establishing, improving, or reviewing a privacy information
+management system (PIMS). Read `references/sources-and-scope.md` first, then follow the workflow
+below.
+
+## Scope and hard boundaries
+
+In scope:
+
+- PIMS implementation, scope definition, and PII processing-context inventories.
+- Responsibilities, accountability, and evidence for PII controllers and PII processors.
+- Privacy risk registers, processing-activity worksheets, supplier evidence, and gap analyses.
+- Privacy-audit preparation, corrective actions, and continual-improvement plans.
+
+Out of scope:
+
+- Legal advice, legal-basis determinations, or compliance guarantees for any specific jurisdiction.
+- Clause-by-clause requirements, control lists, or verbatim reproduction without a licensed standard document.
+- Treating an ISO/IEC 27701 certificate or PIMS implementation as direct proof of GDPR or other privacy-law compliance.
+- Exposing raw personal data, passwords, tokens, or unnecessary sensitive data in the output.
+
+## Version gate
+
+1. Use `ISO/IEC 27701:2025`, Edition 2, as the default version baseline; treat `ISO/IEC 27701:2019` as historical material only.
+2. The 2025 edition can operate as an independent management-system standard; do not assume that the organization has established or must first establish ISO/IEC 27001.
+3. When answering about the "latest" or "current" version or differences between 2019 and 2025, recheck official sources instead of treating this snapshot as current status.
+4. Use precise clause-level analysis only with licensed local documents supplied by the user; otherwise provide only high-level workflows and items requiring verification.
+
+## Evidence-driven workflow
+
+Execute these steps in order. Do not invent privacy facts when evidence is missing:
+
+1. **Define the PIMS context**: Confirm the organization, processes, locations, systems, PII types, data subjects, recipients, suppliers, retention and transfer contexts, jurisdictions, organizational roles, and target version. Legal judgments require separately specified official regulatory sources.
+2. **Identify roles and responsibilities**: Record whether the organization is a PII controller, PII processor, or another role for each processing activity. Do not infer a role only from a contract title.
+3. **Build an evidence inventory**: For privacy policies, processing-activity records, contracts, supplier assessments, rights-request records, incident records, retention and deletion records, or training records, record an identifier, source, owner, date, coverage, and reliability.
+4. **Separate facts from judgments**: Label content as "verified fact," "evidence-based inference," or "insufficient data." Without an applicable jurisdiction and legal source, do not determine a legal basis or statutory deadline.
+5. **Analyze privacy risks and gaps**: Link the processing activity, PII risk, existing measures, impact, priority, owner, due date, remediation action, and verification method.
+6. **Produce actionable drafts**: As requested, produce a processing-activity worksheet, role-and-responsibility table, privacy risk register, evidence matrix, audit finding, or improvement plan, and mark its version and approval status.
+7. **Run a delivery check**: Confirm that the output does not equate PIMS with legal compliance, expose PII, invent clauses or certification conclusions, and that every high-risk action has an owner, due date, and verification signal.
+
+## Work-product format
+
+Unless the user requests a single fact, use this structure for assessments and reviews:
+
+```markdown
+## Conclusion
+## PIMS scope, roles, and version
+## Verified evidence
+## Privacy risks and gaps
+## Improvement and corrective-action plan
+## Missing information, jurisdiction questions, and limitations
+## Sources and verification date
+```
+
+Each finding must include at least an identifier, processing activity or evidence, problem, impact, priority, recommended action, owner, due date, and verification method. If a field cannot be completed, write "To be confirmed" instead of guessing.
+
+## Worksheet fields
+
+- **Processing-activity table**: Activity, purpose, PII type, data subject, source, recipient, role, system, supplier, retention and transfer information, evidence identifier, and review date.
+- **Role-and-responsibility table**: Processing activity, organizational role, accountable owner, contract or process evidence, exception, review date, and items to be confirmed.
+- **Privacy risk register**: Risk identifier, processing activity, scenario, impact, existing measures, risk method, treatment option, owner, due date, residual risk, and evidence.
+- **Evidence matrix**: Criteria source, evidence identifier, evidence owner, coverage period, evidence status, gap, remediation action, and verification method.
+
+## Integration with neo-iso-27001
+
+- Use `neo-iso-27001` when the main issue is information security management, information-asset risk, or ISMS.
+- When ISMS and PIMS are both in scope, establish the two scope, risk, and evidence chains separately, then document shared processes and cross-dependencies.
+- Do not assume that the same policy, risk assessment, or evidence automatically satisfies the other standard merely because both are management systems.
+
+## Regulatory routing
+
+- When the user asks about GDPR, a personal-data law, or another regulation, first confirm the jurisdiction, applicable role, processing activity, and regulatory version; then request or find the regulator, legal text, or other authoritative legal source.
+- ISO/IEC 27701 can serve as a working privacy-management framework, but it cannot by itself prove full compliance with a specific law.
+- If the regulatory source, organizational role, or processing purpose is missing, report insufficient data and items to be confirmed instead of inferring a legal conclusion.
+
+## Common pitfalls
+
+- Do not apply the historical extension relationship of the 2019 edition directly to the 2025 edition, and do not describe the 2025 edition as necessarily dependent on 27001.
+- Having a privacy policy does not equal having effective evidence; check execution records, accountable owners, coverage periods, and exception handling.
+- Determine controller and processor roles from concrete processing activities and responsibility evidence, not only from the organization's label or a contract title.
+- Every conclusion about the latest version or a regulation must include a verification date and source; if network access is unavailable, state that current status cannot be confirmed.

package/skills/neo-iso-27701/evals/eval_queries.json

@@ -0,0 +1,82 @@
+[
+  {
+    "query": "Using ISO/IEC 27701, inventory the PII processing activities and controller and processor roles for our SaaS product.",
+    "should_trigger": true
+  },
+  {
+    "query": "We need to establish a PIMS. Produce the fields for a privacy risk register and evidence matrix.",
+    "should_trigger": true
+  },
+  {
+    "query": "Review our supplier data-processing contracts, deletion records, and rights-request records and identify privacy-audit gaps.",
+    "should_trigger": true
+  },
+  {
+    "query": "What is the current version of ISO/IEC 27701? What is the status difference between the 2019 and 2025 editions?",
+    "should_trigger": true
+  },
+  {
+    "query": "Plan a 90-day improvement program that takes the company from PII processing inventory to a PIMS internal audit.",
+    "should_trigger": true
+  },
+  {
+    "query": "We have both an ISMS and a PIMS. Separate shared evidence from privacy evidence that must be prepared separately.",
+    "should_trigger": true
+  },
+  {
+    "query": "Create an accountability worksheet based on the data subject, recipient, retention period, and supplier for each processing activity.",
+    "should_trigger": true
+  },
+  {
+    "query": "Determine whether this cloud service is a PII controller or processor in each data flow, and list the required evidence.",
+    "should_trigger": true
+  },
+  {
+    "query": "We are implementing ISO 27701 for a multinational product. List the questions to ask first when jurisdiction, data-transfer, and role information is incomplete.",
+    "should_trigger": true
+  },
+  {
+    "query": "Check whether this PIMS gap report incorrectly describes the ISO management framework as proof of GDPR compliance.",
+    "should_trigger": true
+  },
+  {
+    "query": "Write a JavaScript function that encrypts a user's name before storing it in a database.",
+    "should_trigger": false
+  },
+  {
+    "query": "Prepare a GDPR legal opinion that directly determines that we are fully compliant.",
+    "should_trigger": false
+  },
+  {
+    "query": "Create an information security risk register using ISO/IEC 27001 without discussing personal data.",
+    "should_trigger": false
+  },
+  {
+    "query": "Paste the original text of every ISO/IEC 27701:2025 clause. I have not purchased the standard.",
+    "should_trigger": true
+  },
+  {
+    "query": "Design a Vue 3 personal-data consent checkbox and provide the component code.",
+    "should_trigger": false
+  },
+  {
+    "query": "Compare the current license prices of Salesforce, HubSpot, and Dynamics.",
+    "should_trigger": false
+  },
+  {
+    "query": "Rewrite this Chinese privacy policy so that it sounds more like a native speaker wrote it.",
+    "should_trigger": false
+  },
+  {
+    "query": "Create a database migration that adds a consented_at column.",
+    "should_trigger": false
+  },
+  {
+    "query": "Turn the audit findings into Conventional Commits.",
+    "should_trigger": false
+  },
+  {
+    "query": "Explain only the English abbreviation PII; do not perform PIMS or privacy-management analysis.",
+    "should_trigger": false
+  }
+]

package/skills/neo-iso-27701/evals/evals.json

@@ -0,0 +1,38 @@
+{
+  "skill_name": "neo-iso-27701",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We provide a customer-support SaaS service. We process customer data and determine the purposes of processing for some analytics activities. Create working drafts for PII processing activities, role responsibilities, privacy risks, and an evidence matrix, and list the insufficient data.",
+      "expected_output": "An English PIMS working draft that separately presents processing activities, roles, risks, evidence, and items to be confirmed, without making unverifiable legal-role or compliance conclusions.",
+      "assertions": [
+        "The output distinguishes processing activities, role responsibilities, privacy risks, and evidence",
+        "The output does not infer a role only from the company name or contract title",
+        "The output includes insufficient data and items to be confirmed",
+        "The output does not claim compliance with GDPR or another specific privacy law"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Which version of ISO/IEC 27701 should we use now? Explain whether the 2025 edition must depend on ISO/IEC 27001, and include the verification date and official sources.",
+      "expected_output": "The answer lists ISO/IEC 27701:2025, Edition 2, the verification date, and official sources, correctly explains that the 2025 edition can operate as an independent management-system standard, and states that integration with 27001 still depends on organizational needs.",
+      "assertions": [
+        "The answer mentions ISO/IEC 27701:2025",
+        "The answer identifies Edition 2 or equivalent version information",
+        "The answer explains that the 2025 edition does not necessarily depend on ISO/IEC 27001",
+        "The answer includes official source links and a verification date"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "List every privacy control in ISO/IEC 27701:2025 and directly determine our GDPR legal basis. I have not provided the official standard or a jurisdiction.",
+      "expected_output": "A safe and honest limitation statement that refuses to reproduce restricted complete controls or guess a legal basis, and provides a PIMS evidence-analysis workflow to use after licensed documents and jurisdiction information are supplied.",
+      "assertions": [
+        "The answer refuses to provide a complete clause or control catalogue",
+        "The answer explains that a legal basis cannot be determined without a jurisdiction and the official standard",
+        "The answer provides an alternative workflow for inventorying processing activities, roles, evidence, and risks",
+        "The answer does not equate PIMS with GDPR compliance"
+      ]
+    }
+  ]
+}

package/skills/neo-iso-27701/references/sources-and-scope.md

@@ -0,0 +1,24 @@
+# ISO/IEC 27701 Sources and Scope
+
+## Version snapshot
+
+- Baseline document: `ISO/IEC 27701:2025`, Edition 2, published in 2025-10; the IEC product page lists the publication date as 2025-10-14.
+- Historical document: `ISO/IEC 27701:2019`, replaced and withdrawn by the 2025 edition.
+- The official 2025 edition page states that it can operate as an independent management-system standard; this skill does not assume that it must depend on ISO/IEC 27001.
+- Snapshot verification date: 2026-08-12.
+
+## Sources to verify
+
+- [ISO/IEC 27701:2025 official page](https://www.iso.org/standard/27701?browse=tc)
+- [ISO/IEC 27701:2025 IEC product page](https://webstore.iec.ch/en/publication/110123)
+- [ISO/IEC 27701:2019 historical page](https://www.iso.org/standard/71670.html)
+- [ISO Open Data](https://www.iso.org/open-data.html)
+- [ODC-By 1.0 license for ISO Deliverables Metadata](https://opendatacommons.org/licenses/by-1-0/)
+
+## Usage rules
+
+1. This file stores only version metadata, source links, and original workflows. It does not store the full ISO standard, paid PDFs, verbatim clauses, or a complete control catalogue.
+2. Use `ISO Open Data` to verify standard metadata; attribute ISO and the ODC-By 1.0 license when using it.
+3. When the user provides a licensed document, the Agent may read the local document and cite clause identifiers within that license's scope. Do not copy long passages or the full document into a response or the repository.
+4. When the user asks about the latest version, version differences, certification transition, or legal applicability, recheck official sources and the user's organizational evidence.
+5. The ISO/IEC 27701 management-system framework does not replace applicable law, regulator interpretations, or legal advice.

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)