natureco-cli 5.18.2 → 5.19.0

package/skills/azure-enterprise-infra-planner/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: azure-enterprise-infra-planner
+description: "Architect and provision enterprise Azure infrastructure from workload descriptions. For cloud architects and platform engineers planning networking, identity, security, compliance, and multi-resource topologies with WAF alignment. Generates Bicep or Terraform directly (no azd). WHEN: 'plan Azure infrastructure', 'architect Azure landing zone', 'design hub-spoke network', 'plan multi-region DR topology', 'set up VNets firewalls and private endpoints', 'subscription-scope Bicep deployment', 'Azure Backup for VM workloads'. PREFER azure-prepare FOR app-centric workflows."
+license: MIT
+metadata:
+  author: Microsoft
+  version: "1.2.3"
+---
+
+# Azure Enterprise Infra Planner
+
+## When to Use This Skill
+
+Activate this skill when user wants to:
+- Plan enterprise Azure infrastructure from a workload or architecture description
+- Architect a landing zone, hub-spoke network, or multi-region topology
+- Design networking infrastructure: VNets, subnets, firewalls, private endpoints, VPN gateways
+- Plan identity, RBAC, and compliance-driven infrastructure
+- Generate Bicep or Terraform for subscription-scope or multi-resource-group deployments
+- Plan disaster recovery, failover, or cross-region high-availability topologies
+
+## Quick Reference
+
+| Property | Details |
+|---|---|
+| MCP tools | `insights_get`, `get_azure_bestpractices_get`, `wellarchitectedframework_serviceguide_get`, `microsoft_docs_fetch`, `microsoft_docs_search`, `bicepschema_get` |
+| CLI commands | `az deployment group create`, `az bicep build`, `az resource list`, `terraform init`, `terraform plan`, `terraform validate`, `terraform apply` |
+| Output schema | [schema.md](references/schema.md) |
+| Key references | [workflow.md](references/workflow.md), [waf-checklist.md](references/waf-checklist.md), [resources/](references/resources/README.md), [constraints/](references/constraints/README.md) |
+
+## Workflow (Start Here)
+
+Follow the step-by-step instructions in [workflow.md](references/workflow.md) to execute the 7 phases of infrastructure planning and provisioning.
+
+## MCP Tools
+
+| Tool | Purpose |
+|------|---------|
+| `insights_get` | Retrieve insights about the user's existing Azure environment to guide planning decisions |
+| `get_azure_bestpractices_get` | Azure best practices for code generation, operations, and deployment |
+| `wellarchitectedframework_serviceguide_get` | WAF service guide for a specific Azure service |
+| `microsoft_docs_search` | Search Microsoft Learn for relevant documentation chunks |
+| `microsoft_docs_fetch` | Fetch full content of a Microsoft Learn page by URL |
+| `bicepschema_get` | Bicep schema definition for any Azure resource type (latest API version) |
+
+## Error Handling
+
+| Error | Cause | Fix |
+|---|---|---|
+| MCP tool error or not available | Tool call timeout, connection error, or tool doesn't exist | Retry once; fall back to reference files and notify user if unresolved |
+| Plan approval missing | `meta.status` is not `approved` | Stop and prompt user for approval before IaC generation or deployment |
+| IaC validation failure | `az bicep build` or `terraform validate` returns errors | Fix the generated code and re-validate; notify user if unresolved |
+| Pairing constraint violation | Incompatible SKU or resource combination | Fix in plan before proceeding to IaC generation |
+| Infra plan or IaC files not found | Files written to wrong location or not created | Verify files exist at `<project-root>/.azure/` and `<project-root>/infra/`; if missing, re-create the files by following [workflow.md](references/workflow.md) exactly |

