Cometchat

---
name: cometchat
description: "Entry point for any CometChat task on any platform. Detects the framework + UI Kit version (React, Angular, iOS, Android, React Native, Flutter), then routes to that family's skills — for a NEW integration or a change to an existing one. Triggers: 'add chat', 'add cometchat', 'add chat to my app', 'add calling', 'change something in my chat', 'my chat is already set up', 'add a feature to the chat', 'add chat to my android app', 'integrate cometchat android', 'add chat to my ios app', 'integrate cometchat ios', 'add chat to my swift app', 'migrate my app to cometchat', 'migrate from sendbird', 'migrate from getstream / stream', 'replace sendbird / stream chat with cometchat'."
license: "MIT"
metadata:
  author: "CometChat"
  version: "1.1.0"
  tags: "cometchat router entry react angular ios swift android flutter react-native chat"
---

> **Ground truth:** routing is `peers.yaml` (data); shared rules are `RULES.md`. This is a THIN classifier — detect + dispatch only. No workflows, credential logic, or component detail here; those live in `cometchat-onboarding` + the resolved family's skills + `RULES.md`.

## Use when
User wants to add CometChat to a project, upgrade an existing one, or migrate one off Sendbird / Stream. Triggers: "add chat", "add cometchat", "add voice/video calling", "upgrade my v6 UI Kit to v7", "add chat to my iOS app", "add chat in Swift", "upgrade my v4 iOS UI Kit to v5".

## If you cannot find it here — FETCH, never guess
This applies to EVERY agent and EVERY install mode, whether or not a row above matched.

- **Need a CometChat API that is not in the table above?** Open the resolved family's `core` skill -> `references/docs-map.md` and follow it to the docs page. Append `.md` to any docs URL for the clean Markdown twin.
- **NEVER `grep node_modules`. NEVER read `*.d.ts`.** They expose internal, unsupported and version-drifting surface that is not the public API — code written from them breaks on the next kit release, and often does not work at the version in front of you either.
- **NEVER answer from training memory.** The UI Kit API changes across majors.
- **If the docs genuinely do not cover it, SAY SO and stop.** A truthful "the docs do not document this" is a correct answer. Inventing a plausible API is not.

Full text: `RULES.md` -> "Fetch discipline".

