cometchat-onboarding
Ground truth: this skill runs FIRST for every "add CometChat" request and produces NO integration code — its only outputs are (1) the shared plan artifact and (2) a scoped build directive to the framework core. Repo facts come from
npx @cometchat/skills detect --json(the authority) + READING THE REPO for the rest — NEVER memory, never the dashboard CLI (AUDIT-059). The archetype→capability map and plan template are inreferences/(loaded on demand). Credentials + implementation belong to the framework core (cometchat-<family>-core, family resolved frompeers.yaml). Draw the boundary at PLAN.
Use this skill when
Any first-contact "add CometChat" intent, on ANY stack: "add chat", "add cometchat", "add chat to my app", "add voice/video calling", "integrate cometchat". The router (cometchat) ALWAYS routes here FIRST — a mandatory gate. It runs before ANY framework core so the developer gets discover → understand → plan before a line is written. (An upgrade request — "upgrade my v6 UI Kit to v7" — is reconciliation, not onboarding; the router sends that straight to migration. And a re-entry on an already-integrated repo short-circuits: see §Re-entry.)
What this skill does — and only this (the four beats)
Run the four beats in order, as a CONSULTATIVE conversation (senior-engineer tone: recommend with a reason, surface trade-offs, never a blank form). Nothing is written to the user's code in ANY beat — the first write happens only AFTER beat 4's approval, inside the framework core. The final output is PRODUCTION-READY (the core's contract guarantees it).
The build model — UI Kit first, SDK per-feature fallback (NO "which approach?" question). A renderable app on a platform with a shipped UI Kit ALWAYS gets the UI Kit as its UI layer (fastest path to a production-ready surface). There is NO "UI Kit vs SDK" architecture choice to make. Instead, PER FEATURE: if the UI Kit has a component/prop for it → use the component; if it does NOT → call the platform's Chat SDK method directly (already installed under the UI Kit — init/login use it). The SDK is the FALLBACK for what the UI Kit doesn't expose (AI agents, campaigns, advanced/AI moderation, transient messages, bots, webhooks, …), looked up in the detected family's core
references/docs-map.md→ SDK docs (references/platforms.md). The ONLY exception: a backend/no-DOM/non-renderable context has no UI layer — there the SDK is the whole build; say so honestly.
1. DETECT everything (environment + the WHOLE current repo)
Run the detect probe (above), then READ THE REPO for the rest (on web: package.json deps/scripts, the lockfile, framework config files and source; on iOS: *.xcodeproj/*.xcworkspace, Package.swift, a Podfile as a signal only — references/platforms.md). Capture, framework-agnostically, degrading gracefully when a signal is absent (record it null, never guess):
- Framework & build:
framework·framework_version·bundler·router·ssr_strategy(ssr/csr/islands) ·env_prefix(VITE_/NEXT_PUBLIC_/…) ·package_manager(from the lockfile) ·language(TS/JS) ·project_name(plus mobile version fields for expo/RN/android/flutter). Non-web platforms have different fields — iOS, Android, React Native and Flutter each have a column inreferences/platforms.md. - App integration state: installed UI Kit +
version_conflict(a major other than the family's target — React v7, Angular v5, RN v5, iOS v5, Android v6, Flutter v6;peers.yaml) · existing CometChat integration · credential presence (an existing.cometchat/config.jsonor*_COMETCHAT_APP_IDenv). - App architecture (infer from source,
nullwhen absent): auth system (nextauth / clerk / firebase / auth0 / supabase / custom) · styling / design system (tailwind / css-modules / mui / styled-components / chakra) · state management (redux / zustand / mobx / recoil / context).
version_conflictSTOP still applies HERE. If detection shows a UI Kit major other than the family's target for an add request, STOP and surface it in the plan (reconcile first —RULES.md); do not hand off a build over a mixed-major repo. If CometChat is already wired for THIS major → Re-entry (below). A signal being absent is DATA, not a blocker. Missing auth ⇒ recommend the dev Auth-Key path + a note to add prod auth later; missing framework ⇒ record it and (per §Non-React) state the platform's core isn't built yet. Never fabricate a signal, never stall on one.