@moon791017/neo-skills 1.1.26 → 1.1.28

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.28",
   "type": "module",
   "description": "Neo Skills: A Universal AI Agent Skills Extension",
   "homepage": "https://neo-blog-iota.vercel.app/",

package/skills/neo-code-review/SKILL.md

@@ -3,45 +3,56 @@ name: neo-code-review
 description: >
   Use this skill when the user asks to review or audit source code, a PR, diff, commit,
   or recent changes for bugs, security, performance, tests, compatibility, or
-  maintainability. Also use it after an AI agent finishes modifying code to inspect the
-  current uncommitted working tree before handoff and report actionable findings with
-  file and line evidence.
+  maintainability, duplicated code or logic across files, or hard-coded values. Also use
+  it after an AI agent finishes modifying code to inspect the current uncommitted working
+  tree before handoff and report actionable findings with file and line evidence.
 compatibility: Requires Python 3.11+ and uv for the Git change helper.
 ---
 
 # Code Review
 
-Use the Reviewer workflow. Keep the review read-only and report only evidence-backed, actionable findings.
+Follow this read-only workflow. Report only actionable findings supported by evidence.
 
 ## Trigger On
 
 - The user requests a code, PR, diff, commit, security, performance, test, or maintainability review.
+- The user asks whether code or logic is duplicated across files, or whether hard-coded values should be centralized.
 - An AI Agent finishes modifying code, tests, configuration, or scripts before handoff.
 
 ## Workflow
 
-1. **Collect the review scope**
-   - Use the files or code snippets supplied by the user as the primary scope.
-   - If no scope is supplied inside a Git repository, run:
+1. **Define the review scope**
+   - Use the files or snippets supplied by the user as the primary scope.
+   - If the user provides no scope and the current directory is a Git repository, run:
      ```bash
      uv run skills/neo-code-review/scripts/git-diff-reviewer.py --working-tree
      ```
    - Use `--staged` for staged-only changes and `--commit <range>` for a commit range.
    - Read surrounding code, related tests, and existing contracts. If no reviewable input exists, report it and stop.
+   - For a working-tree review, include the helper's tracked diff and each non-ignored untracked file as separate inputs.
 
-2. **Load the rules**
+2. **Load the review rules**
    - Read [review-checklist.md](references/review-checklist.md) before evaluating code.
    - Identify the actual language, framework, and affected behavior from the change. Do not infer unverified rules from filenames.
 
-3. **Analyze risk**
+3. **Run the cross-file consistency scan**
+   - Build the comparison set from the review targets and relevant repository source and configuration files. Use `rg --files` and the repository's ignore rules. Exclude dependency, vendor, cache, generated, minified, build, and coverage output unless a file is explicitly in scope.
+   - Inventory changed or reviewed functions, classes, validation and authorization rules, state transitions, request or query construction, error handling, and distinctive literals such as URLs, routes, timeouts, retry counts, thresholds, regexes, feature flags, and error messages.
+   - Search the comparison set for exact and near-exact matches, then read each match in context. Ignore name and formatting differences when the behavior matches. Treat renamed or slightly rearranged copies as duplicates when their business rules, inputs, side effects, and failure behavior are materially the same.
+   - Report only meaningful duplication: copied implementation, duplicated business or validation logic, divergent security or state logic, or repeated non-trivial hard-coded configuration. Do not report a match based only on a common keyword, normal one-time literal, test fixture, snapshot, generated file, or vendor code.
+   - For every cross-file finding, cite both file paths and line numbers. Explain the concrete maintenance, divergence, security, or behavior risk and recommend a specific shared helper, constant, configuration source, or other single source of truth.
+   - If the user supplied only a snippet or specific files without repository context, state in `## Validation` that cross-file verification was unavailable. Never invent repository matches or line evidence.
+
+4. **Analyze risk**
    - Prioritize correctness, regressions, security, data consistency, resource lifetime, concurrency, and high-risk test gaps.
    - `🔴 Critical Issues` contain only security vulnerabilities, data loss, incorrect behavior, authorization bypasses, or major regressions.
    - `🟡 Suggestions` contain only actionable, non-blocking issues with a clear impact and remediation direction.
+   - Classify ordinary duplicated logic or hard-coded configuration as `🟡 Suggestions`. Classify hard-coded secrets or duplication that creates a demonstrable security or behavior defect as `🔴 Critical Issues`.
    - Do not report preferences, unsupported speculation, or checklist items that were not triggered by evidence.
 
