cometchat-migrate-from-sendbird

Ground truth: the SENDBIRD side (what to look for) is baked in references/inventory.md + references/feature-map.md — confirm each hit by reading the user's code. The COMETCHAT side is never from memory: symbols come from the target family's skills + catalog, feature existence from that family's features.json, signatures from the docs via the family's -core/references/docs-map.md (Docs MCP first — RULES.md → Fetch discipline). REST pages live under DOCS_BASE = https://www.cometchat.com/docs.

Companion skills (read first)

• cometchat-<family>-core — the init → login → render the migrated app lands on. <family> is resolved in step 1; this skill ASSUMES that core and never restates its code.
• cometchat-<family>-components / -features / -calls / -push / -customization — pulled in only for the Sendbird features the inventory finds.

Use this skill when

The user asks to move an app off Sendbird: "migrate my app from Sendbird to CometChat", "replace Sendbird", "switch to CometChat", or "migrate my app to CometChat" when npx @cometchat/skills detect --json reports migrate_from with vendor sendbird. Stream/GetStream apps → cometchat-migrate-from-getstream. An app with BOTH vendors: run both skills, one after the other, into one report. Data only ("migrate only my data", "import my Sendbird users and messages", "don't change my code", or the app already runs on CometChat) → follow references/data-only.md INSTEAD of the workflow below: it writes and runs the data script and changes nothing else.

The single-prompt contract (read before step 1)

The migration request IS the approval (RULES.md → Competitor migration). Run every step below to the end in this one turn:

• Do not stop to ask. No onboarding plan/approve gate, no clarification questions. Where a companion skill would ask, take the default written here, and record it under Defaults taken in the report.
• Safety net instead of questions: in a git repo, first git switch -c cometchat-migration (carries any uncommitted work along; mention that in the report). Never commit, push, or rewrite history. No git → proceed and say so in the report.
• Removing Sendbird is the requested outcome — RULES.md's append-never-replace does not protect Sendbird code. It still protects everything else: touch non-chat code only to rewire it.
• Credentials: never ask, never provision. Reuse .cometchat/config.json or existing CometChat env values if present; otherwise write the family's env/settings file with clearly-named placeholders so the build still compiles, and make "add your CometChat credentials" action item #1. Never write a real key into a git-tracked file: check git ls-files <file> first. If the file is tracked, put real values in the untracked local variant the framework reads (Vite/Next .env.local, Android local.properties, …) and keep placeholders in the tracked file. Adding a tracked file to .gitignore does NOT untrack it. The server's REST API key only ever goes into an untracked file or the hosting env.
• Only three STOPs: (1) no Sendbird usage found → say so and hand to cometchat; (2) the app's platform has no family in this pack (Vue, Unity, .NET, …) → deliver the inventory + feature map as the report, change nothing; (3) the build was already failing before you started → record the pre-existing errors, migrate anyway, and label them as pre-existing.