cometchat-onboarding

Installation
SKILL.md

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 in references/ (loaded on demand). Credentials + implementation belong to the framework core (cometchat-<family>-core, family resolved from peers.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 in references/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.json or *_COMETCHAT_APP_ID env).
  • App architecture (infer from source, null when 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_conflict STOP 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.

Installs
1
GitHub Stars
162
First Seen
14 days ago
Security Audits