package/skills/azure-hosted-copilot-sdk/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: azure-hosted-copilot-sdk
+description: "Build, deploy, and modify GitHub Copilot SDK apps on Azure. MANDATORY when codebase contains @github/copilot-sdk or CopilotClient in package.json. PREFER OVER azure-prepare when copilot-sdk markers detected. WHEN: copilot SDK, @github/copilot-sdk, copilot-powered app, build copilot app, prepare copilot app, add feature to copilot app, modify copilot app, BYOM, bring your own model, CopilotClient, createSession, sendAndWait, azd init copilot. DO NOT USE FOR: deploying already-prepared copilot-sdk apps (use azure-deploy), general web apps without copilot SDK (use azure-prepare), Copilot Extensions, Foundry agents (use microsoft-foundry)."
+license: MIT
+metadata:
+  author: Microsoft
+  version: "1.1.3"
+---
+
+# GitHub Copilot SDK on Azure
+
+## Codebase Detection — MANDATORY FIRST CHECK
+
+> ⚠️ **CRITICAL: This check MUST run before ANY other skill (azure-prepare, azure-deploy, etc.) when an existing codebase is present.**
+
+### Detection procedure (run IMMEDIATELY for any build/modify/add-feature/prepare prompt):
+
+1. Read `package.json` in the workspace root (and any `*/package.json` one level deep)
+2. Check if `@github/copilot-sdk` or `copilot-sdk` appears in `name`, `dependencies`, or `devDependencies`
+3. If NOT found in package.json, scan `.ts` and `.js` files for `CopilotClient` or `createSession`
+4. **If ANY marker is found → invoke this skill as the entry point. Do not route directly to azure-prepare or azure-deploy — this skill orchestrates them as sub-skills.**
+
+| Marker | Where to check |
+|--------|---------------|
+| `@github/copilot-sdk` | `package.json` dependencies or devDependencies |
+| `copilot-sdk` | `package.json` name or dependencies |
+| `CopilotClient` | Source files (`.ts`, `.js`) |
+| `createSession` + `sendAndWait` | Source files (`.ts`, `.js`) |
+
+### Generic prompts that MUST trigger this skill when markers are detected:
+
+| Prompt pattern (no "copilot" keyword) | Why this skill |
+|---------------------------------------|---------------|
+| "Build this app" / "Prepare this app for Azure" | Codebase contains `@github/copilot-sdk` - needs SDK-aware scaffolding |
+| "Add a new feature to this app" | Requires SDK-aware implementation patterns |
+| "Update this app" / "Modify this app" | Must preserve SDK integration patterns |
+
+> ⚠️ **Warning:** ANY build, modify, add-feature, or prepare prompt targeting an existing codebase MUST route to this skill when codebase contains `@github/copilot-sdk`, even if the prompt does not mention "copilot". This skill then orchestrates azure-prepare and azure-deploy as sub-skills.
+
+> ⚠️ **Yield to azure-deploy:** When the codebase already has `.azure/deployment-plan.md` and the user wants to **deploy** (not modify or add features), route to **azure-deploy** instead. This skill handles preparation; azure-deploy handles execution.
+
+## Step 1: Route
+
+| User wants | Action |
+|------------|--------|
+| Build new (empty project) | Step 2A (scaffold) |
+| Add new SDK service to existing repo | Step 2B (scaffold alongside) |
+| Deploy existing SDK app to Azure | Step 2C (add infra to existing SDK app) |
+| Modify/add features to existing SDK app | Use codebase context + SDK references to implement |
+| Add SDK to existing app code | [Integrate SDK](references/existing-project-integration.md) |
+| Use Azure/own model | Step 3 (BYOM config) |
+
+## Step 2A: Scaffold New (Greenfield)
+
+`azd init --template azure-samples/copilot-sdk-service`
+
+Template includes API (Express/TS) + Web UI (React/Vite) + infra (Bicep) + Dockerfiles + token scripts — do NOT recreate. See [SDK ref](references/copilot-sdk.md).
+
+## Step 2B: Add SDK Service to Existing Repo
+
+User has existing code and wants a new Copilot SDK service alongside it. Scaffold template to a temp dir, copy the API service + infra into the user's repo, adapt `azure.yaml` to include both existing and new services. See [deploy existing ref](references/deploy-existing.md).
+
+## Step 2C: Deploy Existing SDK App
+
+User already has a working Copilot SDK app and needs Azure infra. See [deploy existing ref](references/deploy-existing.md).
+
+## Step 3: Model Configuration
+
+Three model paths (layers on top of 2A/2B):
+
+| Path | Config |
+|------|--------|
+| **GitHub default** | No `model` param — SDK picks default |
+| **GitHub specific** | `model: "<name>"` — use `listModels()` to discover |
+| **Azure BYOM** | `model` + `provider` with `bearerToken` via `DefaultAzureCredential` |
+
+> ⚠️ **BYOM Auth — MANDATORY**: Azure BYOM configurations MUST use `DefaultAzureCredential` (local dev) or `ManagedIdentityCredential` (production) to obtain a `bearerToken`. The ONLY supported auth pattern is `bearerToken` in the provider config. See [auth-best-practices.md](references/auth-best-practices.md) for the credential pattern and [model config ref](references/azure-model-config.md) for the full BYOM code example.
+
+See [model config ref](references/azure-model-config.md).
+
+## Step 4: Deploy
+
+Invoke **azure-prepare** (skip its Step 0 routing — scaffolding is done) → **azure-validate** → **azure-deploy** in order.
+
+## Rules
+
+- Read `AGENTS.md` in user's repo before changes
+- Docker required (`docker info`)
+- BYOM auth: ONLY `bearerToken` via `DefaultAzureCredential` or `ManagedIdentityCredential` — no other auth pattern is supported

