---

name: azure-logic-apps-standard-cli description: 'Create, inspect, validate, test, run, debug, package, and deploy Azure Logic Apps Standard projects using the Azure CLI logicapp extension. Use for Standard workflow authoring, optional workspaces, connector discovery, identity-based connections, local runtimes, native workflow tests, and approved cloud lifecycle operations. Not for Consumption-only workflow development.' compatibility: 'Requires Azure CLI 2.67.0 or newer with the logicapp extension; its Python runtime must be 3.10 or newer. Local hosting and native tests have additional task-specific dependencies. Installation, connector catalogs, and Azure operations can require network access and Azure permissions.'

Logic Apps Standard CLI

Use az logicapp as the primary interface for supported Standard project, workflow, connection, validation, runtime, diagnostic, testing, and packaging operations. Do not manually recreate files or Azure wiring owned by a supported command. Manual workflow authoring, workspace files, ignore files, and infrastructure-as-code remain appropriate where the CLI does not own that operation.

Reviewed baseline: extension 1.0.0b1. It is a public preview for evaluation and development, not a claim of production readiness. Use non-production resources for evaluation. Existing core app-management, app-settings, and ZIP-deployment commands are distinct from the extension's preview commands, even where reference pages label extension commands GA. Declared platform support is not live-runtime qualification.

Mandatory procedure routing

This folder is one installable skill package. Resolve bundled files relative to this SKILL.md, not the customer's working directory. Install/copy the entire folder. These references are required procedures, not optional background reading. See the package README for installation, provenance, and maintenance notes.

Before the corresponding operation, read every applicable reference below. For combined tasks, read each required procedure before its phase. If a required file is missing or unreadable, report that operation as blocked. Do not invent syntax, bypass its prerequisites, or fetch an unreviewed substitute.

| Requested operation | Required bundled procedure | |---|---| | Install/check dependencies; diagnose, start, or stop a host | Local runtime | | Discover connectors; create/change/test/delete connections; configure identity or ACLs | Connections and identity | | Inspect/export/change live workflows; invoke/diagnose/cancel/replay runs | Live workflows and runs | | Scaffold, plan, run, or inspect native workflow tests | Workflow testing | | Package, deploy, or change deployment exclusions | Packaging and deployment |

Basic local scaffolding, workspace creation, and offline validation are specified here. Do not start a host, restore packages, invoke workflows, or mutate Azure merely because the skill was activated. Select only the procedures needed for the requested task.

Non-negotiable rules

1. Inspect before mutation. Establish the actual project root and requested scope. Inspect affected workflows, configuration structure/references, ignore files, workspaces, and uncommitted changes. Do not dump secret setting values.
2. Preserve existing conventions. Do not restructure repositories, convert workflow kinds, migrate authentication, normalize aliases, or replace user files unsolicited.
3. Use managed identity by default. For new connections and deployed app configuration, use another authentication method only when explicitly requested by the customer or unsupported by the selected connector/operation. Authentication failure is not proof of lack of support. Never silently fall back to secrets.
4. Enable identity as part of new-project delivery. Configure the supported local identity-based connection mechanism. For deployment-facing work, enable app identity through the authorized provisioning/deployment process. Preserve an existing identity convention; otherwise default to system-assigned identity. Local scaffolding does not authorize Azure mutation; report unapproved cloud prerequisites explicitly.
5. Verify distinct principals and permissions. A local process does not acquire a deployed app's managed identity. Follow the connector's documented local mechanism; do not assume every connector uses DefaultAzureCredential. Verify local and cloud principals, connection access, and least-privilege data-plane roles separately.
6. Discover, do not guess. Obtain connector IDs, operation IDs, parameter sets, and required input shapes from the actual runtime or regional managed catalog. Verify authentication support using metadata and authoritative connector documentation.
7. Protect secrets and sensitive outputs. Never put secret values in command arguments, source control, examples, or shared logs. Treat existing definitions, exports, and provider output as potentially sensitive; protect and review them before sharing. Use supported stdin secret input and setting references. Required protected local/runtime storage is permitted; local settings and test artifacts must be ignored and excluded from deployment.
8. Keep environments configurable. Put deployment-specific endpoints, resource IDs, and environment values in settings or parameters, not hardcoded workflow literals.
9. Guard replacements and concurrency. Inspect before every create; treat creation as non-idempotent. Use --force only for reviewed replacement. Export live workflows before replacement/deletion, retain revisions, and obtain approval for non-atomic writes. Do not bypass conflicts or blindly retry uncertain mutations.
10. Authorize effects, not just targets. Starting local triggers and running test/build code can contact real systems. Establish permitted effects first. Obtain explicit authorization for Azure mutations, cancellation, and replay; preview is not a sandbox.
11. Keep evidence honest. Read structured results even on nonzero exits. Distinguish configured, authorized, accepted, observed, and verified states. An open port, accepted invocation, generated plan, or inspected report is not successful workflow execution.
12. Validate without manufacturing success. Validate incrementally; require strict full-project validation before release packaging/deployment. Preserve stricter repository policy. Do not remove warnings, assertions, outputs, or guards merely to obtain a passing result.
13. Own cleanup precisely. Stop only task-owned runtimes unless asked to leave them running; verify shutdown and shared dependency ownership. Never kill processes by name or stop another user's host/emulator.
14. Preserve deployment boundaries. Merge ignore rules without replacing unrelated entries; inspect the actual package. Do not deploy local settings, tests, state, editor files, logs, settings templates, or generated packages.
15. Keep connector semantics specialized. Use available connector-specific guidance for delivery guarantees, poison handling, and operation-specific tests. If unavailable, use authoritative connector documentation; do not invent specialized behavior.

