Azure Messaging SDK Troubleshooter
Diagnose Azure Event Hubs and Service Bus SDK failures across connectivity, authentication, and message processing.
The skill is scoped to Azure Event Hubs and Service Bus troubleshooting, with no evidence of malware or grossly excessive permissions. However, it asks users to inspect connection strings, entity names, and consumer groups without documenting redaction, least privilege, confirmation, data flows, rollback, or external-change boundaries, so points are deducted.
The workflow gives a plausible sequence for SDK identification, health checks, error matching, documentation lookup, and configuration review. It lacks skill-specific scripts, examples, abnormal-input handling, and diagnosable failure messages; the MCP tool inventory is also internally inconsistent, so the static score remains limited.
Trigger terms and scenarios cover connectivity, authentication, locks, reconnection, checkpoints, and batch processing, giving the skill a reasonably clear target. It does not define non-fit boundaries, input/output formats, version boundaries, Chinese-language support, or mainland-China network reachability, so points are deducted.
The SKILL.md is readable and layered with metadata, a quick reference, usage conditions, tool tables, and a workflow. MIT licensing, authorship, and version are stated, but the referenced azure-diagnostics path is not supplied in the evidence, and installation notes, examples, FAQs, limitations, changelog, and explicit maintenance/update ownership are missing.
The skill can provide directional troubleshooting for Azure messaging SDK problems and instructs the agent to cite Microsoft Learn. It provides no concrete commands, parameters, language-specific procedures, or directly usable diagnostic-output format, while relying on external MCP tools and an unavailable reference path, so substantial follow-up work may remain.
The repository includes general CI, evaluation workflows, and harness tests, providing some audit context. The supplied evidence does not show azure-messaging-specific tests, real execution results, or independent corroboration, and the core referenced troubleshooting material is absent, so verifiability is limited.
- The quick reference lists only two MCP tools, while the later table lists five; actual tool names and permissions should be confirmed.
- “Apply remediation” may affect external Azure resources or configuration, but no user confirmation, change scope, or recovery procedure is defined.
- Connection strings and other credential-related data should be explicitly redacted and prohibited from diagnostic output.
- The key troubleshooting guides under azure-diagnostics are absent from the supplied evidence, so their content, version, and reachability cannot be verified.
- There is no evidence of mainland-China network access, Chinese documentation, or Chinese-language error handling.
What does this skill do, and when should you use it?
azure-messaging is a focused skill in the microsoft/skills repository for troubleshooting Azure Event Hubs and Azure Service Bus SDKs. It addresses connection failures, authentication errors, AMQP link problems, message and session lock expiry, stalled processors, duplicate events, and checkpoint offset resets. Its workflow combines Azure MCP resource and messaging operations, resource health checks, diagnostic-log queries, and Microsoft Learn searches. It is a good fit for developers debugging existing Azure messaging applications, but it is not presented as a general messaging architecture guide or complete SDK tutorial.
Identifies SDK and version clues, checks namespace health, reviews error messages and AMQP failures, verifies connection strings, entity names, and consumer groups, lists Event Hubs and Service Bus resources through MCP tools, queries diagnostic logs with KQL, searches Microsoft Learn for relevant guidance, and produces documentation-backed remediation recommendations.
- An Event Hubs developer is investigating receiver disconnects, missing events, stalled event processing, or checkpoint resets.
- A Service Bus developer is troubleshooting authentication failures, AMQP link detach errors, or disconnected receivers.
- A team processing messages in batches is dealing with lost locks, failed lock renewal, or batch lock timeouts.
- A session-based Service Bus application is reporting expired session locks or session receiver errors.
- An engineer needs to distinguish Azure service health, diagnostic-log evidence, configuration errors, and SDK behavior.
What are this skill's strengths and limitations?
- Targets both Azure Event Hubs and Azure Service Bus.
- Covers connectivity, authentication, AMQP, locks, sessions, checkpoints, and message processing.
- Provides a concrete diagnostic sequence instead of only generic troubleshooting advice.
- Can use MCP tools for resource discovery, health checks, diagnostic logs, and documentation search.
- Requires access to Azure MCP tools; their setup and permission model are not documented in the supplied material.
- Focuses on troubleshooting rather than complete application development or messaging architecture.
- No independent test coverage or language-specific examples are provided for this individual skill.
- The quality of diagnosis depends on available errors, Azure state, logs, and documentation results.
How do you install this skill?
The skill is located at .github/plugins/azure-skills/skills/azure-messaging/SKILL.md. To install the collection, run npx skills add microsoft/skills and select the required skill in the wizard. The README also documents Copilot CLI installation: /plugin marketplace add microsoft/skills, followed by /plugin install azure-skills@skills. A dedicated single-skill installation command is not documented in the supplied source.
How do you use this skill?
In an agent with this skill loaded and Azure MCP access configured, provide a concrete issue such as Troubleshoot receiver disconnected errors in my Event Hubs consumer or Investigate message lock expired during Service Bus batch processing. The documented workflow checks SDK clues, resource health, errors, documentation, and configuration. The source does not define a fixed invocation syntax for a particular programming language.