// Rules for planning the migration of a TIBCO flow to Azure Logic Apps Standard. Covers workflow split policy, 1-flow-to-1-workflow rule, source coverage requirements, planning artifact store sequence, and design constraints.
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.
| name | logic-apps-planning-rules |
| description | Rules for planning the migration of a TIBCO flow to Azure Logic Apps Standard. Covers workflow split policy, 1-flow-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 for a TIBCO migration. Follow exactly.
⚠️ DEPENDENCY PREREQUISITE: Whenever source behavior required to fully implement the workflows exists only in custom Java classes, custom TIBCO modules, or compiled JARs, you MUST follow skill
dependency-and-decompilation-analysisto analyse dependencies BEFORE designing the target architecture. This applies to flows and any workflow-critical logic — custom Java components, custom transformers, Mapper/XSLT modules with complex logic, and shared utility libraries. Do NOT proceed with planning until all relevant dependencies are analysed and their logic is understood.
process-call) MUST map to its own separate Logic Apps workflow.InvokeWorkflow) to call child workflows from parent workflows, mirroring the process-call pattern.Build a one-to-one source coverage map: every discovered flow/sub-process/processor 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 source 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 — custom Java classes, custom TIBCO modules/connectors, Java-interop XPath expressions, custom message processors — 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 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. SQL Connector for JDBC SQL activities, HTTP for http:request), use it — do NOT fall back to expressions or ask.
Mapper/XSLT PROCESSING RULE: For Mapper/XSLT transformations (
mapper activity), assess complexity. Simple field mappings (process-data field expressions, basic map/filter) → Liquid templates or Compose actions. Complex scripts with reduce, groupBy, match, custom functions → .NET local functions. Always flag Mapper/XSLT conversions as gaps requiring review.
Before generating any workflow definition:
source-to-logic-apps-mapping to look up the exact Logic Apps Standard equivalent for every TIBCO processor.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: Mapper/XSLT scripts (.dwl → Liquid/XSLT), RAML/OAS specs, JSON/XML schemas, custom Java code (.java → local function), certificates. Do NOT include flow XMLs or property files. 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.