getstream/agent-skills/stream-unity

Stream Unity - docs orchestrator for Unity Engine

Chat and Video. There is no Stream Feeds SDK for Unity (/activity-feeds/docs/unity and https://getstream.io/cli/docs/activity-feeds-unity.md both 404). If the user asks for activity feeds in Unity, say so up front and offer the alternatives (the REST/server API driven from your backend, or a platform SDK on a companion app) rather than inventing an API.

These are two separate SDKs, and almost nothing is shared. Different repos, different install mechanisms, different maturity, different supported platforms, different docs quality. There is no combined client, no shared AuthCredentials type (StreamChat.Libs.Auth.AuthCredentials and StreamVideo.Libs.Auth.AuthCredentials are distinct types in distinct assemblies), and connecting a user to one does not connect them to the other. Treat "add chat to my Unity call app" as two integrations that happen to share an API key.

Neither SDK ships reusable UI. Both ship a sample project you import and read, not a component library you drop in. Every chat bubble, channel row, participant tile, and call button in the user's game is code you write. Say this before promising a screen, and run `ui.md` when building one.

This skill orchestrates: it gates the request against product, platform, and feature support, routes to the exact docs page, fetches it live, and applies it - while carrying the Unity-specific knowledge the docs do not have (the client's hidden DontDestroyOnLoad runner, the track-binding requirement, IL2CPP stripping, and the player settings that decide whether a build works on device at all).

Rules (read once per session): `RULES.md` - non-negotiable rules + Unity pitfalls. Read before writing any code.

Step 0: Three gates, before any code

Resolve all three from the user's words plus a read-only probe. Each one can turn "here is the code" into "that is not possible", so none is optional and none belongs in a runtime failure later.

Gate 1: product (and whether it exists for Unity)

Gate 2: Unity version and build target (the Video SDK is the constraint)

Probe rather than ask:

bash -c 'echo "=== UNITY VERSION ==="; cat ProjectSettings/ProjectVersion.txt 2>/dev/null; \
echo "=== UPM MANIFEST ==="; cat Packages/manifest.json 2>/dev/null; \
echo "=== STREAM CHAT PRESENT ==="; find . -maxdepth 5 -type d -name "StreamChat" -not -path "*/Library/*" 2>/dev/null; \
echo "=== STREAM VIDEO PRESENT ==="; grep -n "io.getstream.video" Packages/manifest.json 2>/dev/null; \
echo "=== SCRIPTING BACKEND / TARGET ==="; grep -nE "scriptingBackend|AndroidTargetArchitectures|apiCompatibilityLevel|managedStrippingLevel" ProjectSettings/ProjectSettings.asset 2>/dev/null | head -20'

Unity 6 plus Chat carries one hard version floor: Chat v5.4.0 fixed an IL2CPP build crash on Unity 6000.0.x (a KeyNotFoundException in IL2CPP's vtable builder). Never pin Chat below v5.4.0 on Unity 6.

Gate 3: feature support (say no in the plan, not in a compile error)

Chat - not implemented client-side as of v5.7.0. If the request needs one of these, say so before writing code:

• Guest and anonymous users (ConnectGuestUser / anonymous connect do not exist) - this blocks the usual read-only-spectator livestream pattern
• Channel archiving, channel pinning (both are per-member fields with no client API)
• Draft messages, message reminders and bookmarks, location sharing
• User blocking (BlockUser / UnblockUser / blocked-user list)
• On-demand message translation (auto-translation on a channel does work)
• Setting invisible or a custom status at connect time (MarkInvisibleAsync after connect works)
• Unread-mentions-per-channel count; pagination of reactions, watchers, and pinned messages via their dedicated endpoints
• Client-level standalone file upload (channel-level UploadFileAsync / UploadImageAsync work)
• Poll answers (text comments) and querying poll votes

Video - not implemented client-side as of 0.11.0:

• Publishing your own screen share. You can receive a remote participant's ScreenShareTrack; there is no API to start sharing from Unity. The repo README's feature list says "Screensharing" and means the receive half.
• Any incoming-call / ringing event. call.ring is handled internally and never surfaced (the source literally reads //StreamTodo: expose CallRinging event?). ring: true and AcceptAsync / RejectAsync exist, but the callee has no client-side signal that a call arrived - you need your own push handling.
• Push device registration. CreateDeviceAsync exists only on an internal API and the low-level client is only reachable through an internal interface. Register devices from your backend.
• A public calling-state machine. CallingState is internal; use client.CallStarted / CallLeaving / CallEnded plus client.ActiveCall.
• Video-side chat integration, deeplinking, picture-in-picture, noise cancellation, transcription control, and HLS/RTMP viewer UI have no Unity docs page. GoLiveAsync / StopLiveAsync / StartHLS / StopHLS / StartRecordingAsync / StopRecordingAsync do ship on IStreamCall - they are undocumented, not absent. Read the interface (rung 2 below) and say where you got it.

Anything server-side stays server-side for both SDKs: call types, channel types, permissions and roles, webhooks, push templates and providers, recording/transcription config, data retention, imports. The client never holds the API secret.

The docs convention - and the per-product coverage reality

Every Stream docs page has a Markdown twin: take the page URL, drop the trailing `/`, add `.md`.

https://getstream.io/chat/docs/unity/query-channels/   ->   https://getstream.io/chat/docs/unity/query-channels.md
https://getstream.io/video/docs/unity/basics/quickstart/ -> https://getstream.io/video/docs/unity/basics/quickstart.md

Always fetch the .md variant - clean Markdown, verbatim code, no page chrome. Live indexes that list every page:

The two trees fail in opposite directions, so the caveat is different per product.

Chat: the code is real, but not every C# block is Unity C#

The Chat Unity tree is well maintained. Roughly 40 of its 53 pages carry a genuine Unity code tab, and where a feature is missing the page usually says so outright:

// This feature is not yet available in the Unity SDK.

The one trap is the fence label, and it is easy to miss because both say C#. These pages mix two different SDKs:

label="C#" snippets are IStreamChannel-shaped only by coincidence: chat.SendMessageAsync("channel-type", "channel-id", request) looks close enough to channel.SendNewMessageAsync(request) to paste by mistake, and then the fix is "add the API secret to the client", which is exactly wrong. Pages that are entirely server-side C# (archiving-channels, pinning-channels, location-sharing) document features the Unity SDK does not have at all - see Gate 3. Pages that are mixed (send-message, query-channels, channel-members, moderation, message-delivery-and-read-status) do have a Unity path; take the label="Unity" block and ignore the rest.

message-delivery-and-read-status is the sharpest case: read state is fully implemented (channel.MarkChannelReadAsync, channel.Read, channel.MarkChannelAsUnreadAsync, message.MarkMessageAsLastReadAsync) and the page carries no Unity block at all. Get the API from the interface, not from the page's server-side C#.

Two more Chat-tree facts worth knowing before you fetch:

• The CLI index is incomplete. 15 more paths resolve under /chat/docs/unity/ - but they 301-redirect to platform or Node docs (push-devices -> /docs/platform/push-devices/, chat-permission-policies -> /chat/docs/node/..., update-users -> /docs/platform/users/) and their /chat/docs/unity/<page>.md twins 404. Fetch the .md at the redirect target instead, and expect no Unity code there. `docs-map.md` lists them with their real URLs.
• The sample-project link in the docs is broken. The introduction page links github.com/GetStream/stream-chat-unity/tree/main/...; the repo has no `main` branch. Use develop (or a version tag).

Video: the code is trustworthy, the tree is just small

All 22 Video Unity pages are Unity-first C# - there is no server-SDK mixing and no JavaScript. The problem is absence: no page covers going live, backstage, HLS, RTMP, recording control, ringing flows, or screen-share receive, even though most of those ship on IStreamCall. When a Video request has no page, that is normal - go to rung 2 and read the interface.

Source-of-truth ladder