Read first (every session): Glob

../stream/SKILL.md

. If the path is empty, install with

npx skills add GetStream/agent-skills --s stream -y

(no confirmation, just run). Then Read

../stream/RULES.md

- it includes a Peer skills table for installing/invoking any other pack skills on demand.

getstream.io

https://getstream.io/cli/llms.txt

No CLI gate, no up-front shell. This skill never invokes Write, Edit, npm, scaffold tools, or

Bash(stream *)

. Pure docs questions with an explicit SDK reach

WebFetch

without running any shell command. A small read-only probe runs only on demand - inside Step 1a below - when the SDK can't be resolved from the user's input. If the user's question requires running the CLI or building code, offer to switch - the user re-enters via the

stream

router, the

stream-cli

skill, or the

stream-builder

skill.

1. Announce inference only when it happened. If you picked an SDK/version from anything other than explicit user input, say so in the first sentence - but only on the turn the inference happened:
   • "Looking in Chat React v13 (detected from your package.json)..."
   • "Inferring Video from your question about 'calls' - let me know if you meant something else..."
   On follow-ups within the same SDK, stay silent - the user knows what's loaded. Only re-announce when the SDK changes. For explicit input (e.g.

   /stream Chat React v14

   ), no preamble is needed - go straight to the answer.
2. Write for humans, not for the skill. Users don't know (or care) how this skill works - they want their answer. No internal workflow terminology, status narration, or process commentary should ever appear in output. The answer itself proves the fetch worked.
   Never say:

   Bad (leaks internals)	Why it's bad
   "framework index", "CLI index", "the index"	Internal term - call it "the docs" or skip the label
   "slug", "per llms.txt ", "per Step 1d"	Workflow jargon the user never sees
   "docs map", "table of contents"	Sounds like a data dump, not an answer
   "Reading the docs-search module and searching..."	Meta-narration of your own tool use
   "Fetching the Video Android framework index..."	Process commentary
   "the versioned URL returned 200", "index is in context now"	Fetch status - users assume success
   "Still in Chat React v14" on a follow-up	Redundant; users know they didn't switch

   When an SDK has just loaded (explicit invocation like

   /stream Video Android

   ), open with a warm human sentence, then get to the point. Good examples:
   • "Video Android docs loaded. Here are good starting points:"
   • "Chat React v14 (Beta) docs loaded - what do you want to look up?"
   • "Got the Video iOS docs. A few areas you can explore:"
   Then list actual pages/topics. Do not call it a "map", "index", or "TOC" - just present the content.
   List formatting rules (apply anywhere you emit links - SDK-loaded intros, "see also" notes, recovery messages):
   • Every link is a markdown link with a short title:

     [Installation](https://getstream.io/chat/docs/sdk/react/basics/installation.md)

     - never a bare URL in prose, never a URL wall, never comma-separated URLs inline.
   • One link per line. Readers scan vertically. Breaking five links onto one line hides four of them.
   • Curate, don't dump. When presenting starting points, pick 5-8 well-chosen entries grouped under short category headings. An exhaustive 30-URL inventory is a sitemap, not an intro. If the user wants the full index, they'll ask.
   • Group with short bold headings, not prose prefixes. Use

     **Getting started**

     on its own line with links below it - not

     Getting started: link1, link2, link3

     .
   Example - good:

   **Video Android docs loaded.** Here are good starting points:
   
   **Getting started**
   - [Installation](https://getstream.io/video/docs/android/basics/installation.md)
   - [Quickstart](https://getstream.io/video/docs/android/basics/quickstart.md)
   
   **Core APIs**
   - [Joining a call](https://getstream.io/video/docs/android/guides/joining-and-creating-calls.md)
   - [Call state](https://getstream.io/video/docs/android/guides/call-and-participant-state.md)
   
   What would you like to look up?

   Example - bad (URL wall):

   - Getting started: https://.../installation.md, https://.../quickstart.md, https://.../intro.md
   - Core APIs: https://.../call.md, https://.../state.md, https://.../participant.md

3. Only answer from fetched content. No training data, no assumptions, no "I think it's probably..." If you didn't fetch it in this conversation, you don't know it.
4. Cite the source page URL in every answer. Format:

   Source: [Page Title](https://getstream.io/...)

   - a complete, clickable URL.
5. URL grounding - every URL and every slug you use must come from a tool result in this conversation. Slugs come from

   llms.txt

   (fetched in Step 1b). Page URLs come from the framework index

   WebFetch

   in Step 2. Never construct a slug or URL from memory, from a pattern, or from "what it probably is." Many Stream URLs look guessable but aren't -

   chat-sdk-react

   vs

   chat-react

   vs

   chat-javascript

   all exist and point to different products.
   No placeholders. A citation must be a complete

   https://

   URL. Forbidden:
   • Ellipses:

     https://getstream.io/video/docs/android/...

     X
   • Patterns or templates:

     https://getstream.io/chat/docs/sdk/{framework}/...

     X
   • Descriptive stand-ins:

     Video Android docs index (table of contents)

     X
   • Wildcards:

     /components/*.md

     X
   If you don't have the exact page URL, your options are:
   • (a) Cite the index URL you actually fetched (e.g.

     https://getstream.io/cli/docs/video-android.md

     ) - a real fetched URL is always valid
   • (b) Re-fetch the index asking for raw URLs
   • (c) Tell the user "I have the SDK overview but need to fetch the specific page for a precise link"
   A citation you made up isn't a citation - it's a fabrication dressed as one.
6. If the docs don't cover it, say so. Don't fill gaps with guesses. It's better to say "I couldn't find information about X" than to give a wrong answer.
7. Don't invent cross-references. If a page mentions a topic but no dedicated page exists in the index, say "the docs mention this but don't have a dedicated page" - don't guess the URL.
8. Code examples from docs are authoritative. Use them verbatim unless the user's context requires adaptation.
9. Multi-page answers allowed, but fetch at most 3 pages per question. If more are needed, point the user to the framework index URL instead.

1. Explicit user input always wins. If the user named a product/framework/version (

   /stream Chat React v14

   ), use that even if the project contains a different SDK.
2. Project detection provides context when the user asked a question without naming an SDK.
3. Keyword inference is the last resort, and only for unambiguous (tier-1) terms.

1. Run project detection (Step 1a below)
2. Check for tier-1 keyword match (Step 1c, unambiguous terms)
3. Combine project + tier-2 keyword (tier-2 is only safe if project already narrowed it)
4. Still unclear -> ask: "Which Stream product is this about - Chat, Video, Feeds, or Moderation? And which SDK/framework?"

stream-cli

preflight.md

PKG

NATIVE

• project signals hasn't run yet in this conversation (rare - usually means you're answering before the router classified)
• project signals found nothing but the user's question implies a project file exists (e.g., the user said "in my Flutter project" but

  NATIVE

  was empty when probed)
• A scaffold or install completed mid-conversation and may have added packages

• If a tier-1 keyword clearly matches one -> use that one, announce the match
• If ambiguous -> ask: "I found Chat React v13 and Video React in your project. Which is this question about?"

https://getstream.io/cli/llms.txt

cli/docs/*.md

llms.txt

chat-sdk-react

chat-react

chat-javascript

llms.txt

"Return the raw list of SDK slugs and their section headers from llms.txt, verbatim. Do not summarize."

llms.txt

llms.txt

• Chat UI SDKs:

  chat-sdk-{framework}

  (e.g.

  chat-sdk-react

  ,

  chat-sdk-ios

  ). Versioned - see Step 1d.
• Chat low-level / server-side:

  chat-{framework}

  (e.g.

  chat-javascript

  ,

  chat-node

  ,

  chat-python

  ). No version suffix.
• Video:

  video-{framework}

  (e.g.

  video-react

  ,

  video-ios

  ,

  video-api

  ). No version suffix.
• Feeds (v3):

  activity-feeds-{framework}

  (e.g.

  activity-feeds-react

  ,

  activity-feeds-node

  ). Feeds v2 exists only for server-side languages - append

  -v2

  to one of:

  node

  ,

  python

  ,

  go-golang

  ,

  java

  ,

  ruby

  ,

  php

  ,

  dotnet-csharp

  ,

  javascript

  . There are no v2 slugs for React, React Native, iOS, Android, or Flutter.
• Moderation:

  moderation-{framework}

  (e.g.

  moderation-node

  ,

  moderation-python

  ). No version suffix.

llms.txt

stream-chat

stream-chat-react

stream-chat-angular

stream-chat

stream-chat

• Server-side file importing it (e.g.

  StreamChat.getInstance

  in

  api/

  or

  server/

  ) -> Chat + Node
• Otherwise -> default to Chat + JavaScript (client) and offer to switch: "Using Chat JavaScript docs (client-side). If you're asking about server-side Node usage, say so and I'll switch."

grep -rE "from ['\"]@stream-io/node-sdk['\"]" --include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" . 2>/dev/null | head -20
grep -rE "\.(video|feeds)\." --include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" . 2>/dev/null | grep -iE "streamclient|client\." | head -20

• .video.

  dominates -> Video + server

• .feeds.

  dominates -> Feeds + Node
• Both or neither -> ask

• Project detection resolved it -> use that, announce
• No project context -> ask

/stream Video Android Latest

video-android

chat-sdk-*

1. If the user specified a version (e.g.

   v14

   ) -> try the versioned URL first:

   chat-sdk-react-v14.md

   . If it returns 200, you're done. If it 404s, fall back to the base URL (

   chat-sdk-react.md

   ) - this means the version the user named IS the current latest.
2. If the user didn't specify a version, or said "latest" -> use the base URL directly. It always returns the latest version. The

   # Heading

   line will announce which version that is (e.g.

   # React v13 (Latest)

   ) - use this when citing.
3. If the user asked for the latest by version number (e.g. user said "v13" and v13 is current latest) -> the versioned URL will 404 (current latest is at base URL only). Fall back to base.

https://getstream.io/cli/docs/{slug}.md

WebFetch

"Return the top-level heading, and every page in the index as

Title - URL

with the exact URL as listed. Do not summarize."

https://

• Prefer exact keyword matches ("reactions" -> title containing "reaction")
• Fall back to broader topic ("custom reactions" -> "Message Interactions")
• Prefer pages that sound like the user's question type:
  • "How do I X?" -> Guides, How-Tos, Getting Started
  • "What is X?" -> Overview, Introduction, Concepts
  • "API for X?" -> Reference, API pages
• If multiple candidates, fetch the most specific one first
• Fetch at most 3 pages per question

1. Start with an inference announcement only if rule #1 required one (inference this turn, or SDK just switched) - otherwise go straight to the answer
2. Quote or paraphrase directly from fetched content
3. End with a source citation:

   Source: [Page Title](https://getstream.io/...)

The docs describe how to add a reaction, but don't cover custom reaction UI rendering on this page. See also Message Interactions.

llms.txt

1. Check spelling, version suffix, product prefix against

   llms.txt

   (verbatim)
2. Retry once with a corrected slug from

   llms.txt

3. If still 404 or no matching slug exists in

   llms.txt

   , tell the user the SDK isn't in the docs and list what's available

• Check the framework index for related pages (same section, similar title)
• Fetch one more page (within the 3-page limit)
• Still no answer -> tell the user which pages you checked and offer to try a different SDK

• llms.txt

  is fetched once per conversation (in Step 1b). Don't re-fetch - it stays in context for every slug lookup after.
• Within a conversation, the framework index stays in context. Don't re-fetch for follow-ups on the same SDK.
• Per question, fetch at most 3 pages (doc pages, not counting

  llms.txt

  or the framework index).
• Switching SDKs - follow-up on a different SDK -> restart Step 1 cleanly (but

  llms.txt

  is still loaded, just pick a different slug).

/stream how do I add reactions?

stream-chat-react@^13.2.0

stream

• No explicit SDK -> Case B.
• Step 1a (project detection): finds

  stream-chat-react@13

  .
• Step 1b: fetch

  llms.txt

  , map

  stream-chat-react

  -> Chat + React (UI), find slug

  chat-sdk-react

  in

  llms.txt

  , major version 13.
• Step 1c (tiers): "reactions" is tier-2, but project already resolved to Chat - proceed.
• Step 1d (version): user didn't specify -> use base URL.
• Announce: "Looking in Chat React (detected from your package.json)..."

• https://getstream.io/cli/docs/chat-sdk-react.md

  -> 200.
• Heading confirms:

  # React v13 (Latest)

  .

• Scan index for "reaction" -> find "Message Interactions" and "Custom Reactions".
• User asked a basic how-to -> pick "Message Interactions" first (basic), not "Custom Reactions" (advanced).
• Fetch

  https://getstream.io/chat/docs/sdk/react/.../message-interactions.md

  .

• Quote the add-reaction example from the page.
• Cite:

  Source: [Message Interactions](https://getstream.io/chat/docs/sdk/react/.../message-interactions/)