Phoenix to AX migration

Help the user migrate a Phoenix project to AX using the bundled helper. Handle setup and commands yourself; the user should only need to supply their source and destination details.

Requires Python 3.10 or later, shell access, and network access to Phoenix and AX. No particular coding agent, ax CLI, or AX Phoenix connector is required.

At the start, give the user this short roadmap before setup or tool calls:

1. Inspect Phoenix and count the supported data.
2. Show the proposed AX organization, space, and fresh destination names.
3. Let the user choose all or part of the data and accept or rename the AX project.
4. Migrate and verify the selected records.
5. Return direct links to the new AX project, datasets, and experiments.

Say that a typical small or medium migration takes about 5–20 minutes, while large exports or AX trace indexing can take longer. Do not promise a completion time. Keep setup narration to stage changes; do not make the user follow routine interpreter, dependency, or endpoint investigation.

Discover the source and gather missing details

Reuse details from the request and configured environment. Look for an explicitly provided configuration path and the current workspace's .env; do not search unrelated home-directory files. Credential collection is the first setup step when source or destination values are unavailable. Request the missing Phoenix host URL and project name directly. For secret keys, accept an existing local .env path or create a small owner-only credential-entry helper and give the user one exact command to run in a separate terminal; the helper prompts without echo and writes the local .env. This is ordinary missing input, not a permission or confirmation gate, so do not cite or quote the skill when requesting it. Do not ask the user to create or edit a file, find an AX space ID, or understand environment-variable names.