package/skills/azure-kubernetes/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: azure-kubernetes
+license: MIT
+metadata:
+  author: Microsoft
+  version: "1.1.4"
+description: "Plan, create, and configure production-ready Azure Kubernetes Service (AKS) clusters. Covers Day-0 checklist, SKU selection (Automatic vs Standard), networking options (private API server, Azure CNI Overlay, egress configuration), security, and operations (autoscaling, upgrade strategy, cost analysis). WHEN: create AKS environment, provision AKS, enable AKS observability, design AKS networking, choose AKS SKU, secure AKS, optimize AKS, AKS spot nodes, AKS cluster-autoscaler, rightsize AKS pod, pod rightsizing, over-provisioned AKS pod, pod resource requests and limits, Vertical Pod Autoscaler, VPA recommendations."
+---
+
+# Azure Kubernetes Service
+
+> **AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE**
+>
+> This skill produces a **recommended AKS cluster configuration** based on user requirements, distinguishing **Day-0 decisions** (networking, API server — hard to change later) from **Day-1 features** (can enable post-creation). See [CLI reference](./references/cli-reference.md) for commands.
+
+## Quick Reference
+| Property | Value |
+|----------|-------|
+| Best for | AKS cluster planning and Day-0 decisions |
+| MCP Tools | `mcp_azure_mcp_aks` |
+| CLI | `az aks create`, `az aks show`, `kubectl get`, `kubectl describe` |
+| Related skills | azure-diagnostics (troubleshooting AKS), azure-validate (readiness checks), azure-kubernetes-automatic-readiness (migrate existing cluster to AKS Automatic) |
+
+## When to Use This Skill
+Activate this skill when user wants to:
+- Create a new AKS cluster
+- Plan AKS cluster configuration for production workloads
+- Design AKS networking (API server access, pod IP model, egress)
+- Set up AKS identity and secrets management
+- Configure AKS governance (Azure Policy, Deployment Safeguards)
+- Enable AKS observability (Container Insights, Managed Prometheus, Grafana)
+- Define AKS upgrade and patching strategy
+- Understand AKS Automatic vs Standard SKU differences
+- Get a Day-0 checklist for AKS cluster setup and configuration
+
+## Rules
+1. Start with the user's requirements for provisioning compute, networking, security, and other settings.
+2. Use the `azure` MCP server and select `mcp_azure_mcp_aks` first to discover the exact AKS-specific MCP tools surfaced by the client. Choose the smallest discovered AKS tool that fits the task, and fall back to Azure CLI (`az aks`) only when the needed functionality is not exposed through the AKS MCP surface.
+3. Determine if AKS Automatic or Standard SKU is more appropriate based on the user's need for control vs convenience. Default to AKS Automatic unless specific customizations are required.
+4. Document decisions and rationale for cluster configuration choices, especially for Day-0 decisions that are hard to change later (networking, API server access).
+
+
+## Required Inputs (Ask only what’s needed)
+If the user is unsure, use safe defaults.
+- AKS environment type: dev/test or production
+- Region(s), availability zones, preferred node VM sizes
+- Expected scale (node/cluster count, workload size)
+- Networking requirements (API server access, pod IP model, ingress/egress control)
+- Security and identity requirements, including image registry
+- Upgrade and observability preferences
+- Cost constraints
+
+## Workflow
+
+### 1. Cluster Type
+- **AKS Automatic** (default): Best for most production workloads, provides a curated experience with pre-configured best practices for security, reliability, and performance. Use unless you have specific custom requirements for networking, autoscaling, or node pool configurations not supported by Node Auto-Provisioning (NAP).
+- **AKS Standard**: Use if you need full control over environment configuration, which requires additional overhead to set up and manage.
+
+### 2. Networking (Pod IP, Egress, Ingress, Dataplane)
+
+**Pod IP Model** (Key Day-0 decision):
+- **Azure CNI Overlay** (recommended): pod IPs from private overlay range, not VNet-routable, scales to large environments and good for most workloads
+- **Azure CNI (VNet-routable)**: pod IPs directly from VNet (pod subnet or node subnet), use when pods must be directly addressable from VNet or on-prem
+  - Docs: https://learn.microsoft.com/azure/aks/azure-cni-overlay
+
+**Dataplane & Network Policy**:
+- **Azure CNI powered by Cilium** (recommended): eBPF-based for high-performance packet processing, network policies, and observability
+
+**Egress**:
+- **Static Egress Gateway** for stable, predictable outbound IPs
+- For restricted egress: UDR + Azure Firewall or NVA
+
+**Ingress**:
+- **App Routing addon with Gateway API** — recommended default for HTTP/HTTPS workloads
+- **Istio service mesh with Gateway API** - for advanced traffic management, mTLS, canary releases
+- **Application Gateway for Containers** — for L7 load balancing with WAF integration
+
+**DNS**:
+- Enable **LocalDNS** on all node pools for reliable, performant DNS resolution
+
+### 3. Security
+- Use **Microsoft Entra ID** everywhere (control plane, Workload Identity for pods, node access). Avoid static credentials.
+- Azure Key Vault via **Secrets Store CSI Driver** for secrets
+- Enable **Azure Policy** + **Deployment Safeguards**
+- Enable **Encryption at rest** for etcd/API server; **in-transit** for node-to-node
+- Allow only signed, policy-approved images (Azure Policy + Ratify), prefer **Azure Container Registry**
+- **Isolation**: Use namespaces, network policies, scoped logging
+
+### 4. Observability
+- Use Managed Prometheus and Container Insights with Grafana for AKS observability (logs + metrics).
+- Enable Diagnostic Settings to collect control plane logs and audit logs in a Log Analytics workspace for security monitoring and troubleshooting.
+- For other monitoring and troubleshooting tools, use features like the Agentic CLI for AKS, Application Insights, Resource Health Center, AppLens detectors, and Azure Advisors.
+
+### 5. Upgrades & Patching
+- Configure **Maintenance Windows** for controlled upgrade timing
+- Enable **auto-upgrades** for control plane and node OS to stay up-to-date with security patches and Kubernetes versions
+- Consider **LTS versions** for enterprise stability (2-year support) by upgrading your AKS environment to the Premium tier
+- **Fleet upgrades**: Use **AKS Fleet Manager** for staged rollout across test to production environments
+
+### 6. Performance
+- Use **Ephemeral OS disks** (`--node-osdisk-type Ephemeral`) for faster node startup
+- Select **Azure Linux** as node OS (smaller footprint, faster boot)
+- Enable **KEDA** for event-driven autoscaling beyond HPA
+
+### 7. Node Pools & Compute
+- **Dedicated system node pool**: At least 2 nodes, tainted for system workloads only (`CriticalAddonsOnly`)
+- Enable **Node Auto Provisioning (NAP)** on all pools for cost savings and responsive scaling
+- Use **latest generation SKUs (v5/v6)** for host-level optimizations
+- **Avoid B-series VMs** — burstable SKUs cause performance/reliability issues
+- Use SKUs with **at least 4 vCPUs** for production workloads
+- Set **topology spread constraints** to distribute pods across hosts/zones per SLO
+
+### 8. Reliability
+- Deploy across **3 Availability Zones** (`--zones 1 2 3`)
+- Use **Standard tier** for zone-redundant control plane + 99.95% SLA for API server availability
+- Enable **Microsoft Defender for Containers** for runtime protection
+- Configure **PodDisruptionBudgets** for all production workloads
+- Use **topology spread constraints** to ensure pod distribution across failure domains
+
+### 9. Cost Controls
+- Use **Spot node pools** for batch/interruptible workloads (up to 90% savings)
+- **Stop/Start** dev/test clusters: `az aks stop/start`
+- Consider **Reserved Instances** or **Savings Plans** for steady-state workloads
+
+**Deep-dive scenarios** — load only the relevant reference file:
+
+| Scenario | Trigger Keywords | Reference |
+|----------|-----------------|-----------|
+| Pod Rightsizing | over-provisioned pods, CPU requests, memory requests, rightsize workloads | [azure-aks-rightsizing.md](./references/azure-aks-rightsizing.md) |
+| VPA Setup | vertical pod autoscaler, VPA recommendations, VPA enable | [azure-aks-vpa.md](./references/azure-aks-vpa.md) |
+| Cluster Autoscaler | idle nodes, CAS off, enable autoscaler, scale-down profile, node utilization | [azure-aks-autoscaler.md](./references/azure-aks-autoscaler.md) |
+| Spot Node Pools | Spot VMs, Spot nodes, batch workloads, cheaper nodes | [azure-aks-spot.md](./references/azure-aks-spot.md) |
+
+> **Disambiguation:** If a prompt matches multiple rows (e.g., "cheaper nodes" could suggest both Spot and autoscaler), prefer the most specific match. If ambiguous, ask the user to clarify their intent before loading a reference file.
+
+## Guardrails / Safety
+- Do not request or output secrets (tokens, keys).
+- Do not ask the user to paste subscription IDs. Discover subscription and resource scope via MCP tools (e.g., list subscriptions, list resource groups) or `az account show` / `az account list` so the agent can resolve context without exposing identifiers.
+- If requirements are ambiguous for day-0 critical decisions, ask the user clarifying questions. For day-1 enabled features, propose 2–3 safe options with tradeoffs and choose a conservative default.
+- Do not promise zero downtime; advise workload safeguards (PDBs, probes, replicas) and staged upgrades along with best practices for reliability and performance.
+
+## MCP Tools
+| Tool | Purpose | Key Parameters |
+|------|---------|----------------|
+| `mcp_azure_mcp_aks` | AKS MCP entry point used to discover the exact AKS-specific tools exposed by the client | Discover the callable AKS tool first, then use that tool's parameters |
+
+## Error Handling
+| Error / Symptom | Likely Cause | Remediation |
+|-----------------|--------------|-------------|
+| MCP tool call fails or times out | Invalid credentials, subscription, or AKS context | Verify `az login`, confirm the active subscription context with `az account show`, and check the target resource group without echoing subscription identifiers back to the user |
+| Quota exceeded | Regional vCPU or resource limits | Request quota increase or select different region/VM SKU |
+| Networking conflict (IP exhaustion) | Pod subnet too small for overlay/CNI | Re-plan IP ranges; may require cluster recreation (Day-0) |
+| Workload Identity not working | Missing OIDC issuer or federated credential | Enable `--enable-oidc-issuer --enable-workload-identity`, configure federated identity |

