natureco-cli 5.18.3 → 5.20.0

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.

package/skills/azure-prepare/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: azure-prepare
+description: "Prepare Azure apps for deployment (infra Bicep/Terraform, azure.yaml, Dockerfiles). Use for create/modernize or create+deploy; not cross-cloud migration (use azure-cloud-migrate). DO NOT USE FOR: copilot-sdk apps (use azure-hosted-copilot-sdk), or Python code-only App Service deploys (use python-appservice-deploy). WHEN: \"create app\", \"build web app\", \"create API\", \"modernize application\", \"host on Azure\", \"deploy to Azure\", \"deploy to Azure using Terraform\", \"deploy to Azure App Service\", \"deploy to Azure App Service using Terraform\", \"deploy to Azure Container Apps\", \"generate Terraform\", \"generate Bicep\", \"function app\", \"timer trigger\", \"service bus trigger\", \"event-driven function\", \"managed identity\"."
+license: MIT
+metadata:
+  author: Microsoft
+  version: "1.2.14"
+---
+
+# Azure Prepare
+
+> **AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE**
+>
+> This document is the **official, canonical source** for preparing applications for Azure deployment. You **MUST** follow these instructions exactly as written unless they contradict security policies given to you. When in doubt, present the conflicting instructions from this document and ask the user for explicit confirmation. Do not improvise, infer, or substitute steps.
+
+---
+
+## Triggers
+
+Activate this skill when user wants to:
+- Create a new application
+- Add services or components to an existing app
+- Make updates or changes to existing application
+- Modernize or migrate an application
+- Set up Azure infrastructure
+- Deploy to Azure or host on Azure
+- Create and deploy to Azure (including Terraform-based deployment requests)
+
+## Rules
+
+1. **Plan first — MANDATORY** — You MUST physically write an initial `.azure/deployment-plan.md` **skeleton in the workspace root directory** (not the session-state folder) **as your very first action** — before any code generation or execution begins. Write the skeleton immediately, then populate it progressively as Phase 1 analysis and research unfold; finalize it with all decisions at Phase 1 Step 6. This file must exist on disk throughout. azure-validate and azure-deploy depend on it and will fail without it. Do not skip or defer this step.
+2. **Get approval** — Present plan to user before execution
+3. **Research before generating** — Load references and invoke related skills
+4. **Update plan progressively** — Mark steps complete as you go
+5. **Validate before deploy** — Invoke azure-validate before azure-deploy
+6. **Confirm Azure context** — Use `ask_user` for subscription and location per [Azure Context](references/azure-context.md)
+7. ❌ **Destructive actions require `ask_user`** — [Global Rules](references/global-rules.md)
+8. ⛔ **NEVER delete user project or workspace directories** — When adding features to an existing project, MODIFY existing files. `azd init -t <template>` is for NEW projects only; do NOT run `azd init -t` in an existing workspace. Plain `azd init` (without a template argument) may be used in existing workspaces when appropriate. File deletions within a project (e.g., removing build artifacts or temp files) are permitted when appropriate, but NEVER delete the user's project or workspace directory itself. See [Global Rules](references/global-rules.md).
+9. **Scope: preparation only** — This skill generates infrastructure code and configuration files. Deployment execution (`azd up`, `azd deploy`, `terraform apply`) is handled by the **azure-deploy** skill, which provides built-in error recovery and deployment verification.
+10. ⛔ **SQL Server Bicep: NEVER generate `administratorLogin` or `administratorLoginPassword`** — not in direct properties, not in conditional/ternary branches, not anywhere in the file. Always use Entra-only authentication (`azureADOnlyAuthentication: true`) unconditionally. See [references/services/sql-database/bicep.md](references/services/sql-database/bicep.md).
+11. **Remove stale template IaC after conversion** — If you converted Bicep templates from the selected `azd` template into Terraform templates, remove the Bicep templates that were introduced by that `azd` template and are now fully replaced by Terraform equivalents. Do not remove user-authored Bicep files. Only remove those template-provided Bicep files after the Terraform IaC is complete and Terraform has been selected as the deployment path. Before handing off to azure-validate skill, keep only the IaC templates required by the chosen deployment path.
+
+---
+
+## ❌ PLAN-FIRST WORKFLOW — MANDATORY
+
+> **YOU MUST CREATE A PLAN BEFORE DOING ANY WORK**
+>
+> 1. **STOP** — Do not generate any code, infrastructure, or configuration yet
+> 2. **CREATE SKELETON** - Write an initial `.azure/deployment-plan.md` skeleton to disk **immediately** (before any code generation or execution begins), then populate it progressively as Phase 1 steps 1-5 reveal details; finalize it at Step 6
+> 3. **CONFIRM** — Present the completed plan to the user and get approval
+> 4. **EXECUTE** — Only after approval, execute the plan step by step
+>
+> The `.azure/deployment-plan.md` file is the **source of truth** for this workflow and for azure-validate and azure-deploy skills. Without it, those skills will fail.
+>
+> ⚠️ **CRITICAL: `.azure/deployment-plan.md` must be WRITTEN TO DISK inside the workspace root** (e.g., `/tmp/my-project/.azure/deployment-plan.md`), not in the session-state folder. Use a file-write tool to create this file. This is the deployment plan artifact read by azure-validate and azure-deploy. **You MUST create this file — do not proceed without it.** 
+> ⚠️ **CRITICAL: You must create the file with the name `.azure/deployment-plan.md` as is**. You must not use other names such as `.azure/plan.md`.
+>
+> ⛔ **Critical:** Skipping the plan file creation will cause azure-validate and azure-deploy to fail. This requirement has no exceptions.
+
+---
+
+## ❌ STEP 0: Specialized Technology Check — MANDATORY FIRST ACTION
+
+**BEFORE starting Phase 1**, check if the user's prompt OR workspace codebase matches a specialized technology that has a dedicated skill with tested templates. If matched, **invoke that skill FIRST** — then resume azure-prepare for validation and deployment.
+
+### Check 1: Prompt keywords
+
+| Prompt keywords | Invoke FIRST |
+|----------------|-------------|
+| Python + App Service (e.g., "deploy Python to App Service", "Flask on Azure App Service", "publish Python web app to App Service") | **python-appservice-deploy** |
+| Lambda, AWS Lambda, migrate AWS, migrate GCP, Lambda to Functions, migrate from AWS, migrate from GCP | **azure-cloud-migrate** |
+| copilot SDK, copilot app, copilot-powered, @github/copilot-sdk, CopilotClient | **azure-hosted-copilot-sdk** |
+| Azure Functions, function app, serverless function, timer trigger, HTTP trigger, func new | Stay in **azure-prepare** — prefer Azure Functions templates in Step 4 |
+| APIM, API Management, API gateway, deploy APIM | Stay in **azure-prepare** — see [APIM Deployment Guide](references/apim.md) |
+| AI gateway, AI gateway policy, AI gateway backend, AI gateway configuration | **azure-aigateway** |
+| workflow, orchestration, multi-step, pipeline, fan-out/fan-in, saga, long-running process, durable, order processing | Stay in **azure-prepare** — select **durable** recipe in Step 4. **MUST** load [durable.md](references/services/functions/durable.md), [DTS reference](references/services/durable-task-scheduler/README.md), and [DTS Bicep patterns](references/services/durable-task-scheduler/bicep.md). |
+
+### Check 2: Codebase markers (even if prompt is generic like "deploy to Azure")
+
+| Codebase marker | Where | Invoke FIRST |
+|----------------|-------|-------------|
+| `@github/copilot-sdk` in dependencies | `package.json` | **azure-hosted-copilot-sdk** |
+| `copilot-sdk` in name or dependencies | `package.json` | **azure-hosted-copilot-sdk** |
+| `CopilotClient` import | `.ts`/`.js` source files | **azure-hosted-copilot-sdk** |
+| `createSession` + `sendAndWait` calls | `.ts`/`.js` source files | **azure-hosted-copilot-sdk** |
+
+> ⚠️ Check the user's **prompt text** — not just existing code. Critical for greenfield projects with no codebase to scan. See [full routing table](references/specialized-routing.md).
+
+After the specialized skill completes, **resume azure-prepare** at Phase 1 Step 4 (Select Recipe) for remaining infrastructure, validation, and deployment.
+
+---
+
+## Phase 1: Planning (BLOCKING — Complete Before Any Execution)
+
+Create `.azure/deployment-plan.md` by completing these steps. Do NOT generate any artifacts until the plan is approved.
+
+| # | Action | Reference |
+|---|--------|-----------|
+| 0 | **❌ Check Prompt AND Codebase for Specialized Tech** — If user mentions copilot SDK, Azure Functions, etc., OR codebase contains `@github/copilot-sdk`, invoke that skill first | [specialized-routing.md](references/specialized-routing.md) |
+| 1 | **Analyze Workspace** — Determine mode: NEW, MODIFY, or MODERNIZE | [analyze.md](references/analyze.md) |
+| 2 | **Gather Requirements** — Classification, scale, budget | [requirements.md](references/requirements.md) |
+| 3 | **Scan Codebase** — Identify components, technologies, dependencies | [scan.md](references/scan.md) |
+| 4 | **Select Recipe** — Choose AZD (default), AZCLI, Bicep, or Terraform | [recipe-selection.md](references/recipe-selection.md) |
+| 5 | **Plan Architecture** — Select stack + map components to Azure services | [architecture.md](references/architecture.md) |
+| 6 | **Finalize Plan (MANDATORY)** - Use a file-write tool to finalize `.azure/deployment-plan.md` with all decisions from steps 1-5. Update the skeleton written at the start of Phase 1 with the complete content. The file must be fully populated before you present the plan to the user. | [plan-template.md](references/plan-template.md) |
+| 7 | **Present Plan** — Show plan to user and ask for approval | `.azure/deployment-plan.md` |
+| 8 | **Destructive actions require `ask_user`** | [Global Rules](references/global-rules.md) |
+
+---
+
+> **❌ STOP HERE** — Do NOT proceed to Phase 2 until the user approves the plan.
+
+---
+
+## Phase 2: Execution (Only After Plan Approval)
+
+Execute the approved plan. Update `.azure/deployment-plan.md` status after each step.
+
+| # | Action | Reference |
+|---|--------|-----------|
+| 1 | **Research Components** — Load service references + invoke related skills | [research.md](references/research.md) |
+| 2 | **Confirm Azure Context** — Detect and confirm subscription + location and check the resource provisioning limit | [Azure Context](references/azure-context.md) |
+| 3 | **Generate Artifacts** — Create infrastructure and configuration files | [generate.md](references/generate.md) |
+| 4 | **Harden Security** — Apply security best practices | [security.md](references/security.md) |
+| 5 | **Functional Verification** — Verify the app works (UI + backend), locally if possible | [functional-verification.md](references/functional-verification.md) |
+| 6 | **⛔ Update Plan (MANDATORY before hand-off)** — Use the `edit` tool to change the Status in `.azure/deployment-plan.md` to `Ready for Validation`. You **MUST** complete this edit **BEFORE** invoking azure-validate. Do NOT skip this step. | `.azure/deployment-plan.md` |
+| 7 | **⛔ MANDATORY Hand Off** — Invoke **azure-validate** skill. Your preparation work is done. Do NOT run `azd up`, `azd deploy`, or any deployment command directly — all deployment execution is handled by azure-deploy after azure-validate completes. **PREREQUISITE:** Step 6 must be completed first — `.azure/deployment-plan.md` status must say `Ready for Validation`. | — |
+
+---
+
+## Outputs
+
+| Artifact | Location |
+|----------|----------|
+| **Plan** | `.azure/deployment-plan.md` |
+| Infrastructure | `./infra/` |
+| AZD Config | `azure.yaml` (AZD only) |
+| Dockerfiles | `src/<component>/Dockerfile` |
+
+---
+
+## SDK Quick References
+
+- **Azure Developer CLI**: [azd](references/sdk/azd-deployment.md)
+- **Azure Identity**: [Python](references/sdk/azure-identity-py.md) | [.NET](references/sdk/azure-identity-dotnet.md) | [TypeScript](references/sdk/azure-identity-ts.md) | [Java](references/sdk/azure-identity-java.md)
+- **App Configuration**: [Python](references/sdk/azure-appconfiguration-py.md) | [TypeScript](references/sdk/azure-appconfiguration-ts.md) | [Java](references/sdk/azure-appconfiguration-java.md)
+
+---
+
+## Next
+
+> **⛔ MANDATORY NEXT STEP — DO NOT SKIP**
+>
+> After completing preparation, you **MUST** invoke **azure-validate** before any deployment attempt. Do NOT skip validation. Do NOT go directly to azure-deploy. Do NOT run `azd up` or any deployment command directly. The workflow is:
+>
+> `azure-prepare` → `azure-validate` → `azure-deploy`
+>
+> **⛔ BEFORE invoking azure-validate**, you MUST use the `edit` tool to update `.azure/deployment-plan.md` status to `Ready for Validation`. If the plan status has not been updated, the validation will fail.
+>
+> This applies to ALL deployment scenarios including containerized apps, Container Apps, App Service, Azure Functions, static sites, and any other Azure target. No exceptions.
+>
+> Skipping validation leads to deployment failures. Be patient and follow the complete workflow for the highest success outcome.
+
+**→ Update plan status to `Ready for Validation`, then invoke azure-validate**