본문으로 건너뛰기
cccskills
무료GitHub에 공개한국어 소개

azure-logic-apps-standard-cli

Azure CLI의 `logicapp` 확장으로 Logic Apps Standard 워크플로를 만들고 검증합니다. 네이티브 테스트를 실행하고 로컬 또는 클라우드 동작을 진단하며, 연결과 관리 ID 인증을 설정하고 배포 패키지를 준비할 수 있습니다.

원문원문 설명 보기

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 프로젝트와 워크플로를 만들고 살펴봅니다. 변경 내용을 검증하고 테스트하며, 워크플로 실행과 진단, 배포 패키지 준비도 진행합니다. 커넥터 정보를 확인하고 연결 및 관리 ID 인증을 설정하거나 로컬 런타임을 사용할 수 있습니다. 변경하기 전에 기존 파일과 설정을 확인하고, 검증 결과와 실행 상태는 실제로 확인된 범위에 따라 나누어 보고합니다.

이럴 때 유용합니다

새 Logic Apps Standard 프로젝트를 준비하거나 기존 워크플로를 변경하기 전에 영향 범위를 확인할 때 유용합니다. 출시 전 전체 검증, 네이티브 테스트, 로컬 실행 진단, 배포 패키지 생성에도 사용할 수 있습니다. Consumption 전용 워크플로 개발에는 적합하지 않습니다.

사용 예시

  • “이 폴더에 Standard 프로젝트를 만들고 주문 처리 워크플로를 추가해 주세요.”
  • “변경한 워크플로를 검증하고 테스트를 실행한 뒤 결과를 정리해 주세요.”
  • “배포를 위해 검증하고 제외 항목을 확인한 다음 패키지를 만들어 주세요.”

주의 사항

Azure CLI 2.67.0 이상, logicapp 확장, Python 3.10 이상이 필요합니다. 로컬 호스팅과 테스트에는 추가 의존 항목이 필요할 수 있습니다. 확장 설치, 커넥터 정보 조회, Azure 작업에는 네트워크 연결이나 Azure 권한이 필요할 수 있습니다.

이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.

문서 점검

AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.

안전성전송·삭제·명령 실행 등을 명시하고 있는가
A양호Azure 변경과 실행 영향에 대한 승인, 비밀 정보 보호, 교체 전 확인을 요구합니다.
도입의 용이성필요한 도구나 API 키가 적고 적혀 있는가
B일부 부족Azure CLI, 확장, Python 버전을 명시하지만 추가 의존 항목과 권한은 작업에 따라 다릅니다.

점수에는 넣지 않았습니다. 2026년 10월 26일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.

평가가 다르다고 생각되면 재검토를 요청하기

어느 항목이 왜 다르다고 생각하는지 적어 주세요. 로그인은 필요 없습니다. 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(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

acquire-codebase-knowledge

무료요약 있음

기존 프로젝트의 코드와 설정을 조사해 기술 구성, 구조, 아키텍처, 규칙, 연동, 테스트, 우려 사항을 다루는 문서 7개를 작성합니다. 근거 파일을 연결하고 미확인 항목을 표시하며, 계획과 실제 구현의 차이를 드러냅니다.

  • 익숙하지 않은 코드베이스 파악하기
  • 프로젝트 인수인계 문서 준비하기
  • 설계 문서와 실제 구현 비교하기
github/awesome-copilot4.1만2026년 10월 29일 업데이트

acreadiness-assess

무료요약 있음

AgentRC로 저장소의 AI 에이전트 활용 준비도를 평가하고 독립 실행형 HTML 보고서를 생성합니다. 9개 영역의 점수와 우선순위별 개선안을 확인하고, 조직에 맞춘 채점 정책도 적용할 수 있습니다.

  • AI 에이전트 도입 전 준비도 확인
  • 평가 결과에 따라 개선 우선순위 결정
  • 조직별 정책으로 점수 산정
github/awesome-copilot4.1만2026년 10월 29일 업데이트

프로젝트의 실제 코드에서 언어, 프레임워크, 개발 관례를 파악해 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일 업데이트

add-educational-comments

무료요약 있음

지정한 코드 파일에 학습용 주석을 추가해 문법, 프로그래밍 개념, 설계 선택의 이유를 설명합니다. 독자의 지식에 맞춰 설명의 깊이와 반복 정도를 조절하며 파일 구조와 형식을 유지합니다.

  • 기존 코드에 초보자용 설명 추가
  • 문법이나 설계 방식을 선택한 이유 설명
  • 독자의 경험에 맞춰 주석 조정
github/awesome-copilot4.1만2026년 10월 29일 업데이트

github의 스킬 모두 보기

이 스킬의 문제 신고