Defaults and consequential choices

| Decision | Rule | |---|---| | Workflow kind | Preserve existing kinds; new workflows default to Stateful | | Stateful vs Stateless | Stateful for durable history/long-running work; choose Stateless deliberately for suitable short-lived, low-latency work | | Initial scope | Local authoring, unless the request includes further operations | | Authentication | Managed identity, subject only to the exceptions above | | Identity type | Existing convention, otherwise system-assigned; user-assigned for explicit stable/shared/pre-provisioned identity requirements | | Project root/layout | Existing repository convention; otherwise the smallest suitable layout | | Workspace | Optional; reuse an existing workspace and ask only if intent is unresolved | | Context | Optional saved shortcut; never change active selection without authorization | | Automation | Explicit project path and runtime/cloud target coordinates | | Runtime lifetime | Stop task-owned hosts after checks unless explicitly asked to retain them |

Infer paths and established choices from the request/repository. Ask only about missing, consequential decisions. Do not insist on three scaffold questions when answers are known.

1. Verify tooling and select the target

Inspect first; these commands do not install the extension:

az version
az extension list --query "[?name=='logicapp'].{name:name,version:version}" --output table

Minimums for the reviewed release: Azure CLI 2.67.0 and its Python runtime 3.10. If the extension is absent and installation is authorized, use the public extension index:

az extension add --name logicapp --version 1.0.0b1 --allow-preview true
az extension show --name logicapp --output json
az logicapp --help

Check the exit after each command; do not continue after failed installation. If the requested version is unavailable, report the index/network/version error. Do not substitute a private wheel, disable TLS, or bypass organizational package policy. Do not automatically upgrade an installed extension. For a different installed version, inspect each affected command's --help and current official contracts before execution; report material differences instead of assuming this baseline still applies.

Detect OS and shell before using examples. Single-line azurecli blocks avoid shell-specific continuations. App, Orders, and uppercase identifiers are illustrative names: substitute the inspected target, quote paths containing spaces, and use the host OS's path separator. PowerShell/native-wrapper quoting for expressions is specified in the connections procedure.

| Operation | Target contract | |---|---| | Local file authoring/validation | Explicit --path; some commands also accept a local context | | Runtime API inspection/execution | --local --port PORT, or cloud --resource-group GROUP --name APP | | Runtime lifecycle | Local runtime start/show/stop flags; not cloud host management | | Runtime doctor | Local --path and optional --port, or local --context; no --local | | Managed connection creation | --name CONNECTION and --logic-app-name APP, not interchangeable | | Live workflow enable/disable | Deployed apps only |

For API-targeting commands, explicit --port requires --local. A named context owns its coordinates: do not mix it with explicit API target flags. Inspect command-specific help for file-command context combinations; do not assume one universal precedence rule. Cloud work requires the intended Azure login, tenant, subscription, and permissions. Verify account selection independently: saved contexts do not bind subscription/tenant. Avoid changing global account selection; prefer explicit --subscription in automation.

2. Inspect and scaffold locally

Classify the destination as new, an existing Standard project, or a nonempty unrecognized directory. The project/host root contains host.json; workflow directories are its direct children. The repository root may itself be that project root.

For an existing project, inspect host.json, workflow files, connections.json, parameters.json when present, settings names/references, ignore files, workspaces, and affected uncommitted changes. Preserve unrelated content and avoid exposing local values.

For a new project, choose a minimal project-at-root layout or a solution/monorepo child project according to requirements. Support directories such as docs, re