package/skills/azure-kusto/SKILL.md

@@ -0,0 +1,231 @@
+---
+name: azure-kusto
+description: "Query and analyze data in Azure Data Explorer (Kusto/ADX) using KQL for log analytics, telemetry, and time series analysis. WHEN: KQL queries, Kusto database queries, Azure Data Explorer, ADX clusters, log analytics, time series data, IoT telemetry, anomaly detection."
+license: MIT
+metadata:
+  author: Microsoft
+  version: "1.1.1"
+---
+
+# Azure Data Explorer (Kusto) Query & Analytics
+
+Execute KQL queries and manage Azure Data Explorer resources for fast, scalable big data analytics on log, telemetry, and time series data.
+
+## Skill Activation Triggers
+
+**Use this skill immediately when the user asks to:**
+- "Query my Kusto database for [data pattern]"
+- "Show me events in the last hour from Azure Data Explorer"
+- "Analyze logs in my ADX cluster"
+- "Run a KQL query on [database]"
+- "What tables are in my Kusto database?"
+- "Show me the schema for [table]"
+- "List my Azure Data Explorer clusters"
+- "Aggregate telemetry data by [dimension]"
+- "Create a time series chart from my logs"
+
+**Key Indicators:**
+- Mentions "Kusto", "Azure Data Explorer", "ADX", or "KQL"
+- Log analytics or telemetry analysis requests
+- Time series data exploration
+- IoT data analysis queries
+- SIEM or security analytics tasks
+- Requests for data aggregation on large datasets
+- Performance monitoring or APM queries
+
+## Overview
+
+This skill enables querying and managing Azure Data Explorer (Kusto), a fast and highly scalable data exploration service optimized for log and telemetry data. Azure Data Explorer provides sub-second query performance on billions of records using the Kusto Query Language (KQL).
+
+Key capabilities:
+- **Query Execution**: Run KQL queries against massive datasets
+- **Schema Exploration**: Discover tables, columns, and data types
+- **Resource Management**: List clusters and databases
+- **Analytics**: Aggregations, time series, anomaly detection, machine learning
+
+## Core Workflow
+
+1. **Discover Resources**: List available clusters and databases in subscription
+2. **Explore Schema**: Retrieve table structures to understand data model
+3. **Query Data**: Execute KQL queries for analysis, filtering, aggregation
+4. **Analyze Results**: Process query output for insights and reporting
+
+## Query Patterns
+
+### Pattern 1: Basic Data Retrieval
+Fetch recent records from a table with simple filtering.
+
+**Example KQL**:
+```kql
+Events
+| where Timestamp > ago(1h)
+| take 100
+```
+
+**Use for**: Quick data inspection, recent event retrieval
+
+### Pattern 2: Aggregation Analysis
+Summarize data by dimensions for insights and reporting.
+
+**Example KQL**:
+```kql
+Events
+| summarize count() by EventType, bin(Timestamp, 1h)
+| order by count_ desc
+```
+
+**Use for**: Event counting, distribution analysis, top-N queries
+
+### Pattern 3: Time Series Analytics
+Analyze data over time windows for trends and patterns.
+
+**Example KQL**:
+```kql
+Telemetry
+| where Timestamp > ago(24h)
+| summarize avg(ResponseTime), percentiles(ResponseTime, 50, 95, 99) by bin(Timestamp, 5m)
+| render timechart
+```
+
+**Use for**: Performance monitoring, trend analysis, anomaly detection
+
+### Pattern 4: Join and Correlation
+Combine multiple tables for cross-dataset analysis.
+
+**Example KQL**:
+```kql
+Events
+| where EventType == "Error"
+| join kind=inner (
+    Logs
+    | where Severity == "Critical"
+) on CorrelationId
+| project Timestamp, EventType, LogMessage, Severity
+```
+
+**Use for**: Root cause analysis, correlated event tracking
+
+### Pattern 5: Schema Discovery
+Explore table structure before querying.
+
+**Tools**: `kusto_table_schema_get`
+
+**Use for**: Understanding data model, query planning
+
+## Key Data Fields
+
+When executing queries, common field patterns:
+- **Timestamp**: Time of event (datetime) - use `ago()`, `between()`, `bin()` for time filtering
+- **EventType/Category**: Classification field for grouping
+- **CorrelationId/SessionId**: For tracing related events
+- **Severity/Level**: For filtering by importance
+- **Dimensions**: Custom properties for grouping and filtering
+
+## Result Format
+
+Query results include:
+- **Columns**: Field names and data types
+- **Rows**: Data records matching query
+- **Statistics**: Row count, execution time, resource utilization
+- **Visualization**: Chart rendering hints (timechart, barchart, etc.)
+
+## KQL Best Practices
+
+**🟢 Performance Optimized:**
+- Filter early: Use `where` before joins and aggregations
+- Limit result size: Use `take` or `limit` to reduce data transfer
+- Time filters: Always filter by time range for time series data
+- Indexed columns: Filter on indexed columns first
+
+**🔵 Query Patterns:**
+- Use `summarize` for aggregations instead of `count()` alone
+- Use `bin()` for time bucketing in time series
+- Use `project` to select only needed columns
+- Use `extend` to add calculated fields
+
+**🟡 Common Functions:**
+- `ago(timespan)`: Relative time (ago(1h), ago(7d))
+- `between(start .. end)`: Range filtering
+- `startswith()`, `contains()`, `matches regex`: String filtering
+- `parse`, `extract`: Extract values from strings
+- `percentiles()`, `avg()`, `sum()`, `max()`, `min()`: Aggregations
+
+## Best Practices
+
+- Always include time range filters to optimize query performance
+- Use `take` or `limit` for exploratory queries to avoid large result sets
+- Leverage `summarize` for aggregations instead of client-side processing
+- Store frequently-used queries as functions in the database
+- Use materialized views for repeated aggregations
+- Monitor query performance and resource consumption
+- Apply data retention policies to manage storage costs
+- Use streaming ingestion for real-time analytics (< 1 second latency)
+- Integrate with Azure Monitor for operational insights
+
+## MCP Tools Used
+
+| Tool | Purpose |
+|------|---------|
+| `kusto_cluster_list` | List all Azure Data Explorer clusters in a subscription |
+| `kusto_database_list` | List all databases in a specific Kusto cluster |
+| `kusto_query` | Execute KQL queries against a Kusto database |
+| `kusto_table_schema_get` | Retrieve schema information for a specific table |
+
+**Required Parameters**:
+- `subscription`: Azure subscription ID or display name
+- `cluster`: Kusto cluster name (e.g., "mycluster")
+- `database`: Database name
+- `query`: KQL query string (for query operations)
+- `table`: Table name (for schema operations)
+
+**Optional Parameters**:
+- `resource-group`: Resource group name (for listing operations)
+- `tenant`: Azure AD tenant ID
+
+## Fallback Strategy: Azure CLI Commands
+
+If Azure MCP Kusto tools fail, timeout, or are unavailable, use Azure CLI commands as fallback.
+
+### CLI Command Reference
+
+| Operation | Azure CLI Command |
+|-----------|-------------------|
+| List clusters | `az kusto cluster list --resource-group <rg-name>` |
+| List databases | `az kusto database list --cluster-name <cluster> --resource-group <rg-name>` |
+| Show cluster | `az kusto cluster show --name <cluster> --resource-group <rg-name>` |
+| Show database | `az kusto database show --cluster-name <cluster> --database-name <db> --resource-group <rg-name>` |
+
+### KQL Query via Azure CLI
+
+For queries, use the Kusto REST API or direct cluster URL:
+```bash
+az rest --method post \
+  --url "https://<cluster>.<region>.kusto.windows.net/v1/rest/query" \
+  --body "{ \"db\": \"<database>\", \"csl\": \"<kql-query>\" }"
+```
+
+### When to Fallback
+
+Switch to Azure CLI when:
+- MCP tool returns timeout error (queries > 60 seconds)
+- MCP tool returns "service unavailable" or connection errors
+- Authentication failures with MCP tools
+- Empty response when database is known to have data
+
+## Common Issues
+
+- **Access Denied**: Verify database permissions (Viewer role minimum for queries)
+- **Query Timeout**: Optimize query with time filters, reduce result set, or increase timeout
+- **Syntax Error**: Validate KQL syntax - common issues: missing pipes, incorrect operators
+- **Empty Results**: Check time range filters (may be too restrictive), verify table name
+- **Cluster Not Found**: Check cluster name format (exclude ".kusto.windows.net" suffix)
+- **High CPU Usage**: Query too broad - add filters, reduce time range, limit aggregations
+- **Ingestion Lag**: Streaming data may have 1-30 second delay depending on ingestion method
+
+## Use Cases
+
+- **Log Analytics**: Application logs, system logs, audit logs
+- **IoT Analytics**: Sensor data, device telemetry, real-time monitoring
+- **Security Analytics**: SIEM data, threat detection, security event correlation
+- **APM**: Application performance metrics, user behavior, error tracking
+- **Business Intelligence**: Clickstream analysis, user analytics, operational KPIs

