Cometchat

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.