Lists multiple specific concrete actions: prepare Azure apps for deployment, infrastructure via Bicep/Terraform, azure.yaml, Dockerfiles, create/modernize apps, add authentication, add caching, and more. Very detailed about what it does.

Clearly answers both 'what' (prepare Azure apps for deployment with infra Bicep/Terraform, azure.yaml, Dockerfiles) and 'when' with an extensive explicit WHEN clause listing numerous trigger phrases. Also includes explicit exclusions (DO NOT USE FOR) which further clarifies when to use it.

Excellent coverage of natural user phrases including 'create app', 'build web app', 'deploy to Azure', 'generate Terraform', 'generate Bicep', 'function app', 'todo list with frontend and API', 'static portfolio website', and many more variations users would naturally say.

Explicitly distinguishes itself from related skills by name: 'not cross-cloud migration (use azure-cloud-migrate)' and 'DO NOT USE FOR: copilot-sdk apps (use azure-hosted-copilot-sdk)'. This clear boundary-setting with named alternatives makes it highly distinctive and reduces conflict risk.

The document is extremely verbose and repetitive. The same instructions are stated multiple times — the plan-first requirement is repeated at least 4 times with nearly identical wording, the mandatory hand-off to azure-validate is repeated 3+ times, and the deployment-plan.md file creation requirement is hammered in redundantly. Many warnings and rules restate what was already said, wasting significant token budget.

The skill provides a clear structured workflow with specific file paths, tool references, and step sequences, but almost all concrete guidance is deferred to reference files (analyze.md, requirements.md, scan.md, etc.) which are not provided. The skill itself contains no executable code, no command examples, and no concrete templates — it's essentially a routing document pointing elsewhere.

The multi-phase workflow is clearly sequenced with explicit blocking points (STOP before Phase 2), mandatory validation checkpoints (update plan status before hand-off, invoke azure-validate before azure-deploy), and a clear error recovery path. The Phase 1 → approval gate → Phase 2 → validation → deployment pipeline is well-defined with explicit prerequisites at each transition.

The skill references many external files (references/analyze.md, references/requirements.md, etc.) which is good progressive disclosure in principle, but since no bundle files are provided, we cannot verify these references exist. The main document itself is bloated with repeated warnings that could be consolidated, and the routing tables and rules sections contain substantial inline content that could be better organized.