package/skills/azure-messaging/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: azure-messaging
+description: "Troubleshoot and resolve issues with Azure Messaging SDKs for Event Hubs and Service Bus. Covers connection failures, authentication errors, message processing issues, and SDK configuration problems. WHEN: event hub SDK error, service bus SDK issue, messaging connection failure, AMQP error, event processor host issue, message lock lost, message lock expired, lock renewal, lock renewal batch, send timeout, receiver disconnected, SDK troubleshooting, azure messaging SDK, event hub consumer, service bus queue issue, topic subscription error, enable logging event hub, service bus logging, eventhub python, servicebus java, eventhub javascript, servicebus dotnet, event hub checkpoint, event hub not receiving messages, service bus dead letter, batch processing lock, session lock expired, idle timeout, connection inactive, link detach, slow reconnect, session error, duplicate events, offset reset, receive batch."
+license: MIT
+metadata:
+  author: Microsoft
+  version: "1.1.2"
+---
+
+# Azure Messaging SDK Troubleshooting
+
+## Quick Reference
+
+| Property | Value |
+|----------|-------|
+| **Services** | Azure Event Hubs, Azure Service Bus |
+| **MCP Tools** | `mcp_azure_mcp_eventhubs`, `mcp_azure_mcp_servicebus` |
+| **Best For** | Diagnosing SDK connection, auth, and message processing issues |
+
+## When to Use This Skill
+
+- SDK connection failures, auth errors, or AMQP link errors
+- Idle timeout, connection inactivity, or slow reconnection after disconnect
+- AMQP link detach or detach-forced errors
+- Message lock lost, message lock expired, lock renewal failures, or batch lock timeouts
+- Session lock lost, session lock expired, or session receiver errors
+- Event processor or message handler stops processing
+- Duplicate events or checkpoint offset resets
+- SDK configuration questions (retry, prefetch, batch size, receive batch behavior)
+
+## MCP Tools
+
+| Tool | Command | Use |
+|------|---------|-----|
+| `mcp_azure_mcp_eventhubs` | Namespace/hub ops | List namespaces, hubs, consumer groups |
+| `mcp_azure_mcp_servicebus` | Queue/topic ops | List namespaces, queues, topics, subscriptions |
+| `mcp_azure_mcp_monitor` | `logs_query` | Query diagnostic logs with KQL |
+| `mcp_azure_mcp_resourcehealth` | `get` | Check service health status |
+| `mcp_azure_mcp_documentation` | Doc search | Search Microsoft Learn for troubleshooting docs |
+
+## Diagnosis Workflow
+
+1. **Identify the SDK and version** — Check the prompt for SDK and version clues; if not stated, proceed with diagnosis and ask later if needed
+2. **Check resource health** — Use `mcp_azure_mcp_resourcehealth` to verify the namespace is healthy
+3. **Review the error message** — Match against language-specific troubleshooting guide
+4. **Look up documentation** — Use `mcp_azure_mcp_documentation` to search Microsoft Learn for the error or topic
+5. **Check configuration** — Verify connection string, entity name, consumer group
+6. **Recommend fix** — Apply remediation, citing documentation found
+
+
+## Troubleshooting Guides
+
+Connectivity, SDK, and auth troubleshooting guides are located in the azure-diagnostics skill under `troubleshooting/messaging/`.
+
+## References
+
+- Use `mcp_azure_mcp_documentation` to search Microsoft Learn for latest guidance.