菜单
Rules for planning the migration of a flow to Azure Logic Apps Standard. Covers workflow split policy, 1-orchestration-to-1-workflow rule, source coverage requirements, planning artifact store sequence, and design constraints.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | logic-apps-planning-rules |
| description | Rules for planning the migration of a flow to Azure Logic Apps Standard. Covers workflow split policy, 1-orchestration-to-1-workflow rule, source coverage requirements, planning artifact store sequence, and design constraints. |
Purpose: Authoritative rules for how an AI agent should plan the target Logic Apps Standard architecture. Follow exactly.
⚠️ DECOMPILATION PREREQUISITE: Whenever source behavior required to fully implement the workflows exists only in compiled assemblies (.dll/.exe), you MUST follow skill
dependency-and-decompilation-analysisto decompile BEFORE designing the target architecture. This applies to orchestrations and any workflow-critical logic — custom pipeline components, helper libraries, functoids, map extension code, and shared business rules. Do NOT proceed with planning until all relevant assemblies are decompiled and their logic is understood.
InvokeWorkflow) to call child workflows from parent workflows.Build a one-to-one source coverage map: every discovered orchestration/scenario MUST appear in:
Nothing from the source may be silently dropped.
local.settings.json as WORKFLOWS_INTEGRATION_ACCOUNT_ID and WORKFLOW_INTEGRATION_ACCOUNT_CALLBACK_URL.⚠️ MANDATORY DESIGN PRESERVATION RULE: Do NOT independently simplify, optimize, refactor, merge, reorder, or redesign the BizTalk flow. The target plan MUST preserve the same source design and execution intent unless there is a documented platform gap or the user explicitly asks for a redesign.
When a trigger returns an array (batch of messages), ALWAYS use splitOn on the trigger instead of wrapping actions in a For_each loop. SplitOn debatches the array so each item fires a separate workflow run. Only use For_each if splitOn is not supported by that trigger type.
Do NOT add delete/remove/cleanup actions that remove the trigger input file by default. The runtime does not re-trigger on the same unchanged file, so deleting is unnecessary unless the user explicitly requests it.
⚠️ MANDATORY OVERRIDE — READ THIS FIRST: Source custom code — scripting functoids, external assemblies (.dll), custom pipeline components, helper libraries, map extension objects — MUST ALWAYS map to .NET local functions. Do NOT simplify custom code to expressions, inline code, or any other level. This overrides the ladder below. Translate the real business logic from source or decompiled code — never approximate with expressions.
For all other (non-custom-code) components:
AUTO-APPLY RULE: Always choose the HIGHEST applicable level without asking the user. If a built-in action exists (e.g. XmlParse for XML processing), use it — do NOT fall back to expressions or ask.
XML PROCESSING RULE: For XML parsing, validation, or structured access, ALWAYS use XmlParse / XmlValidation (built-in XML Operations) instead of
xpath()expressions. XmlParse validates against schemas and returns structured JSON. xpath() skips validation and is verbose. This applies to all BizTalk XMLReceive pipeline replacements.
Before generating any workflow definition:
source-to-logic-apps-mapping to look up the exact Logic Apps Standard equivalent for every component.migration_searchReferenceWorkflows and migration_readReferenceWorkflow to find real reference examples.serviceProviderConfiguration and operationId values from references — do NOT invent these.migration_readReferenceDoc to verify connector capabilities.Store planning results in THIS order:
migration_planning_storeMeta — flowId, flowName, explanation, summary.migration_planning_storeArchitecture — flowId and Mermaid flowchart TB diagram.migration_planning_storeWorkflowDefinition — call once PER workflow. Each call MUST include flowId, name, workflowDefinition (with definition.triggers, definition.actions with runAfter, type for each action), and a mermaid field with a flowchart TB diagram. The mermaid field is ENFORCED and will be rejected if missing when multiple workflows exist.migration_planning_storeAzureComponents — flowId and components array.migration_planning_storeActionMappings — flowId and mappings array (source → target for each component; include workflowName when multiple workflows exist).migration_planning_storeGaps — flowId and gaps array (empty if none).migration_planning_storePatterns — flowId and patterns array (empty if none).migration_planning_storeArtifactDispositions — flowId and dispositions array. ONLY include artifacts that need conversion or upload: schemas (.xsd), maps (.btm → XSLT), custom code (.cs/.dll → local function), certificates. Do NOT include orchestrations, pipelines, or bindings. Each entry needs: artifactName, artifactType, conversionRequired, uploadDestination (integration-account / logic-app-artifact-folder / azure-function / not-applicable), uploadNotes (REQUIRED). When conversionRequired=true, also include conversionFrom, conversionTo, conversionNotes. If the plan uses Integration Account, artifact dispositions must consistently use integration-account instead of mixing destinations.migration_planning_finalize — flowId to validate and display the plan.Rules for analysing a single TIBCO flow group's architecture. Covers source file reading depth, Mermaid diagram rules, flow/sub-process rendering, processor mapping priority ladder, and the required multi-step store tool sequence.
Rules for optional cloud deployment and testing of Logic Apps Standard projects. Covers ARM/Bicep generation, deployment method, app settings management, cloud test execution, and reporting.
Rules for generating connections.json files for Logic Apps Standard. Covers serviceProviderConnections format, mandatory reference lookup, FileSystem mountPath rule, and connector parameter constraints.
Rules for generating ordered conversion task plans. Covers mandatory task ordering, required task types, descriptive task ID rules, optional vs non-optional tasks, output path conventions, and what each task must contain.
Rules for discovering, analysing, and classifying missing dependencies during TIBCO flow analysis. Covers JAR/Java decompilation, Maven dependency analysis, custom module classification, and what blocks migration.
Rules for detecting and grouping TIBCO integration artifacts into logical flow groups using a process-call chain strategy. Covers process-call chain rules, fallback grouping when no sources exist, and required output fields.