Skill: Detecting Flow Groups

Purpose: Authoritative rules for how an AI agent should group discovered MuleSoft integration artifacts into logical flow groups. The agent MUST follow these rules exactly.

1. Grouping Strategy (Flow Reference Chains)

• HIGHEST PRIORITY: If multiple flows reference the SAME sub-flow via flow-ref (directly or transitively), they MUST be in the SAME group — the shared sub-flow is the unifying element.
• Call-workflow edges: The connectionGraph includes call-workflow edges when one flow calls another flow or sub-flow via flow-ref. Flows linked by these edges (directly or transitively) MUST be in the SAME group. Example: If Flow-A calls Sub-Flow-B and Sub-Flow-B calls Sub-Flow-C, all three belong in ONE group.
• Shared-connection edges: The connectionGraph includes shared-connection edges when multiple flows use the same global configuration (e.g., same http:listener-config, same db:config). Flows sharing configs SHOULD be in the same group unless they are clearly independent.
• Only create separate groups for flows that use DIFFERENT sub-flows with no transitive connection.
• Transitively connected artifacts belong in the SAME group.
• Name each group by business purpose (derived from flow names and HTTP listener paths).

2. Fallback Rules (When no HTTP listeners or schedulers exist)

Do NOT return empty groups. Use this fallback order:

1. Flow-root grouping — one group per CONNECTED flow cluster. Follow call-workflow edges to find clusters. Do NOT create one group per individual flow when they reference each other.
2. Trigger-capability grouping — flows with sources (http:listener, scheduler, jms:listener, file:listener, vm:listener) as entry points. receiveLocationCount includes all triggers.
3. Connected-component grouping — from graph edges (call-workflow, shared-connection) and any remaining connections.

Only leave artifacts in ungroupedArtifactIds if they are truly isolated with no meaningful edges or entry semantics.

For fallback groups, set entryPoint to flow/trigger/internal-entry (not receive-location).

3. Required Output Fields

Each group MUST have:

4. Procedure

1. Call migration_detectFlowGroups to get the artifact connection graph and summaries.
2. If the connectionGraph has few or no call-workflow or shared-connection edges, the flow-ref data may be incomplete. In that case: a. Call migration_listArtifacts with category="custom-code" to find JARs and custom Java classes. b. Read flow source files (migration_readSourceFile) to find flow-ref targets and shared config references. c. Use the discovered call chains and shared configs to merge groups that should be together.
3. Determine logical flow groups using the flow-reference chain strategy above, incorporating both graph edges AND any call chains discovered in step 2.
4. Call migration_discovery_storeFlowGroups with the groups array, ungroupedArtifactIds, and explanation.

5. What NOT to Do

• Do NOT create empty artifactIds arrays.
• Do NOT split flows linked by flow-ref chains into separate groups.
• Do NOT skip source reading when the connectionGraph has missing call-chain edges — incomplete grouping causes downstream analysis failures.