cometchat-onboarding

• SKILL.mdcore · 22,300 bytes
• references/archetypes.mddoc · 6,467 bytes
• references/calling-first.mddoc · 9,749 bytes
• references/not-in-this-pack.mddoc · 2,661 bytes
• references/plan-artifact.mddoc · 8,254 bytes
• references/platforms.mddoc · 8,629 bytes

> **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.

<!-- onboarding is a platform-NEUTRAL journey skill (like the cross-family a11y/i18n): no per-platform Companion block. Its "companion" is whatever framework core the plan names on hand-off. -->

## 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):