Stream - skill router + CLI

This skill picks the track from the user's input. Building (web + platform) and docs go to dedicated sub-skills; CLI tasks - querying data, configuring an app, onboarding, installing skills - are handled here (see Stream CLI below), since the getstream CLI underlies every track.

Read first: [RULES.md](RULES.md). Non-negotiable rules apply, including the Peer skills procedure. [peers.yaml](peers.yaml) (schema: [peers.schema.json](peers.schema.json)) is the single source of truth for peer names, Glob paths, install commands, and routing signals.

Install a missing peer on demand per its policy in peers.yaml (Glob its path, run its install command - getstream skills <name>), then invoke via the Skill tool or Read it inline. Don't call Skill before the Glob; it surfaces a confusing "Unknown skill" error. Do not stop after naming the track.

By task

Build or integrate Stream in a platform-specific app -> peer pack from [peers.yaml](peers.yaml) (check peer signals first)

• Match user input or cwd against each peer's signals (e.g. swift / swiftui / .xcodeproj -> stream-swift; react native / expo / stream video react native -> stream-react-native; unreal / .uproject / umg -> stream-unreal; unity / monobehaviour / .unitypackage -> stream-unity)
• All peers install on demand - install if missing, then route, no prompt
• An SDK/engine signal beats an OS-target signal. When both appear, the pack that owns the SDK wins: "build an Unreal chat app for iOS" is stream-unreal (not stream-swift), "a Unity game on Android" is stream-unity (not stream-android). ios / android / xcode / gradle describe the build target; unity / unreal / .uproject / .unitypackage / umg / flutter / react native describe the SDK. Same rule for flutter + ios.
• Name the engine for game requests. stream-unreal and stream-unity both claim generic game phrasing (in-game chat, game chat). An explicit engine token decides it; with neither engine named and no .uproject / ProjectSettings/ in the cwd, ask one short question ("Unity or Unreal?") rather than guessing. Note the capability difference that answer implies: Unity has Chat and Video, Unreal has Chat only.
• Peer signals take precedence over the web rows below. A request like "add a video call to my Expo app" or "scaffold a React Native app with Stream Video" matches stream-react-native, not the web packs - the platform token wins.

Build / enhance / audit / migrate a web app with Stream (React / Next.js) -> use the stream-react skill (the default web pack when no other platform signal is present)

• "build me a Chat/Video/Feeds app", "scaffold", "create a new ...", "add Chat to this app", "integrate Video", "drop Feeds into ...", "upgrade/migrate ... to vN" - and no platform signal (no react native, expo, swift, ios, android, etc.)
• React / Next.js tokens (stream-chat-react, @stream-io/video-react-sdk, useCreateChatClient, MessageList, ...) with a build/integrate verb also route here
• Covers Track A (scaffold, Steps 0-7), Track E (enhance an existing project), Track F (read-only best-practices audit), Track M (migrate/upgrade an SDK version)

Build with the framework-agnostic builder -> use the stream-builder skill only when the user names it explicitly ("use stream-builder", "/stream-builder")

• stream-builder is the generic builder being extended to other app kinds; web React/Next.js defaults to stream-react above

Audit/review an existing Stream Video integration against best practices (read-only - no scaffolding, no CLI, no build steps)

• Peer signal (react native / expo) -> stream-react-native; web / React / Next.js or no platform signal -> stream-react (Track F)
• Video only. The dedicated best-practices audit covers Stream Video. Chat/Feeds have no dedicated audit checklist yet - stream-react handles those requests with a general docs-based review and says so up front.
• Triggers: "audit/review my video integration", "is my video app production-ready?", "what am I missing before launch?"
• Routes here even when the request contains "check" - the audit intent takes precedence over the CLI "check {anything}" route below

Build or review a Feeds v2 -> v3 sync mapping -> use the stream-feeds-migration skill

• "what mapping do we need?", "set up our v2 to v3 migration", "review our v3sync mapping", "why did the migrated activity lose its text/attachments/comments?"
• Produces the mapping config object by sampling the v2 app's own activities and reactions - it does not build or change an app
• Needs the v2 app's API key and secret in the environment; see the skill's Step 1 and [RULES.md](RULES.md) > Secrets

Query Stream data or run a CLI command -> handled here (see Stream CLI below)

• "list calls", "show channels", "any flagged", "find users", a literal getstream command, or "install the CLI" / "set up stream"

Search Stream SDK documentation -> use the stream-docs skill

• "docs", "documentation", explicit SDK token (Chat React, Video iOS, Feeds Node, Moderation)
• "how do I ... in <framework>", "how does <hook/component/method> work?", "what does <SDK thing> do?"
• No CLI needed - answers come from getstream.io with citations

Pick a track

