/migrate-integration

Migrate an integration from $ARGUMENTS to a Prismatic Code Native Integration.

Generate CNI TypeScript code during the analysis phase — that's the build phase's job Pre-decide which Prismatic components exist — the standard build flow searches live Use prismatic-tools synthetic commands for parsing and analysis Run Python scripts directly or call parsers via Bash If `$ARGUMENTS` is blank, ask the user for the path to their export files. Run: `prismatic-tools detect-platform ` If platform is "unknown", inform the user that only Boomi and Cyclr are supported. Derive session name from the export directory basename. Run: `npx tsx ${CLAUDE_PLUGIN_ROOT}/scripts/run.ts prerequisites --type integration` This creates the session directory. Run: `prismatic-tools parse-export --platform --session ` This produces parsed-export.json in the session directory. If --summary mode is useful for initial overview, run with --summary first, then full. Output an `` tag to delegate analysis to the migration-analyzer agent. The main conversation handles the handoff (see CLAUDE.md orchestration).

```
I need the migration analyzer to build the integration schema.
<analyzer-request>
Analyze the {platform} export for session '{session-name}'.
Session directory: {session-dir}
The parsed export is at: {session-dir}/parsed-export.json

Follow your full workflow:
1. Read the parsed export from the session
2. Load the {platform}-migration skill for platform-specific concepts
3. Build the standard integration schema (migration-schema.json)
4. Generate flow diagrams if Boomi
5. Present the migration plan with confidence scores

Write migration-schema.json to: {session-dir}/migration-schema.json
</analyzer-request>
```

Then STOP and wait for the analyzer's response via SendMessage.
After it returns, present the migration plan to the user.
Use AskUserQuestion: "Here's the migration plan. Ready to proceed?"
WAIT for user approval before continuing.

Run: `prismatic-tools schema-to-answers --session --schema /migration-schema.json` This pre-populates requirements.json with answers derived from the schema. The output lists what was pre-populated. Run: `prismatic-tools update-tasks --session --actionable` Most items will be in `mark_completed` (pre-populated from schema). Remaining items are component search, connection setup, and any decisions the schema couldn't resolve.

If `<draft-proposal>` is emitted, present the full proposal to the user.
Otherwise, walk through remaining questions one at a time per the standard requirements flow.

When find-components returns a result, record the FULL JSON object — not a bare string key When find-components returns empty, ask the user: "No Prismatic component exists for [system]. Options: 1) Research the API and use direct HTTP calls, 2) Build a custom component first" Silently decide to use HTTP calls — the user must confirm If the user chooses "build custom component": 1. Record *_component=none for that system (activates api_docs_url question) 2. Ask for or use API docs URL from migration schema 3. Spawn external-api-researcher to analyze the API 4. WAIT for researcher to complete 5. Launch /build-component for that system using the research 6. After component is published, re-run find-components — now it exists 7. Record the real component object and continue the connection flow Launch /build-component without running the API researcher first If the user chooses "direct HTTP calls": 1. Record *_component=none (activates api_docs_url question) 2. Ask for or use API docs URL from migration schema 3. Spawn external-api-researcher to analyze the API 4. WAIT for researcher to complete — research informs code generation 5. Continue with HTTP component for connections

Hand off to the standard `/build-integration` workflow from here.
The session is pre-populated, components are searched, code-plan will emit
`<migration-context>` automatically when `migration-schema.json` exists.
Follow the build-integration command's procedure from the scaffold step onward.

After the build-integration flow completes deploy and test, spawn the `migration-reviewer` agent to validate the generated code against the original export:

"Review the generated CNI code against the migration schema.
Project directory: {project-dir}
Migration schema: {session-dir}/migration-schema.json

Run your full 8-point review checklist. Compare field names, endpoints,
transformations, and script translations against the original export data.
Output a <review-result> XML report."

Parse the `<review-result>` output:
- For `fixable="yes"` findings: apply the fixes, rebuild, and redeploy
- For `fixable="needs-verification"` findings: present them to the user
- If no findings: report clean migration