Commerce App Migrate

Migrate to App Management

Use this skill when the user wants to migrate an Adobe Commerce App Builder project from the Integration Starter Kit or Checkout Starter Kit to the new App Management approach using @adobe/aio-commerce-lib-app.

This skill orchestrates the full migration: detection → domain analysis → Q&A → config assembly → execution. It leaves the project fully migrated and ready to deploy.

Confirmation protocol

At each step marked [await]: end your turn immediately, output nothing further, and wait for the developer's reply before proceeding.

Autonomous mode: If invoked with --auto or --yes, or the context indicates an automated pipeline (no interactive terminal), skip all [await] points and proceed directly to the next step.

Doc-scan-only mode: If invoked with --doc-scan-only, skip all migration steps after the Analyzer. After Step 1 completes (Analyzer returns a ProjectSnapshot):

• If alreadyMigrated === false, output:

  --doc-scan-only requires the project to already be migrated to App Management.
  No app.commerce.config.ts (or .js) was found.
  
  Run /commerce-app-migrate (without --doc-scan-only) to perform the migration first.

  Then stop.

• If alreadyMigrated === true, apply any applicable Cross-cutting Warnings, then dispatch the Executor in doc-scan-only mode. No files are modified. Do not proceed to Steps 2–5.

Preflight Check

Before doing anything else, verify the current directory looks like an App Builder project. Check that ALL of these exist:

• app.config.yaml
• package.json
• At least one of: actions/ directory OR src/ directory OR actions-src/ directory (some projects compile TypeScript from actions-src/ to actions/; actions/ may be gitignored and absent in a fresh checkout)

If none of those pass, stop immediately and output:

This directory does not appear to be a Commerce App Builder project.
Expected to find: app.config.yaml, package.json, and an actions/ or src/ directory.

Please run this skill from the root of your App Builder project.

Do not proceed further if the preflight fails.

Step 1: Run Analyzer Agent

Dispatch the Analyzer agent (defined in ${CLAUDE_SKILL_DIR}/agents/analyzer.md) using the Agent tool. The Analyzer reads the current directory and returns a ProjectSnapshot JSON object (schema defined in ${CLAUDE_SKILL_DIR}/shared/schema.md).

Before printing the summary, check these early-exit conditions:

If alreadyMigrated === true: Output:

This project appears to already be migrated to App Management.
Found: app.commerce.config.ts (or app.commerce.config.js with ESM defineConfig)

Re-running migration would overwrite your existing configuration.
If you want to re-generate specific sections, please specify which
section to update: metadata / eventing / installation / adminUi / businessConfig

Then apply any applicable Cross-cutting Warnings (see subsection below).

Then dispatch the Executor agent (${CLAUDE_SKILL_DIR}/agents/executor.md) in doc-scan-only mode to produce documentation recommendations for the project:

• Pass mode = "doc-scan-only" to the Executor
• Pass the ProjectSnapshot JSON from the Analyzer
• Pass assembled config = null (no new config to write)

The Executor will scan README.md and env.dist against the existing app.commerce.config.ts and print the "Documentation recommendations" report without modifying any files.

Do not proceed to Steps 2–5 (domain agents, Q&A, config assembly, full execution) unless the developer explicitly requests a specific section update.

After the Executor prints the documentation recommendations, stop. Do not continue to the "Detected project:" summary block or the migration confirmation prompt below.

After the Analyzer returns, print a human-readable summary:

Detected project:
  Type:             <starterKitType> Starter Kit
  Auth mode:        <authMode> (<paas = "PaaS/OAuth1" | saas = "SaaS/IMS" | dual = "Both PaaS + SaaS" | unknown = "Unknown">)
  Action packages:  <comma-separated list of package names> (<count> packages)
  Onboarding:       <comma-separated list of script paths with purposes, or "none">
  Package manager:  <packageManager>

Migration will include: <list domains where confidence !== "none">

Apply any applicable Cross-cutting Warnings (see subsection below).

If hasMeshConfig === true, also append:

⚠ API Mesh configuration detected (mesh.json).
Mesh configuration cannot be migrated automatically and must be preserved manually.

Then ask:

