• "Create a Mule app/integration/flow"
• "Build integration between X and Y"
• "Sync data from X to Y" (e.g., "Salesforce to Slack", "MySQL to Salesforce")
• "Query Salesforce", "Send Slack notifications"
• "Schedule jobs", "Poll data every N minutes"
• "Create webhooks", "Build event-driven flows"

• Phase 1: Technical Design (Steps 1–7). Identify systems, search Exchange, describe connectors, pick trigger and providers, present a Technical Design Summary, wait for the user to approve. Phase 1 writes nothing to the user's project directory — all artifacts live under workspace-relative paths:

  tmp/mule-dev-env.json

  (env cache owned by

  validate_prerequisites.sh

  ),

  tmp/connector-choices/*.json

  (draft connector picks), and

  tmp/connector-metadata/*.json

  . The pinned

  tmp/connector-versions/*.json

  directory that Phase 2 reads is only populated after Step 7's approval, by

  commit_connectors.sh

  .
• Phase 2: Build (Steps 8–17). Create the real project, generate config and flow XML, run the build, declare completion. Phase 2 is the only phase that touches the user's project directory.

• Build → cleanup → completion separation (Step 16 → Step 17 → Step 18). Three responses, in order, each with a single tool call:

  mvn clean package

  , then

  rm -r tmp/

  , then the completion signal. Do not bundle them. Wait for each result before moving on.
• One mvn invocation per response. When re-running a build after a fix, emit only the

  mvn

  command in that response. Do not bundle it with further edits, follow-up shell commands, or the completion signal.
• "Completion" means the build already passed. You may only declare completion after a response that ran

  mvn clean package

  came back with

  BUILD SUCCESS

  .
• Connector versions come ONLY from the Step 3 flow. Never paste a version from

  references/connector-catalog.md

  , from training-time memory, or from extrapolation. Step 3 is a three-script dance:

  get_latest_connector.sh

  lists ranked candidates (stdout only, no pin file),

  pick_connector.sh <nickname> <gav>

  records the chosen row as a draft in

  tmp/connector-choices/

  , and

  commit_connectors.sh

  (Step 8, first action after TDD approval) promotes every draft to

  tmp/connector-versions/

  . Every GAV that reaches

  dx mule project create --dependencies

  or

  pom.xml

  must be pulled from a

  tmp/connector-versions/*.json

  file via

  scripts/build_deps.sh

  (for the full

  --dependencies

  string at Step 8) or

  scripts/build_gav.sh

  (for a single connector's GAV elsewhere in Phase 2). The catalog's versions are snapshots that drift — treat it only as a connector-identity reference, not as a version source.
• The agent does the picking, not the script.

  get_latest_connector.sh

  deliberately emits a plain ranked list with no score, no emoji, and no "winner" signal. When the list has one row the choice is obvious. When it has several rows the agent must decide which one matches the user's stated system — and if the rows represent real variants of the same family (Slack

  mule4-slack-connector

  vs

  mule-slack-connector

  ; FTP vs FTPS; Dynamics 365 vs Dynamics GP/NAV/BC; IBM MQ vs Solace vs JMS), the decision belongs to the user via

  AskUserQuestion

  , not to the agent's guess. The cost of one extra prompt is one turn; the cost of a silent wrong variant is a full Phase-2 rewrite.
• No HTTP fallback without evidence. You may only classify a system as "no dedicated connector exists, use HTTP" AFTER

  scripts/get_latest_connector.sh <system>

  has run AND returned zero matches (exit 1) OR every row in the ranked list is obviously a different product (no assetId shares tokens with the system name beyond noise words like

  mule

  /

  connector

  ). Declaring HTTP as the answer before the search has run is forbidden. Exchange carries dedicated connectors for hundreds of SaaS products that are easy to miss when reasoning from training-time knowledge alone — the helper script is the authoritative check. A dedicated connector gives metadata discovery, typed operations, and correct authentication; HTTP gives raw request plumbing the user would then have to wire up by hand, so quietly falling back to HTTP is a real loss, not a neutral choice. Note that any ranked row whose

  groupId

  is a UUID (e.g.

  a50e4364-a38c-4340-b05a-c1f8ebed0748:…

  ) is a connector the user's organization has published privately to Exchange — treat these as first-class candidates, not noise. An org that took the trouble to publish a private connector usually wants it used, often because it wraps internal endpoints, custom auth, or a golden-path the public connector can't cover.

<ask_followup_question>

<AskUserQuestion>

tmp/connector-choices/<nick>.json

pick_connector.sh

foo.queue

orders.topic

events-stream

messaging broker (backend unspecified)

sources[]

• Major SaaS platforms (Salesforce, ServiceNow, NetSuite, Workday) → search for dedicated connector in Step 3.
• Standard protocols (Database, JMS, FTPS, SFTP) → search for protocol-specific connector in Step 3.
• Mid-market SaaS (Stripe, Shopify, HubSpot, Twilio, Plaid, etc.) → search for dedicated connector in Step 3. Do NOT assume these have no connector — Exchange has dedicated connectors for many of them. Training-data intuition that "Stripe/Shopify/etc. is a REST-API-only system" is unreliable; the search is the authority.
• Queue or Pub/Sub with a named backend ("Kafka topic", "IBM MQ", "SQS", "Solace") → search for that specific connector in Step 3.
• Queue or Pub/Sub without a named backend (the prompt uses "queue", "topic", or a bare destination name without naming the broker technology) → per the Step-2 anti-pattern above, the destination name is not the backend. In Step 3, escalate via

  AskUserQuestion

  to let the user pick the backend (JMS via any broker provider, Kafka, IBM MQ, Solace, SQS, etc.). Only if the user declines to choose should you default to

  mule-jms-connector

  — JMS is the generic protocol layer that fits any broker, with the broker selected in Step 6 via the connection provider (active-mq, active-mq-nct, generic).
• Unknown/Unclear / custom internal APIs → still search Exchange first in Step 3; HTTP is the fallback only when Step 3's search returns nothing plausibly related.

get_latest_connector.sh

ask_followup_question

1. List candidates with

   get_latest_connector.sh

   .
2. Decide which row is the right fit — inline rationale if the choice is obvious,

   AskUserQuestion

   if the rows are real variants of the same system family.
3. Draft the chosen GAV with

   pick_connector.sh

   . The draft lands in

   tmp/connector-choices/<nick>.json

   and stays there through Phase 1.

get_latest_connector.sh

databricks

aws-storage

snowflake

database

salesforce

mule-amazon-s3-connector

mule-db-connector

mule-amazon-s3-connector

mule-plugin-aws-storage-api

mule-db-connector

<uuid>:mule-plugin-customer-warehouse-database

• The only acceptable source for a connector's version number is

  get_latest_connector.sh

  run against live Exchange in the current session, recorded via

  pick_connector.sh

  , and later promoted to

  tmp/connector-versions/

  by

  commit_connectors.sh

  . This applies equally to

  dx mule project create --dependencies

  ,

  pom.xml

  <dependency>

  blocks, and every other place a version appears.
• Do not paste a version from

  references/connector-catalog.md

  . The catalog exists to help identify which connector to use (asset ID, purpose); its version numbers are best-effort snapshots that drift.
• Do not invent a version from memory or by extrapolating. Version numbers on Exchange are not predictable.
• Do not write a version before the corresponding

  tmp/connector-choices/<name>.json

  draft exists on disk.

org.mule.connectors:mule-http-connector:1.11.1

mule-salesforce-connector

AskUserQuestion

• slack

  →

  mule-slack-connector

  (community, v4.x) vs

  mule4-slack-connector

  (premium MuleSoft, v2.x). Different OAuth shapes, different operations — neither is a "newer version" of the other.

• ftp

  →

  mule-ftp-connector

  (plain) vs

  mule-ftps-connector

  (TLS). Always confirm and suggest FTPS for best security practices.

• ibm-mq

  vs

  solace

  vs

  kafka

  vs

  jms

  — a destination name in the prompt (e.g.

  foo.queue

  ,

  bar.topic

  ) does NOT identify the backend. Unless the prompt explicitly names the broker technology, escalate with these as options;

  mule-jms-connector

  is the generic-protocol fallback when the user declines to pick.

• microsoft-dynamics-*

  — 365, GP, NAV, 365-Business-Central, CRM are different products the user may have meant interchangeably.

• oracle-ebs

  vs

  oracle-ebs-122

  — alternate EBS major versions.
• Any pair whose assetIds share the target system's name and differ only in a variant suffix, protocol marker, major-version marker, or the

  mule4-

  vs

  mule-

  prefix.
• A public connector + a private (UUID-groupId) connector for the same system family — e.g.

  com.mulesoft.connectors:mule4-snowflake-connector

  and

  <uuid>:mule-plugin-snowflake-sys-api-json

  both showing up in a

  snowflake

  search. The org-published asset usually exists for a reason (custom auth, internal endpoints, a wrapper around the public connector), so NEVER silently pick the public one when a private alternative is in the same ranked list — surface both with

  AskUserQuestion

  and let the user choose.

<ask_followup_question>
<question>Two Mule 4 Slack connectors exist on Exchange. Which should this integration use?</question>
<options>[
  "org.mule.connectors:mule-slack-connector:4.3.2 — community Slack connector",
  "com.mulesoft.connectors:mule4-slack-connector:2.0.1 — MuleSoft premium Slack connector",
  "Other — describe which Slack variant you need"
]</options>
</ask_followup_question>

• Only

  "type": "extension"

  (Mule 4 compatible) — Mule 3

  type=connector

  assets, templates, examples, and rest-apis are filtered out.
• Any groupId whose asset is

  type="extension"

  is admissible; ranking keeps first-party connectors on top via a 3-tier preference (

  com.mulesoft.connectors

  >

  org.mule.connectors

  > other).
• Latest semantic version within each

  (groupId, assetId)

  group.
• Token-overlap scoring with the search term; the premium groupId and shorter assetId break ties. Scores are used for ordering only and are never emitted.
• Two pages fetched in parallel (offsets 0 and 200) so broad searches like

  salesforce

  don't drop candidates off a single page.

<flow-ref>

AskUserQuestion

1. tmp/connector-choices/<nick>.json

   exists on disk (Step 3, via

   pick_connector.sh

   ).

2. tmp/connector-metadata/<nick>.json

   exists on disk (Step 4).

sources[]

for f in tmp/connector-metadata/*.json; do
  echo "--- $f ---"
  jq '{namespace: .namespace.prefix, sources}' "$f"
done

describe_connector.sh

sources[]

http:listener

sources[]

sources[]

on-new-*

on-updated-*

on-modified-*

on-*-arrived

poll-*

*-listener

*-trigger

describe-connector

--type source

NODE_NO_WARNINGS=1 anypoint-cli-v4 dx mule describe-connector \
  --connector "$(bash scripts/build_gav.sh tmp/connector-choices/<nick>.json)" \
  --type source \
  --name <source-name> \
  --output json

source-detail

• If the source's

  childElements[]

  includes a

  scheduling-strategy

  element, this is a polling source — the connector itself handles the cadence natively. When the user's prompt names a cadence ("every N", "daily", "hourly") AND the matched source is a polling source, the cadence goes inside the source's

  <scheduling-strategy>

  child. Do NOT introduce a separate top-level

  <scheduler>

  alongside it. Example correct shape:
  xml

  <shopify:on-updated-product-trigger config-ref="shopifyConfig">
      <scheduling-strategy>
          <fixed-frequency frequency="3000" startDelay="5000"/>
      </scheduling-strategy>
  </shopify:on-updated-product-trigger>

• If the source has no

  scheduling-strategy

  child and exposes an event (

  on-new-*

  ,

  on-modified-*

  ), it's an event source — use it directly; no top-level scheduler needed.
• If the source's shape includes

  listenerConfig

  references, it's a webhook receiver — suitable for "receive callback at endpoint" prompts.

AskUserQuestion

<ask_followup_question>
<question>Which Salesforce event should trigger this flow?</question>
<options>[
  "salesforce:replay-topic-listener — subscribe to a Salesforce streaming topic",
  "salesforce:modified-object-listener — fire when a record of a given sObject is modified",
  "Other — pick a different source"
]</options>
</ask_followup_question>

• No connector source fits the user's intent (Rung 1 examined the candidates and none matched), AND
• The prompt names a cadence ("every N", "daily", "hourly", "poll every…"), AND
• The flow body will call connector operations (not event-driven).

<scheduler>

<fixed-frequency>

<cron>

on-updated-product-trigger

<scheduler>

shopify:product-list

• The prompt explicitly says "expose endpoint", "receive HTTP request", "provide REST API", "webhook at /path", AND
• No connector source in scope is a webhook-style receiver.

<http:listener>

configs[]

connectionProviders

• Multiple configs or multiple providers → MUST use

  AskUserQuestion

  . The user's choice determines both which

  config-name

  and which

  --connection-provider

  you pass to Step 11's

  config-detail

  call, and which XML structure you write in Step 12.
• Exactly one config and exactly one provider → DO NOT prompt. State the choice inline in one line ("Using

  s3:config[connection]

  — the only option provided by the connector") and proceed. Prompts that offer a single "option" look like pointless ceremony and waste a conversation turn.

configs

config[connection]

config[connection]

listener-config[listener-connection]

request-config[request-connection]

config[basic, role]

streams-config[streams]

config[basic, oauth-user-pass, jwt, oauth-client-credentials]

config[my-sql-connection, oracle-connection, data-source-connection, generic-connection, ...]

pom.xml

This connector offers four connection providers. Which should this integration use?

• basic

  — username + password + security token

• oauth-user-pass

  — OAuth with user credentials

• jwt

  — JWT bearer token (server-to-server)

• oauth-client-credentials

  — OAuth client credentials

(config-name, connection-provider)

describe-connector

--name

--config-name

NODE_NO_WARNINGS=1 anypoint-cli-v4 dx mule describe-connector \
  --connector "$(bash scripts/build_gav.sh tmp/connector-choices/sfdc.json)" \
  --type connection-provider \
  --name basic-connection \
  --config-name sfdc-config \
  --output json > tmp/connector-metadata/sfdc-config.json

Then read `tmp/mule-dev-env.json` for the Mule version and use `build_deps.sh` to emit the full `--dependencies` string from the pins on disk — do not retype GAVs from previous tool output, and do not inline `$(build_gav.sh ...)` once per connector:

```bash
MULE_VERSION=$(jq -r '.mule_version' tmp/mule-dev-env.json)

NODE_NO_WARNINGS=1 anypoint-cli-v4 dx mule project create <project-name> \
  --group-id com.example \
  --mule-version "$MULE_VERSION" \
  --dependencies "$(bash scripts/build_deps.sh)"

build_deps.sh

tmp/connector-versions/*.json

db-driver.json

http.json

$(build_gav.sh …)

$(…)

dx mule project create

build_deps.sh

tmp/connector-versions/

build_deps.sh

commit_connectors.sh

<http:listener>

mule-http-connector

mule-http-connector

<s3:new-object-listener>

<salesforce:replay-topic-listener>

get_latest_connector.sh mule-http-connector http

pick_connector.sh http <gav>

commit_connectors.sh

dx mule project create

tmp/connector-versions/http.json

build_deps.sh

Can't resolve http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd

--dependencies

tmp/connector-versions/*.json

com.mulesoft.connectors:mule-amazon-s3-connector:6.6.0

--dependencies

build_deps.sh

mvn clean package

• pom.xml

  (Maven configuration with dependencies)

• mule-artifact.json

  (artifact metadata with correct Java version)

• src/main/mule/<project-name>.xml

  (flow definition)

• src/main/resources/

  (configuration files)

tmp/connector-choices/db-driver.json

<project-name>/pom.xml

<dependency>

<sharedLibrary>

mule-db-connector

tmp/connector-choices/db-driver.json

mule-db-connector

db-driver.json

dependencies[]

1. <dependency>

   inside

   <dependencies>

   , verbatim from the sidecar:

<dependency>
    <groupId>{groupId}</groupId>
    <artifactId>{artifactId}</artifactId>
    <version>{version}</version>
</dependency>

1. <sharedLibrary>

   inside the

   mule-maven-plugin

   <configuration><sharedLibraries>

   —

   groupId

   /

   artifactId

   copied verbatim from the

   <dependency>

   above (no version here).

<configuration>
    <sharedLibraries>
        <sharedLibrary>
            <groupId>{groupId}</groupId>
            <artifactId>{artifactId}</artifactId>
        </sharedLibrary>
        <!-- repeat for every entry in db-driver.json -->
    </sharedLibraries>
</configuration>

--dependencies

mule-http-connector

oauth|jwt|auth-code|authorization-code

bash <skill-dir>/scripts/maybe_add_http_connector.sh \
  --project ./<project-name> \
  "oauth-user-pass"    # one argument per Step-6 provider

<skill-dir>

SKILL.md

oauth

jwt

auth-code

authorization-code

1. Reuses

   <project-name>/tmp/connector-choices/http.json

   if the agent already picked HTTP in Step 3, otherwise runs

   get_latest_connector.sh mule-http-connector http

   and drafts the top row via

   pick_connector.sh http <gav>

   — HTTP is an unambiguous search, so no user prompt is needed.
2. Inserts a

   <dependency>

   block before

   </dependencies>

   in

   <project-name>/pom.xml

   (with

   <classifier>mule-plugin</classifier>

   ).
3. Is a no-op if the HTTP connector is already present.

config-detail

oauth-callback-config

The content of element '<connector>:<connection-provider>' is not complete

config-detail

tmp/connector-metadata/<nickname>-config.json

cat tmp/connector-metadata/sfdc-config.json

--name

--config-name

NODE_NO_WARNINGS=1 anypoint-cli-v4 dx mule describe-connector \
  --connector "$(bash scripts/build_gav.sh tmp/connector-versions/sfdc.json)" \
  --type connection-provider \
  --name basic-connection \
  --config-name sfdc-config \
  --output json

attributes

childElements

{
  "name": "sfdc-config",
  "prefix": "salesforce",
  "elementName": "sfdc-config",
  "attributes": [ { "attributeName": "name", "required": true } ],
  "childElements": [
    { "paramName": "expirationPolicy", "prefix": "salesforce", "elementName": "expiration-policy" }
  ],
  "connectionProviders": [
    {
      "name": "basic-connection",
      "prefix": "salesforce",
      "elementName": "basic-connection",
      "attributes": [
        { "attributeName": "username", "required": true },
        { "attributeName": "password", "required": true },
        { "attributeName": "securityToken", "required": true }
      ],
      "childElements": [
        { "paramName": "reconnection", "prefix": "mule", "elementName": "reconnection" }
      ]
    }
  ]
}

jq '.connectionProviders[0].childElements[] | select(.paramName == "oauthCallbackConfig")' tmp/connector-metadata/sfdc-config.json

1. Attributes pattern (e.g., Salesforce basic-connection):
   xml

   <salesforce:basic-connection
       username="${salesforce.username}"
       password="${salesforce.password}"
       securityToken="${salesforce.securityToken}" />

2. Child elements pattern (e.g., Slack OAuth):
   xml

   <slack:slack-auth-connection>
       <slack:oauth-authorization-code
           consumerKey="${slack.consumerKey}"
           consumerSecret="${slack.consumerSecret}" />
   </slack:slack-auth-connection>

attributes

attributes

childElements