## Do only this
0. **Migration OFF Sendbird or Stream (GetStream) → straight to that vendor's skill. No onboarding.** Triggers: "migrate my app to CometChat", "migrate / switch / move from Sendbird|Stream|GetStream|Twilio", "replace Sendbird|Stream Chat with CometChat". Run `npx @cometchat/skills detect --json`: each `migrate_from` entry names the vendor's `skill` (`cometchat-migrate-from-{sendbird,getstream,twilio}`, routed in `peers.yaml` `migrations:`); a vendor the user NAMES counts even if detect misses it. That skill runs the whole migration in one prompt (detect → replace → remove what CometChat lacks → verify → final list of removed features) and lands on the `<family>` core itself. "Migrate to CometChat" with neither vendor detected nor named → say no Sendbird/Stream usage was found, then continue at rule 1/2. **Data-only** ("migrate only my data from Sendbird|Stream", "import my <vendor> users/messages into CometChat") → the same vendor skill in its data-only mode (`references/data-only.md`): the named vendor is enough (no code detection needed), and it changes only `scripts/cometchat-migration/` and writes the `COMETCHAT_MIGRATION.md` report. Twilio has no data-only mode: say so and offer the full migration, and never change app code on a data-only request. A plain "add chat" on a repo where `migrate_from` is set → onboarding, which names the vendor in its plan and offers the migration.
1. **ALREADY INTEGRATED + a specific request → go STRAIGHT to the task skill. Do NOT run onboarding.** Run `npx @cometchat/skills detect --json` — the authority: `existing_cometchat: true` means a CometChat UI Kit/SDK dependency is present (`@cometchat/chat-uikit-*`/`chat-sdk-*`/`calls-sdk-*`, `com.cometchat:*`, `cometchat_*`, `CometChatUIKitSwift`). If it can't run, READ the repo for that same dependency. A `.cometchat/` folder is NOT evidence — the installer and the dashboard CLI create it. (The dashboard CLI `@cometchat/skills-cli` has no `detect`; `RULES.md` → "The CLI is a dashboard/API client only".) Present ⇒ the plan/approve journey has already happened. Treat the ask as a TASK, not an integration: resolve `<family>` (rule 4), pick the `<type>` from the map in rule 5, open that skill directly. This is the COMMON case in a live app — "change my avatar", "add a logout button", "add polls", "restyle the bubble", "my custom view isn't showing" — and none of it is onboarding. Routing it through the gate re-asks questions the user already answered; having NO branch for it is worse, because the agent then falls out of the flow and guesses from `node_modules` (AUDIT-106).
2. **First-contact "add CometChat" (add chat / add calling / integrate cometchat) → ALWAYS route to `cometchat-onboarding` FIRST.** This is a mandatory gate, not optional: onboarding runs the framework-agnostic DISCOVER → UNDERSTAND → PLAN journey (whole-repo detect, intent questions with recommended defaults, the full plan artifact, the modify/approve gate) BEFORE any framework core. It then hands a scoped build directive down to the framework core. Do NOT route straight to a `-core` skill for a first-contact add request — onboarding gates it. (Onboarding short-circuits on an already-integrated repo — see its Re-entry section.)
3. **Upgrade request** ("upgrade v6 to v7", "v4 to v5", "v5 to v6 Android") is reconciliation, NOT onboarding → route straight to `cometchat-<family>-migration` (that IS the reconciliation). The `version_conflict` STOP still applies to *add* requests; onboarding surfaces it in the plan and reconciles before hand-off.
4. **Resolve `<family>` ONCE, from the project — never assume.** Every skill file is named `cometchat-<family>-<type>`. Take `<family>` from the `dir_prefix` of the matching row in `peers.yaml` — the detect probe's `framework`, else its `detect_signals` against what you READ (`package.json`/lockfile, `angular.json`, `settings.gradle(.kts)` + `app/build.gradle(.kts)`, `pubspec.yaml`, `*.xcodeproj`/`*.xcworkspace`/`Package.swift`): React web → `react-v7`; Angular (`angular.json` detected) → `angular-v5`; React Native / Expo → `react-native`; Android (`settings.gradle(.kts)` detected) → `android-v6` (a `calls-sdk-android`-only / "calling from scratch" ask → the `android-calls` row, `cometchat-android-v5-calls-sdk`); Flutter (`pubspec.yaml`) → `flutter-v6`; iOS → `ios`. **Routing a project to another family's skill is a defect** — a React Native app sent to a `react-v7` skill gets web-only APIs that do not exist on native (no `UIKitSettingsBuilder`, `login` takes an object, callbacks are `on*Press` not `on*Click`), and the reverse is equally broken. If no row matches the detected framework, say the platform is not in this pack — do NOT substitute the nearest one.
5. **On approval, onboarding hands off to `cometchat-<family>-core`.** It pulls in additional SHIPPED skills ONLY as the approved plan names them (progressive disclosure). Route to the `<type>` below, always under the resolved `<family>`:
   - components → `cometchat-<family>-components`
   - placement/layout → `cometchat-<family>-placement`
   - theming/branding/custom message types → `cometchat-<family>-customization`
   - features (search, receipts, reactions, AI, moderation, …) → `cometchat-<family>-features`
   - voice/video calling → `cometchat-<family>-calls`
   - push notifications → `cometchat-<family>-push` (THIN + docs-first — fetches the notifications docs; live delivery is a manual device check)
   - upgrade an existing major → `cometchat-<family>-migration`
   - framework glue (env, SSR/islands, routing, native build config) → `cometchat-<family>-patterns` on `react-v7` (Vite/Next/CRA/React Router/Astro), `angular-v5`, `flutter-v6`. `react-native`: the split pair `cometchat-react-native-expo-patterns` (Expo) / `cometchat-react-native-bare-patterns` (RN CLI/bare) — pick by whether `expo` is a dependency. iOS and Android have NO `patterns` skill.
   - **analytics / metrics / observability / monitor / dashboards / send events to Datadog·Segment·BigQuery** → `cometchat-analytics`.
   - **audit / review / health-check an EXISTING integration** → `cometchat-audit` (read-only; routes fixes to the owning skills).
   - **accessibility / WCAG / screen-reader / keyboard** → `cometchat-a11y`. **localization / i18n / translate the UI / RTL** → `cometchat-i18n`. (Cross-family, installed for every family.)
   - **enterprise security / SSO / RBAC / session revocation / multi-tenant** → `cometchat-security` (cross-family: server + access-control model; client login stays in the family core/production). **data residency / GDPR / retention / audit logs / eDiscovery** → `cometchat-compliance`. **on-prem / self-host / private cloud** → `cometchat-self-host`. **moderation / safety / profanity / image moderation** → `cometchat-moderation`. These four are installed for every family (like onboarding).
   - production hardening / testing / troubleshooting → `cometchat-<family>-{production,testing,troubleshooting}` on every UI family (`react-v7`, `angular-v5`, `react-native`, `ios`, `android-v6`, `flutter-v6`). `events` → `android-v6`, `flutter-v6`.
   - **`react-native` only** — `cometchat-react-native-sdk` (the method→contract fallback map; kit v5 removed the detail/management screens, so SDK calls are on the main road for RN, not an escape hatch).
   - **`android-v6` only** — cohort-split skills (pick cohort from gradle files: `kotlin-*` = XML Views, `compose-*` = Jetpack Compose): `cometchat-android-v6-{kotlin,compose}-{components,placement,customization}`; also `builder-settings`, `extensions`. Headless Chat SDK v5 (build-your-own-UI) → `cometchat-android-v5-sdk`.
   - **Headless Calls SDK v5** (from-scratch calling, NO UI Kit — meet-style or 1:1 ringing; via onboarding's calling-first tree) → `cometchat-js-v5-sdk` (web) · `cometchat-react-native-v5-sdk` · `cometchat-ios-v5-sdk` · `cometchat-android-v5-calls-sdk` · `cometchat-flutter-v5-sdk`. Not installed? `npx @cometchat/skills add --family <js|react-native|ios|android|flutter>-calls` adds it alongside the UI Kit skills. The prebuilt call UI stays `cometchat-<family>-calls`.
   - **iOS** integrates via **SPM**: CocoaPods is winding down (spec repo going read-only), so a Podfile is a DETECTION signal only, never an install instruction.
   - **NOT in this pack — do NOT route (use the "not in this pack" posture):** the headless **JS Chat SDK** has no separate skill (its methods are the per-feature fallback INSIDE core). If the approved plan needs a capability with genuinely no shipped skill, say so, offer CometChat's docs + the plan as a spec, and steer to the shipped path — never route to a skill that isn't in the pack.
   For a framework with no core yet (Vue today), onboarding still delivers the plan and states the platform's core isn't built. **Angular IS built** — `@angular/core`/`angular.json` matches the `angular` row in `peers.yaml`; route to that row's `dir_prefix` + `core` and the rest of its family (v5 kit, catalog-verified vs 5.1.0); never tell an Angular user their platform is unsupported.
6. Do not write integration code here — onboarding plans it, the family's skills build it.

Routing data: `peers.yaml`. Rules: `RULES.md`. This file stays small on purpose.