azure-diagnostics
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, troubleshoot functions, troubleshoot AKS, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, service bus dead letter.
63
73%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugin/skills/azure-diagnostics/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description with excellent trigger term coverage and completeness. The WHEN clause is comprehensive and includes highly specific, natural terms users would use when encountering Azure production issues. The main weakness is that the 'what' portion could be more specific about concrete actions beyond 'debug' and 'safe triage' — listing specific diagnostic steps or outputs would improve specificity.
Suggestions
Expand the initial capability statement with more concrete actions, e.g., 'Diagnoses Azure production issues by querying logs with KQL, analyzing resource health, inspecting pod states, and recommending remediation steps using AppLens, Azure Monitor, and safe triage procedures.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Azure production issues) and mentions specific tools (AppLens, Azure Monitor, resource health), but the 'what it does' is limited to 'debug' and 'safe triage' — it doesn't list multiple concrete actions like 'analyze logs, query metrics, check resource health status, inspect pod states'. | 2 / 3 |
Completeness | The description explicitly answers both 'what' (debug Azure production issues using specific tools) and 'when' (with a clear 'WHEN:' clause listing extensive trigger scenarios). The explicit WHEN clause with detailed triggers satisfies the completeness requirement. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would actually say: 'high CPU', 'deployment failure', 'crashloop', 'pod pending', 'node not ready', 'cold start issues', 'dead letter', 'AMQP connection failure', 'KQL', 'kubectl cannot connect', etc. These are highly specific and match real user language. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — the combination of Azure-specific services (App Service, Container Apps, Functions, AKS, Event Hubs, Service Bus) with specific tools (AppLens, Azure Monitor, KQL) and very specific error conditions (CrashLoop, CoreDNS failures, AMQP connection failure, message lock lost) creates a clear niche unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill serves well as a routing/overview document with strong progressive disclosure and clear service-to-reference mapping. However, it's weakened by verbose trigger lists that duplicate frontmatter, a generic diagnosis flow that doesn't add value beyond what Claude already knows, and MCP tool examples that use ambiguous pseudo-syntax rather than clearly executable patterns. The actionability would improve significantly with more concrete, copy-paste-ready examples.
Suggestions
Remove or drastically shorten the Triggers section — this duplicates the YAML description and Claude doesn't need to be told when to activate a skill in the body content.
Remove the 'AUTHORITATIVE GUIDANCE' banner and the generic 5-step Quick Diagnosis Flow, which describe things Claude already knows how to do.
Make MCP tool examples more concrete with a realistic worked example showing actual resource IDs and expected output patterns, or clarify the exact invocation syntax (is it a function call? tool_use block?).
Add validation/feedback loops to the diagnostic workflow, e.g., 'If resource health shows Available but app is failing → skip to logs; if Degraded → check Azure status page before proceeding.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The triggers section is overly verbose, essentially restating the YAML description. The 'AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE' banner is unnecessary filler. The quick diagnosis flow is generic knowledge Claude already possesses. However, the reference table and command sections are reasonably efficient. | 2 / 3 |
Actionability | Provides some concrete CLI commands and MCP tool invocation patterns, but many are incomplete (placeholder values without guidance on how to obtain them). The MCP tool examples use a pseudo-syntax that isn't clearly executable. The quick diagnosis flow is abstract rather than actionable. | 2 / 3 |
Workflow Clarity | The quick diagnosis flow provides a sequence but lacks validation checkpoints and feedback loops. There's no explicit 'if this fails, do that' error recovery guidance. The routing section helps with triage but the actual diagnostic workflow is shallow — it mostly defers to reference files without specifying when to escalate or what constitutes resolution. | 2 / 3 |
Progressive Disclosure | Excellent structure with a clear overview, well-organized routing table mapping services to reference documents, and one-level-deep references that are clearly signaled. The service-to-reference mapping table is particularly well done for navigation. References section at the bottom provides clean links. | 3 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- microsoft/github-copilot-for-azure
- Commit
915f809
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.