Does this look correct? (yes / no — if no, describe what's wrong)
Press Enter or type "yes" to proceed automatically.

[await]

Handle corrections:

• If developer corrects starterKitType, update it in the ProjectSnapshot before proceeding
• If developer corrects authMode, update it
• Re-print summary with corrections and ask again until confirmed

Handle unknown starterKitType: If starterKitType === "unknown", check extensionPointsInUse:

• If "commerce/backend-ui/1" is present → this is an Admin UI SDK v1 extension. Proceed with starterKitType = "unknown" — the admin-ui-sdk domain agent will migrate it to v2. Print a note: "Detected Admin UI SDK v1 (commerce/backend-ui/1). Migrating to v2 (commerce/backend-ui/2)."

• If all confidence values are "none" AND extensionPointsInUse is empty: Output:

  This project does not appear to be based on the Integration Starter Kit
  or Checkout Starter Kit. No event consumers, webhooks, or Admin UI SDK
  patterns were detected.
  
  Migration can still generate a minimal app.commerce.config.ts with metadata
  only. Continue? (yes / no)

  If developer says no, stop. If yes, proceed with empty domain results.

• Otherwise, ask the developer:

  I couldn't determine which starter kit this project is based on.
  Is this an Integration Starter Kit or a Checkout Starter Kit?
  Options: [integration / checkout / adminUiSdk / custom]
  
  Not sure? See the documentation:
    • Integration Starter Kit: https://developer.adobe.com/commerce/extensibility/starter-kit/integration/
    • Checkout Starter Kit:     https://developer.adobe.com/commerce/extensibility/starter-kit/checkout/

  Update the ProjectSnapshot with their answer before proceeding.

Cross-cutting Warnings

Apply these whenever the corresponding field is set in the ProjectSnapshot, regardless of migration state. Append each matching block to whatever output is currently being built.

If openWhiskTriggers is non-empty, append:

⚠ OpenWhisk triggers detected (cannot be auto-migrated):
  <list each trigger description>
These scheduled triggers have no direct equivalent in App Management.

Read ${CLAUDE_SKILL_DIR}/shared/migration-warnings.md (OpenWhisk Triggers section) and present the replacement options to the developer.

If hasApiGateway === true, append:

⚠ OpenWhisk API Gateway routes detected (apis: blocks in runtime manifest).
These HTTP routes have no direct equivalent in App Management.

Read ${CLAUDE_SKILL_DIR}/shared/migration-warnings.md (API Gateway section) and present the migration options to the developer.

If hasSequences === true, append:

⚠ OpenWhisk sequences detected.
Action sequences have no equivalent in App Management.

Read ${CLAUDE_SKILL_DIR}/shared/migration-warnings.md (Sequences section) and present the refactoring guidance to the developer.

Step 2: Dispatch Domain Agents in Parallel

For each domain where confidence !== "none", dispatch the corresponding agent at the same time using the Agent tool (all in one parallel call):

Each agent receives:

• The ProjectSnapshot JSON
• Instruction to read the relevant files in the current directory using their own Read tools

Collect all returned DomainResult objects. Each has domain, configFragment, and unresolvedQuestions fields (schema in ${CLAUDE_SKILL_DIR}/shared/schema.md).

Step 3: Grouped Q&A

Collect all unresolvedQuestions from every DomainResult. If there are no unresolved questions across all domains, skip to Step 4.

Present all questions in a single grouped session (format defined in ${CLAUDE_SKILL_DIR}/shared/questions.md):

• Group by domain
• For questions with default values, show as confirmations: "(suggested: X)"
• Number questions sequentially across domains

[await]

For each answer received:

• Apply it to the configFragment of the corresponding DomainResult
• Use the question id to locate the exact field to update

If the developer accepts a suggested value (presses Enter / says "yes"), use the default.

Special case — skip-by-default questions (where default is "no"): These questions ask whether to include an optional section that was omitted from the configFragment because required data was missing (e.g. a provider direction with no deployed action package). Interpret the developer's reply as:

• "no" (or pressing Enter) → leave the section out of the configFragment; do nothing
• "yes" or any action string → add the section back; prompt for the runtime action name if not already specified in the reply, then apply it to the configFragment

Autonomous mode — auto-accepted defaults summary:

In --auto mode, after applying all question defaults, print:

── Auto-accepted defaults ────────────────────────────────────────
  The following questions were answered automatically (--auto mode):
  [  <domain> : <question id> = "<default value>"  ]
     ← one line per question that had an explicit default; omit entire section if no questions existed →

Omit this section entirely if there were no unresolved questions across all domains.