-4. **Produce a concise report**
+5. **Produce a concise report**
    - Write in English and preserve file paths and line numbers, such as `src/user.ts:42`.
-   - Use this structure. Write `None` when a section has no findings; do not omit the severity sections:
+   - Use this structure. Keep all severity sections and write `None` when a section has no findings:
 
      ```markdown
      ## 🔍 Review Summary
@@ -56,15 +67,18 @@ Use the Reviewer workflow. Keep the review read-only and report only evidence-ba
 
      ## 🟡 Suggestions
      - **Location**: `path:line`
+       - **Type**: Duplicated logic, duplicated hard-coded value, or another applicable category.
+       - **Evidence**: The matching location and the relevant behavior or value in each file.
        - **Recommendation**: Specific, non-blocking improvement.
 
      ## 🟢 Strengths
      - List only strengths directly supported by the change.
 
      ## Validation
-     - List executed tests, builds, or checks that were not run.
+     - State the cross-file comparison scope and any unavailable repository context.
+     - List executed tests, builds, and checks. Name any that were not run.
      ```
 
-5. **Apply the delivery gate**
+6. **Apply the delivery gate**
    - If an automatic review finds `🔴 Critical Issues`, cannot establish the review scope, or cannot load the skill, do not declare completion or hand off.
    - After fixing findings, rerun the required checks and review the changes again.

package/skills/neo-code-review/evals/eval_queries.json

@@ -10,7 +10,10 @@
     "Is this TypeScript code well designed? What should be improved?",
     "Check this SQL query for performance problems, slow queries, or missing indexes",
     "Run static code analysis and identify problems in this Go project",
-    "An AI Agent just finished modifying code. Review the uncommitted changes before handoff"
+    "An AI Agent just finished modifying code. Review the uncommitted changes before handoff",
+    "Review this pull request and check whether validation logic or hard-coded limits are duplicated in other source files",
+    "Audit the repository for copy-pasted business rules and repeated URLs, timeouts, or thresholds introduced by these changes",
+    "Check whether the same implementation appears in different files and whether repeated configuration should be centralized"
   ],
   "should_not_trigger": [
     "How do I install Git?",
@@ -23,6 +26,8 @@
     "Translate this Python code into Rust",
     "What is the principle behind SQL injection?",
     "Generate today's development progress report",
-    "Run the current project's tests only; do not perform a code review"
+    "Run the current project's tests only; do not perform a code review",
+    "How should I extract duplicated code into a shared helper?",
+    "Write a script that detects repeated literals across a repository"
   ]
 }

package/skills/neo-code-review/evals/evals.json

@@ -36,6 +36,40 @@
         "If 🔴 Critical Issues are found, the status blocks delivery",
         "The report invents no findings when no changes exist"
       ]
