跳到正文
cccskills
免费在 GitHub 公开中文介绍

azure-logic-apps-standard-cli

使用 Azure CLI 的 `logicapp` 扩展创建和验证 Logic Apps Standard 工作流,运行原生测试、诊断本地或云端运行情况,并准备部署包;还可设置连接与托管标识身份验证。

原文查看原文说明

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.

github/awesome-copilot星标 40,567(GitHub 40,567 + cccskills 0)
集成工具Azure

实测评分 未实测

查看安装方法

适用场景

  • 创建 Standard 项目
  • 发布前验证工作流
  • 运行原生工作流测试
  • 诊断运行中的工作流

中文介绍

功能

使用 Azure CLI 的 logicapp 扩展创建和检查 Logic Apps Standard 项目及工作流,并进行验证、测试、运行、诊断和打包。还可查询连接器信息、设置连接和托管标识身份验证,并使用本地运行环境。修改前会先检查现有文件和设置,之后根据实际确认的内容分别报告验证结果与运行状态。

适用场景

适合准备新的 Logic Apps Standard 项目,或在修改现有工作流前查看影响范围。也可用于发布前的整体验证、原生测试、本地运行诊断,以及生成部署包。不适用于仅面向 Consumption 的工作流开发。

使用示例

  • “在这个文件夹中创建 Standard 项目,并添加订单处理工作流。”
  • “验证修改后的工作流,运行测试并汇总结果。”
  • “为部署进行验证,检查排除项并生成部署包。”

注意事项

需要 Azure CLI 2.67.0 或更高版本、logicapp 扩展以及 Python 3.10 或更高版本。本地托管和测试可能还需要其他依赖项。安装扩展、获取连接器信息或执行 Azure 操作时,可能需要网络连接和 Azure 权限。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。

安全性发送数据、删除文件、执行命令等是否有说明
A良好资料要求授权 Azure 修改和运行影响,保护机密,并在替换前检查。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足资料注明 Azure CLI、扩展和 Python 版本,但部分依赖与权限因任务而异。

不计入评分。 由 AI(OpenAI Codex)于 2026年10月26日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(7)

  • SKILL.md17.6 KB
  • README.md9.1 KB
  • references/connections.md13.1 KB
  • references/live-operations.md10.3 KB
  • references/local-runtime.md8.2 KB
  • references/packaging-deployment.md8.3 KB
  • references/testing.md10.7 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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 operationRequired bundled procedure
Install/check dependencies; diagnose, start, or stop a hostLocal runtime
Discover connectors; create/change/test/delete connections; configure identity or ACLsConnections and identity
Inspect/export/change live workflows; invoke/diagnose/cancel/replay runsLive workflows and runs
Scaffold, plan, run, or inspect native workflow testsWorkflow testing
Package, deploy, or change deployment exclusionsPackaging 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

DecisionRule
Workflow kindPreserve existing kinds; new workflows default to Stateful
Stateful vs StatelessStateful for durable history/long-running work; choose Stateless deliberately for suitable short-lived, low-latency work
Initial scopeLocal authoring, unless the request includes further operations
AuthenticationManaged identity, subject only to the exceptions above
Identity typeExisting convention, otherwise system-assigned; user-assigned for explicit stable/shared/pre-provisioned identity requirements
Project root/layoutExisting repository convention; otherwise the smallest suitable layout
WorkspaceOptional; reuse an existing workspace and ask only if intent is unresolved
ContextOptional saved shortcut; never change active selection without authorization
AutomationExplicit project path and runtime/cloud target coordinates
Runtime lifetimeStop 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.

OperationTarget contract
Local file authoring/validationExplicit --path; some commands also accept a local context
Runtime API inspection/execution--local --port PORT, or cloud --resource-group GROUP --name APP
Runtime lifecycleLocal runtime start/show/stop flags; not cloud host management
Runtime doctorLocal --path and optional --port, or local --context; no --local
Managed connection creation--name CONNECTION and --logic-app-name APP, not interchangeable
Live workflow enable/disableDeployed 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, requests, fixtures, tests, logs, and artifacts are optional and created only for actual work. Prefer package output outside the host root. Do not author .azurelogicapps runtime state.

After inspecting the destination, scaffold using explicit paths:

az logicapp project create --path App --workflow Orders

Add --workflow-kind Stateless only for an intentional Stateless choice. Use --adopt only for a reviewed nonempty unrecognized directory, not as routine setup. Inspect generated host/settings/connection/workflow files before extending them. Create additional workflows without replacing existing ones:

az logicapp workflow create --path App --workflow Notify --kind Stateful

--file FILE accepts a reviewed full workflow file or bare definition for local import. Creation is local-only and non-idempotent. Do not use it to add a cloud workflow.

Before writing sensitive local settings, confirm effective Git exclusions. Merge rules relative to the actual repository and host roots; never copy .gitignore over .funcignore. Always exclude local settings/state from source control and deployment. If changing deployment exclusions, first read the packaging procedure and follow its concrete rules.

Gate: Correct project root, requested workflow kinds, preserved user files, effective secret exclusions, and identity-based configuration or an explicitly reported prerequisite.

3. Optional workspace and context

A .code-workspace file is optional; opening the host directory is valid. Reuse an existing workspace. When a new multi-root workspace is requested, use relative paths to real folders and put the Logic Apps host project first. Do not create empty folders just to populate it. Adapt this JSON to the selected layout; it is not a required filename or folder scheme:

{
  "folders": [
    { "name": "Logic App", "path": "App" }
  ]
}

Preserve existing workspace settings and names. Add docs/test roots only when useful and present. For a project-at-root workspace, the project path is ".".

Saved contexts are optional. Inspect context list before choosing a unique project-specific name. If requested, create a shortcut without implicitly selecting it:

az logicapp context list --output table
az logicapp context create --name orders-local --path App --port 7071
az logicapp context show --name orders-local

Use context use --name NAME or creation's --use only when active selection is authorized. context update preserves omitted fields and does not select a target; editing an active target prompts unless --yes is authorized. A kind change requires explicit local path/port or cloud resource group/app coordinates. Inspect its help before changing kind. context delete deletes only a shortcut; deleting the active one clears selection without choosing a replacement. Stores follow AZURE_CONFIG_DIR; no credentials belong in them.

4. Author and validate

Preserve workflow structure/kind. Use stable action/trigger names. Implement the required ordering, branching, retries, timeouts, and failure paths; terminal success/failure paths must not both execute. Use discovered operation shapes and configurable environment values. Create representative non-sensitive fixtures only when needed.

For built-in connector discovery, read both the local-runtime and connections procedures before establishing safe host startup and querying the catalog. For runtime-backed validation, read the local-runtime procedure and establish readiness first. Native tests can instead use authored mocks without starting a host.

Validate the workflow under active development:

az logicapp workflow validate --path App --workflow Orders

For completed project authoring and before release packaging/deployment:

az logicapp workflow validate --path App --all --fail-on-warning

When runtime-backed validation is required, first establish host readiness:

az logicapp workflow validate --path App --all --fail-on-warning --with-runtime --local --port 7071

Do not start a host solely for an offline edit/review. Assess findings and preserve repository policy; report unrelated pre-existing failures separately without weakening release gates. Static validation, runtime-template validation, native assertions, and live integration checks are separate evidence. A completed runtime validation response is required; accepted asynchronous validation alone does not establish completion.

Completion evidence

Apply only gates relevant to the requested task; do not turn an inspection into a deployment.

TaskRequired evidence
Scaffold/authorRequested files/kinds and behavior; affected validation; no unsolicited restructuring
Connections/identityDiscovered shape, setting references, selected principal, verified grants or explicit blockers; no secrets exposed
Full-project releaseStrict full-project validation passes; required runtime validation completes
Native testsReviewed meaningful assertions, actual executed counts/outcome, skipped counts and limitations
Live execution/diagnosisActual supported run evidence, required outputs/effects, failed action/platform error where available
Live mutationRetained export/revision, guarded write result, separate observed runtime behavior
Cancellation/replayRequested/accepted/observed/unknown distinguished; no inferred new run IDs
Package/deployInspected archive/exclusions; authorized prerequisites; required post-deploy verification
Runtime ownershipTask-owned processes stopped and verified, or explicitly retained with coordinates/ownership

State concrete missing permissions, dependencies, resources, unexecuted checks, retained resources, and uncertain effects. Do not call configured identity authorized, an accepted request complete, a skipped suite passing, or a blocked prerequisite satisfied.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

扫描现有项目的代码与配置,生成涵盖技术栈、结构、架构、规范、集成、测试和风险的七份文档。为结论标注文件依据和未知项,并指出计划描述与实际实现的差异。

  • 了解陌生代码库
  • 准备项目交接文档
  • 对照设计资料与实际实现
github/awesome-copilot4.1万2026年10月29日 更新

acreadiness-assess

免费有简介

使用AgentRC评估代码仓库对AI智能体的准备情况,并生成可独立打开的HTML报告。查看九个方面的评分和优先改进建议,也可按组织自定评分政策。

  • 引入AI智能体前检查准备情况
  • 根据评估结果安排改进优先级
  • 按组织自定政策评分
github/awesome-copilot4.1万2026年10月29日 更新

使用AgentRC分析项目代码中的语言、框架和开发惯例,生成或更新AI编程代理的指令文件。可集中写入一个文件,也可按主题和项目区域拆分,并在写入前预览改动。

  • 创建VS Code Copilot指令
  • 将开发规则变更写入指令
  • 按单体仓库区域整理规则
github/awesome-copilot4.1万2026年10月29日 更新

acreadiness-policy

免费有简介

按团队或组织标准调整AgentRC准备度评估。可选择或创建JSON策略,调整检查权重、停用无关检查、设置通过率,并在CI流程中设定自动检查门槛。

  • 制定组织共用的评估标准
  • 只评估AI相关的准备情况
  • 调整特定检查项的权重
github/awesome-copilot4.1万2026年10月29日 更新

ad-campaign-analyzer

免费有简介

分析你提供的广告成效数据,找出浪费支出和表现较好的广告,并整理暂停、加预算或继续测试的候选项。还可比较不同平台、评估A/B测试差异,并提出预算调整建议。

  • 找出应暂停的广告或关键词
  • 发现适合增加预算的广告系列
  • 判断A/B测试的数据是否足够
github/awesome-copilot4.1万2026年10月29日 更新

为指定代码文件添加学习注释,解释语法、编程概念和设计选择;可按读者水平调整讲解深度和重复频率,并保持文件结构、编码与语法。

  • 为现有代码添加初学者说明
  • 解释语法或设计选择的原因
  • 按读者经验调整注释内容
github/awesome-copilot4.1万2026年10月29日 更新

查看 github 的全部技能

报告此技能的问题