Scan the user's input for the signals below in order. The classifier is deterministic - no probes, no fetches, no CLI checks at this stage.

Onboarding carve-outs. stream-docs answers from documentation only - no shell, no project inspection. Read-only / local-only tracks also skip onboarding: a platform pack's audit track (e.g. stream-react Track F) and migrate track (e.g. stream-react Track M) only inspect/edit local files and the live docs - they do not provision orgs/apps or call getstream api, so they need no CLI onboarding. Only build/integrate work (scaffold a new app, add a product to an existing one) runs getstream init before doing real work.

Docs vs platform packs. A pure how-to or method-lookup question about an iOS/Android/etc. SDK symbol stays in stream-docs - don't pull in a platform pack for a documentation answer. Platform packs (e.g. stream-swift) are for building or integrating - scaffolding projects, wiring packages, generating views.

React framework scope. stream-react scaffolds (Track A) a Next.js app. For enhance / audit / migrate on a non-Next.js React project (Vite, CRA, Remix, TanStack Start, etc.) stream-react still owns it - the Stream SDK wiring is identical - but the agent must adapt the Next.js-specific bits: the server-side token route lives in the project's own backend (not a Next.js /api route), and verification uses the project's build command (npm run build), not next build. Never assume Next.js APIs on a non-Next project.

Disambiguator. If the input fits more than one row (typically operational verb + how-to phrasing), ask one short question and wait. Don't probe before the answer:

Want me to look up the SDK method (docs) or run it now via CLI?

After the answer, route as if the user had given that signal directly.

Bare /stream with no args. Render the menu under "Quick navigation" verbatim, then wait for input. No shell execution, no probing, no install.

Stream CLI

CLI tasks - querying data, configuring an app, onboarding, installing skills - are handled here; the getstream CLI is the substrate every track uses. Run getstream -h for the command list and getstream <command> -h for usage, and follow what the CLI prints. Safety and posture (no guessing, confirm before writing): [RULES.md](RULES.md) > CLI safety. If getstream isn't installed, ask the user to install it from https://getstream.io and wait - never fetch or run an install script.

Sendbird data migration (shared, language-agnostic)

A platform pack's Sendbird migration covers the code/SDK swap (e.g. stream-swift sendbird-migration.md, stream-react sendbird-migration.md). Moving the data (users, channels, message history, reactions) is server-side and SDK-independent, so it lives once, here, in [sendbird-data-migration.md](sendbird-data-migration.md) - any platform pack hands off to it. It picks a strategy (hard switch / uni-directional / bi-directional sync), exports from Sendbird, builds the JSONL import file, validates, and imports via the getstream CLI (CreateImportURL -> upload -> CreateImport -> GetImport). Read it when a code migration finishes and the user wants their history brought over.

Quick navigation

For a bare /stream (and whenever the user wants to pick a skill directly), output the block below verbatim - keep the Core / Platform SDKs split, the examples, and the closing line - then wait:

Stream - Chat - Video - Feeds - Moderation. Tell me what you want, or pick a skill directly:

Core
- /stream-react - scaffold, enhance, audit, or migrate a React / Next.js web app with Stream (the default for web) - e.g. "build me a chat app"
- /stream-docs - search live SDK docs, with citations - e.g. "how does useChannel work?"
- /stream-builder - the framework-agnostic builder (web defaults to /stream-react; pick this only if you name it explicitly)
- /stream-feeds-migration - build the v2 -> v3 Feeds sync mapping from your app's live data - e.g. "what mapping do we need for our app?"

Platform SDKs
- /stream-swift - Swift - SwiftUI - UIKit - iOS
- /stream-android - Android - Jetpack Compose - Kotlin
- /stream-react-native - React Native - Expo
- /stream-flutter - Flutter - Dart
- /stream-unity - Unity Engine - C# (Chat + Video)
- /stream-unreal - Unreal Engine - C++ - Blueprint (Chat only)

Or just ask - query data or run getstream commands directly: "list my channels". New to a skill? Just describe the task and I'll install the right one automatically.

The closing line is load-bearing: typing an uninstalled slash command errors with "Unknown skill" before this router runs, so natural-language description is the only dead-end-proof path - it routes here and the missing peer is installed per [peers.yaml](peers.yaml). Keep this menu in sync with peers.yaml: every peer there appears here under Core or Platform SDKs, and new platforms get a bullet under Platform SDKs when their entry is added.

Hand-off

See preamble: install if missing, invoke via Skill tool, don't stop. Cross-cutting rules in [RULES.md](RULES.md) apply to every sub-skill, including Cross-track follow-ups (offer, don't auto-execute, the natural next action across track boundaries).

Support

If the user asks for support or how to contact someone, direct them to getstream.io/contact.