+    },
+    {
+      "id": 4,
+      "prompt": "Review these changed TypeScript files for correctness and compare them with each other for duplicated logic and hard-coded values. File: src/orders/createOrder.ts\n```typescript\nconst MAX_ITEMS = 50;\n\nexport function validateCreateItems(items: Item[]): void {\n  if (items.length > MAX_ITEMS) throw new Error('Too many items');\n  for (const item of items) {\n    if (item.quantity <= 0) throw new Error('Invalid quantity');\n  }\n}\n```\nFile: src/orders/updateOrder.ts\n```typescript\nconst MAX_ITEMS = 50;\n\nexport function validateUpdateItems(items: Item[]): void {\n  if (items.length > MAX_ITEMS) throw new Error('Too many items');\n  for (const item of items) {\n    if (item.quantity <= 0) throw new Error('Invalid quantity');\n  }\n}\n```",
+      "expected_output": "A concise English review report that identifies the duplicated item-validation logic and repeated MAX_ITEMS hard-coded value in both files, cites both file locations, classifies the maintainability issue as a 🟡 Suggestion rather than a 🔴 Critical Issue, and recommends extracting shared validation and a single source of truth for the limit. It must not invent unrelated defects.",
+      "assertions": [
+        "The report contains both src/orders/createOrder.ts and src/orders/updateOrder.ts as evidence locations",
+        "The report identifies the duplicated validation behavior rather than only matching function names",
+        "The report identifies the repeated MAX_ITEMS value as hard-coded configuration duplication",
+        "The duplication findings appear under 🟡 Suggestions and do not block delivery",
+        "The report recommends a shared validator and centralized constant or configuration",
+        "The report contains no unsupported security, performance, or correctness findings"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Review these two test files and check for meaningful cross-file duplication or hard-coded configuration. File: tests/orders.test.ts\n```typescript\nit('returns HTTP 200 for a valid order', async () => {\n  expect(response.status).toBe(200);\n});\n```\nFile: tests/payments.test.ts\n```typescript\nit('returns HTTP 200 for a valid payment', async () => {\n  expect(response.status).toBe(200);\n});\n```\nThese tests cover different endpoints and share only a normal HTTP status literal.",
+      "expected_output": "A concise English review report that performs or clearly scopes the cross-file check but reports no duplication finding. It must not treat a normal repeated test literal or separate endpoint fixture as meaningful hard-coded configuration, and it must not invent other issues.",
+      "assertions": [
+        "The report does not raise a duplicated-logic or hard-coded-configuration finding for the shared 200 test literal",
+        "The report does not claim the two endpoint tests implement the same business rule",
+        "The report explicitly states the cross-file scan scope or limitation",
+        "The report invents no unrelated findings"
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "Review only this Python snippet and check whether the same code or hard-coded values appear in other files:\n```python\ndef is_active(user):\n    return user.status == 'active'\n```\nNo repository or additional files are available.",
+      "expected_output": "A concise English review report that states the supplied snippet was reviewed but cross-file verification was unavailable because no repository context or additional files were provided. It must not invent duplicate locations or line evidence.",
+      "assertions": [
+        "The report states that cross-file verification could not be performed",
+        "The report does not invent another file path, duplicate match, or line number",
+        "The report still uses the required review sections and severity headings"
+      ]
     }
   ]
 }

package/skills/neo-code-review/references/review-checklist.md

@@ -1,8 +1,8 @@
 # Code Review Checklist
 
-This checklist is the review baseline for `neo-code-review`. During review, compare the code changes against these criteria and categorize findings by severity: Critical Issues (🔴 Must-fix), Suggestions (🟡 Clean Code/Performance), and Praise (🟢 High Quality).
+Use this checklist as the baseline for `neo-code-review`. Compare each change against these criteria and report findings under `Critical Issues` (🔴 must fix), `Suggestions` (🟡 non-blocking), or `Strengths` (🟢).
 
-Only report a finding when the risk is supported by the diff, surrounding code, tests, runtime behavior, or a clearly stated requirement. Do not turn every checklist item into a finding.
+Report a finding only when the diff, surrounding code, tests, runtime behavior, or a stated requirement supports the risk. Do not turn every checklist item into a finding.
 
 ---
 
@@ -122,8 +122,18 @@ Only list SOLID/design findings when the violation clearly increases defect risk
   - Is a function, method, component, or query too long or deeply nested to review safely?
   - Is cyclomatic complexity high enough to hide bugs or make tests brittle?
 - [ ] **Modularity & Duplication**:
-  - Does the code avoid meaningful duplication, copy-pasted business rules, and divergent validation logic?
+  - Does the code avoid meaningful duplication and copy-pasted implementations across changed and relevant repository files?
+  - Are business, validation, authorization, state-transition, error-handling, or request/query rules implemented in more than one place?
+  - Are apparently different implementations materially equivalent after comparing inputs, conditions, side effects, and failure behavior?
   - Is shared behavior placed at the right abstraction level without over-engineering?
+- [ ] **Hard-coded Values & Single Source of Truth**:
+  - Are non-trivial URLs, routes, timeouts, retry counts, thresholds, regexes, feature flags, error messages, or other configuration values repeated across production files?
+  - Should a repeated value be moved to a shared constant, configuration source, or domain-level policy to prevent drift?
+  - Are hard-coded credentials, tokens, private keys, or other secrets treated as security findings rather than ordinary maintainability suggestions?
+  - Do not report common one-time literals, test fixtures, snapshots, generated files, vendor code, or matches based only on a shared keyword.
+- [ ] **Cross-file Evidence**:
+  - Does every duplication finding cite both file paths and line numbers with enough surrounding context to verify the match?
+  - If repository context is unavailable, does the review state that cross-file verification could not be performed instead of inventing evidence?
 - [ ] **Testability**:
   - Is the code easy to unit test or integration test?
   - Are dependencies injectable or isolatable where tests need control over time, I/O, network calls, randomness, or external systems?

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)