---
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'."
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, or upgrade an existing one. 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
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.
   - production hardening / testing / troubleshooting → `cometchat-<family>-{production,testing,troubleshooting}` on `angular-v5`, `react-native`, `android-v6`, `flutter-v6` (none on `react-v7`/`ios` — use `core` + its `docs-map.md`). `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.