CometChat Skills now supports voice and video calling. The cometchat-calls skill is a new top-level skill alongside the existing chat skill. Run /cometchat add voice and video calls to my app in your agent, and it handles the full calling integration for your framework: right SDK, right architecture, right configuration.
This works across web (React, Next.js, React Router, Astro), React Native (Expo and bare), Angular, Android (CometChat UI Kit V5 and V6), iOS, and Flutter
Why does this matter to you as a developer?
Adding calling to an app involves more moving parts than adding chat. There's the Calls SDK to install, a calling mode to pick before you write a line of code, native permissions to configure, VoIP push to wire up for mobile, and platform-specific setup that varies significantly between iOS, Android, React Native, and Flutter.
Most of that complexity is not in the CometChat APIs themselves. It's in the scaffolding decisions that have to be made correctly before you start. Pick the wrong calling mode and you're rebuilding your call flow mid-integration. Install the Chat SDK in a session-only flow and you've added two initialization failure modes for zero benefit.
The Calling Skills encode those decisions. The agent asks the right questions first, detects your project state, and scaffolds the right thing for your specific setup. The scaffolding decisions that typically cause mid-integration rework are resolved before the agent writes a line of code.
Key features and capabilities
Six platform families, covered by seven platform-specific calling skills. The dispatcher routes to cometchat-react-calls, cometchat-angular-calls, cometchat-native-calls, cometchat-android-v5-calls, cometchat-android-v6-calls, cometchat-flutter-v5-calls, cometchat-flutter-v6-calls, and cometchat-ios-calls. Each skill carries framework-specific rules covering dual-SDK setup, VoIP push, foreground service lifecycle, permissions handling, and hangup teardown.
Two calling modes, resolved upfront. Before generating any code, the agent asks whether you need Ringing or Session mode.
Ringing mode is for traditional calling flows. One user calls another, the device rings, the recipient accepts or declines. This uses CallKit on iOS and ConnectionService on Android, and requires VoIP push for background wake.
Session mode is for link-driven meeting rooms. Both participants join via a shared session ID. No ringing surface, no VoIP push, no telecom integration.
These are different SDK APIs with different file shapes and different native requirements. Asking upfront avoids costly mid-integration rework.
Standalone vs additive, detected automatically. If your project already has the Chat SDK and UI Kit installed, the agent adds calling on top. If you're building session-only calling from scratch, it scaffolds only the Calls SDK with no Chat SDK and no unnecessary dependencies.
17 reference documents per platform. Each calling skill ships with references covering ringing integration, session flows, custom call UI, group calls, in-call chat, picture-in-picture, screen share and recording, VoIP push end-to-end, and migrating from v4 to v5. The agent pulls from these based on what you're building.
verify --calls expands to 23 checks. Run npx @cometchat/skills verify --calls after scaffolding to catch common integration issues before they become runtime problems: missing peer dependencies, incorrect container sizing in web session mode, Chat SDK installed in a session-only project, and more.
What's interesting about the tech
The dispatcher follows a fixed step sequence before generating any code. It confirms your CometChat credentials, detects your framework, asks Ringing vs Session, determines whether it's a standalone or additive integration, and then generates a plan. This ordering is intentional. The calling mode determines which SDK combination gets installed, which native configurations get added, and what the file structure looks like. Resolving it at Step 3 means every subsequent scaffolding decision follows from a known starting state.
The standalone vs additive distinction has a specific technical reason behind it. In session-only flows, installing the Chat SDK alongside the Calls SDK introduces an initialization race. The Chat SDK needs to log in before the Calls SDK initializes, and that sequencing adds failure modes when you're not using chat at all. The skill enforces Calls SDK only for session-only projects, and verify --calls flags violations.
On mobile, the multi-listener hangup guard is worth knowing about. The v5 Calls SDK fires three termination listeners in sequence on every hangup. Handling each independently on Flutter or Android causes navigation crashes or race conditions during composable exit transitions. The skills funnel all three through a single guarded helper with a flag, so the navigator pops once, cleanly.
Reference links
Nivedita Bharathy
Product Marketing Specialist , CometChat