1. Exact path supplied — use it directly.
2. Rough location or folder name given (e.g. "the order-api project", "in my documents", "the one in ~/projects") — use

   find

   to locate a

   pom.xml

   matching that hint and confirm with the user if more than one match is found.
3. Multiple projects open/in scope and an API name was given, but no project hint (e.g. a multi-root workspace, or more than one

   pom.xml

   reachable from context) — before falling back to "current/active project," check whether the named API's

   <{artifactId}.version>

   property (or a matching hardcoded

   <dependency>

   artifactId) exists in only one of the open projects'

   pom.xml

   files:
   • Unique match — use that project silently. Do not ask; a name that only exists in one place is not actually ambiguous.
   • Matches multiple projects — ask which project, the same way as case 5 below.
   • Matches none of the open projects — do not ask "which project" (that implies the project is the problem, when it's more likely the API name). Instead say:

     I couldn't find an API named

     <name>

     in any of the open projects (

     <list the open project names/paths>

     ). Did you mean a different API name, or is it in a project that isn't open right now? This check only applies when 2+ projects are genuinely in scope. With a single open/reachable project, skip straight to case 4 — never ask when there's nothing to disambiguate.

4. Current working directory implied (e.g. "this project", "the current one"), or only one project is in scope — check if

   pom.xml

   exists in the current directory and use it.
5. Nothing given — no project hint AND no API name to disambiguate by — with multiple projects in scope — this includes fully generic requests like "update the API version" or "check for updates" when 2+ projects are open and no prior project has been established this conversation. Do not guess a "current directory" in this case, even if one happens to be technically active (e.g. whichever file tab last had focus) — a generic request with no name or path given is exactly the ambiguous case this step exists to catch. Ask:

What project do you want to work on? You can give me the full path, a folder name, or just tell me it's the current directory.

pom.xml

<project>

Do you want to display the current API version(s), or change one?

1. Read

   pom.xml

   . Find all properties inside

   <properties>

   whose name ends in

   .version

   and corresponds to an API spec dependency. To identify API spec dependencies, check the matching

   <dependency>

   block:
   • Classifier check (preferred): API spec deps use one of these classifiers:

     raml

     ,

     oas

     ,

     graphql

     ,

     protobuf

     ,

     fat-protobuf

     ,

     evented-api

     . Connectors use

     mule-plugin

     . If a classifier is present and matches this list, it is an API spec.
   • artifactId fallback: If no classifier is set, check whether the

     artifactId

     contains the word

     api

     — this is the common naming convention for API spec artifacts. Skip any dependency whose classifier is

     mule-plugin

     or that matches neither signal.
2. Print all matching ones:

API dependency versions (from pom.xml <properties>):

  order-api.version    → 1.0.0
  customer-api.version → 2.1.0

1. If none are found, say so clearly and suggest the user check the Project Properties → API Specs tab in Anypoint Studio to confirm APIs are added to the project.

1. Extract all API names the user specified. If none were named, fall back to DISPLAY ALL.
2. Read

   pom.xml

   . For each named API, find its

   <{artifactId}.version>

   property.
3. Print each result:

order-api.version    → 1.0.0
customer-api.version → 2.1.0

1. If a named API's property is not found, flag it and list the available API version properties so the user can confirm the correct name.

1. Read

   pom.xml

   and identify all API spec dependencies (same classifier/artifactId logic as DISPLAY ALL).
2. For each API, discover its full version list using the Version Discovery procedure below.
3. Report results:
   If newer versions exist for any API:

   Newer versions available:
   
     order-api:    current 1.0.0 → latest 2.0.0
     customer-api: current 1.5.0 → latest 1.6.0
   
   No updates available:
     billing-api: 3.1.0 (already latest)
   
   Would you like to update any of these?

   STOP — if the user wants to update, transition to the CHANGE path starting at Step 7 for the APIs they name.
   If no newer versions exist for any API:

   All APIs are on their latest versions:
   
     order-api:    1.0.0
     customer-api: 2.1.0
     billing-api:  3.1.0
   
   Would you like to change any version anyway?

   STOP — if yes, transition to CHANGE path at Step 7.

1. Extract the API name(s) the user specified.
2. For each named API, discover its full version list using the Version Discovery procedure below, and compare against the current version to determine if a newer one exists.
3. Go through each named API one at a time in the order the user asked:
   If a newer version exists:

   order-api — current: 1.0.0
   A newer version is available: 2.0.0
   
   Would you like to update it?

   STOP — if yes, proceed with the CHANGE flow for this API (Step 7c onwards). If no, move to the next named API.
   If already on the latest version:

   order-api is already on the latest version: 1.0.0
   
   Would you like to change it to a different version anyway?

   STOP — if yes, proceed with the CHANGE flow for this API (Step 7c onwards). If no, move to the next named API.
4. After all named APIs have been addressed, if any were queued for change, proceed to Step 8.

1. Read

   pom.xml

   and list all API dependency version properties.
2. Ask which API(s) they want to update.

groupId

artifactId

<dependency>

pom.xml

"source": "error"

list

describe

• If no pom.xml changes have been made yet, stop and tell the user, citing the row's

  error

  field:

  Failed to fetch versions from Exchange for

  <artifactId>

  . Check that

  anypoint-cli-v4

  is authenticated and you have network access, then try again.

• If pom.xml was already partially modified in a prior step, restore it to the backed-up state before stopping with the same message.

anypoint-cli-v4

anypoint-cli-v4

Bash

<skill-dir>/scripts/fetch_versions.sh

<skill-dir>

SKILL.md

../scripts/...

<groupId>:<artifactId>:<currentVersion>

<skill-dir>/scripts/fetch_versions.sh \
  "<groupId1>:<artifactId1>:<currentVersion1>" \
  "<groupId2>:<artifactId2>:<currentVersion2>"

[
  {
    "groupId": "org.example", "artifactId": "order-api", "currentVersion": "1.0.0",
    "versions": ["2.0.0", "1.1.0", "1.0.0"],
    "source": "list"
  }
]

source

• "list"

  — the normal path. Internally this ran

  exchange asset list <artifactId> --output json

  , filtered to rows matching the exact

  groupId

  /

  assetId

  , sorted by semver (highest first). Trust this fully — it is not anchored to any single version, so it doesn't have the false-negative failure mode described below.

• "describe-fallback"

  —

  list

  returned zero matching rows for this asset, so the script fell back to

  exchange asset describe <groupId>/<artifactId>/<currentVersion>

  and parsed its

  otherVersions

  field. Surface the row's

  warning

  field to the user verbatim —

  describe

  's version list is anchored to the version you query with and has been observed to come back empty when that anchor version is not the latest published one, even when newer versions genuinely exist. Since CHECK/CHANGE always query from whatever version is currently pinned in

  pom.xml

  (almost never the latest), treat this row's version list as possibly incomplete.

• "error"

  — both

  list

  and the

  describe

  fallback failed for this asset. Surface the row's

  error

  field. For Step 7b (CHANGE), treat this the same as an Exchange-fetch failure (see below). For Steps 5/6 (CHECK), report the failure for that specific API and continue processing the others — don't abort the whole check over one API's lookup failure.

build-mule-integration/scripts/search_templates.sh

manage-global-configurations/scripts/get_latest_connector.sh

exchange asset list

order-api

is already on version

1.0.0

— no changes made.

<{artifactId}.version>

<properties>

<properties>

<version>${order-api.version}</version>

ARTIFACT_ID="order-api"
NEW_VERSION="1.1.0"

awk -v key="${ARTIFACT_ID}.version" -v val="$NEW_VERSION" '
  $0 ~ "<" key ">" { sub(/>.*</, ">" val "<") }
  { print }
' pom.xml > pom.xml.tmp && mv pom.xml.tmp pom.xml

<{artifactId}.version>

<version>1.0.0</version>

1. Add

   <{artifactId}.version>NEW</{artifactId}.version>

   to the

   <properties>

   block.
2. Replace the hardcoded

   <version>1.0.0</version>

   inside that dependency's block with

   <version>${order-api.version}</version>

   .

&&

cd <projectDir> && mvn clean package -DskipTests

• Never append

  2>&1

  ,

  >

  ,

  >>

  , or any other redirection to this command, and never pipe it into anything. The tool invocation already captures stdout and stderr in full, so redirection adds nothing — and it has a real side effect: the host IDE's command layer treats stream-redirection operators as unsafe and forces a manual approval prompt even for an otherwise-trusted command, which is exactly what this step must avoid.
• Do not add flags or bundle it with anything else — only the exact

  cd <projectDir> && mvn clean package -DskipTests

  shape above.
• Do not pause for user confirmation before running this. Rescaffolding after a version change is automatic in the real product — Anypoint Studio runs it the instant

  pom.xml

  changes, or the instant the user touches the Project Properties → API Specs tab — with no click-through step for the human. This skill mirrors that: run the command as soon as Step 8's edits are written, without asking.
• Wait for the full output before continuing.

• BUILD SUCCESS

  means APIkit has pulled in the updated spec versions and regenerated the corresponding flows. The project is now consistent with all changed API versions.
• If

  BUILD FAILURE

  occurs: automatically restore

  pom.xml

  to its pre-change state, then report the Maven error output verbatim so the user can investigate:

  Build failed — pom.xml has been restored to its previous state. Maven error: [output here]

mvn

• Property name is always

  {artifactId}.version

  — derived from the Maven

  artifactId

  of the API dependency, not a hardcoded tag like

  <apiVersion>

  .
• Never touch

  <version>

  (the Maven artifact version at the top of

  pom.xml

  ). That is a different field entirely.
• Always show available versions before applying a change. Never ask the user to type a version string — always fetch from Exchange and present the list first.
• Newer version callout only when one exists. Only show the "a newer version is available" message if the current version is not already the latest. Never show it otherwise.
• Same version is a no-op, not an error. If the user picks the already-applied version, say so and exclude that API from the change set. If all selections are no-ops, end without writing any files or running

  mvn

  .
• Batch all changes, then rescaffold once. Apply all pom.xml edits before running

  mvn

  . Never rescaffold between individual API updates — one

  mvn

  pass at the end covers all of them.
• Always back up pom.xml before writing. Hold the original content in memory at the start of every CHANGE operation. Restore it automatically on any failure — Exchange fetch error, mvn failure, or anything else that prevents successful completion.
• Rescaffold is mandatory after every CHANGE, and it is automatic — never a user prompt. Never declare the version updated without running

  mvn clean package -DskipTests

  and confirming

  BUILD SUCCESS

  . A version change without rescaffolding leaves the project inconsistent. Run it immediately after Step 8's edits with no confirmation question, matching how Anypoint Studio itself rescaffolds automatically on a pom.xml change or an API Specs tab edit.
• Never redirect the

  mvn

  command's output. No

  2>&1

  ,

  >

  ,

  >>

  , or pipes — the tool call already captures full stdout/stderr, and redirection operators can trip the host IDE's unsafe-command check and force an unwanted manual approval.
• One

  mvn

  invocation per response. Do not bundle it with file edits or other commands.
• No Anypoint CLI needed for pom.xml edits — use bash + Read/Edit tools only.

• jq

  is required by

  scripts/fetch_versions.sh

  for parsing Exchange JSON responses. If

  jq

  is not available on the machine running the script, it will fail — there is no separate manual fallback path; install

  jq

  rather than reimplementing the script's parsing inline.
• Version discovery is always one call to

  scripts/fetch_versions.sh

  covering every target API, never a per-API loop of raw

  anypoint-cli-v4

  invocations. See the Version Discovery procedure under Step 7b. The script runs

  exchange asset list

  (not version-anchored) in parallel across all target APIs, falling back to

  exchange asset describe

  's

  otherVersions

  field only per-API when

  list

  finds no match for that asset —

  describe

  's version list is anchored to the version you query with and has been observed to return empty/incomplete results when that version isn't the latest, which is exactly the situation CHECK and CHANGE query from.
• Multi-API version selection is one at a time. Show one API's version list, STOP, get the selection, then proceed to the next. Never show all lists simultaneously.
• Multi-turn interactive. At every STOP marker: print only the question as plain text, end your response, and wait. Do not run any tools until all required values are in hand.
• Skip-if-provided. Before the first STOP, extract any values the user already gave (project path, operation, target API, new version). At each STOP, skip it if the question is already answered.

• No

  .version

  properties found: The APIs may not be added to the project yet. Use Anypoint Studio's Project Properties → API Specs tab to add the API dependency first, which will create the property in

  pom.xml

  .

• mvn

  fails after version change: pom.xml is automatically restored. Check the Maven error for the root cause — the selected version may have an incompatible dependency or the Exchange asset may not be fully published.
• Multiple properties for the same API: If the same artifactId appears more than once under

  <properties>

  , update all occurrences to keep the project consistent.

• scripts/fetch_versions.sh

  rows come back with

  "source": "error"

  due to an auth error: Run

  anypoint-cli-v4 conf

  to verify credentials, or re-authenticate with

  anypoint-cli-v4 conf username <user>

  /

  anypoint-cli-v4 conf password <pass>

  . If

  ANYPOINT_BEARER

  is set in the environment alongside

  ANYPOINT_CLIENT_ID

  /

  ANYPOINT_CLIENT_SECRET

  , unset the client-credential vars — the CLI rejects calls when multiple auth methods are simultaneously active.
• A row comes back with

  "source": "describe-fallback"

  and a

  versions

  list that looks too short: Expected —

  exchange asset list

  found zero rows for that

  groupId

  /

  assetId

  , so the script fell back to the version-anchored

  describe

  lookup, which can under-report versions newer than the current one (see Version Discovery). Confirm the artifactId matches the Exchange

  assetId

  exactly (case-sensitive) and that the account is authenticated against the correct organization — a private asset published under a different org than the CLI session's selected org will not appear via

  list

  . As a next step, try

  anypoint-cli-v4 exchange asset list <artifactId> --output json

  manually (unfiltered) to see whether the asset shows up under a different

  groupId

  than what's in

  pom.xml

  .

• "source": "error"

  with no obvious auth/network cause: Both

  exchange asset list

  and the

  describe

  fallback failed for that specific asset. Re-run just that one API through

  scripts/fetch_versions.sh

  in isolation to see the underlying CLI error more clearly, or run the two

  anypoint-cli-v4

  commands by hand to inspect stderr directly.

• manage-global-configurations — Set up API AutoDiscovery (

  api.id

  ) and other global elements that pair with these API versions
• build-mule-integration — Build and package the Mule project after version changes