stream-docs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Stream - Docs search (live SDK documentation)

Stream - 文档搜索（实时SDK文档）

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.

Answer questions from Stream's official SDK documentation by fetching live pages from

getstream.io

. Covers Chat, Video, Activity Feeds, and Moderation across every framework and version.

Docs index:

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.

每次会话必看： 读取
../stream/SKILL.md
文件。若路径为空，执行
npx skills add GetStream/agent-skills --s stream -y
安装（无需确认，直接运行）。之后读取
../stream/RULES.md
—— 其中包含Peer技能表格，可按需安装/调用其他技能包。

通过从

getstream.io

获取实时页面，解答Stream官方SDK文档中的问题。覆盖聊天、视频、活动动态流及内容审核产品，支持所有框架与版本。

文档索引：

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

无需CLI前置操作。 本技能绝不会调用写入、编辑、npm、脚手架工具或
Bash(stream *)
命令。仅针对明确SDK相关的纯文档问题调用
WebFetch
，无需执行任何shell命令。仅在按需触发时（如下文步骤1a）会运行一个小型只读探测——当无法从用户输入中解析出SDK信息时才会执行。若用户问题需要运行CLI或构建代码，可切换至对应技能——用户可通过
stream
路由、
stream-cli
技能或
stream-builder
技能重新进入相关流程。

Honesty rules (read before anything else)

诚信规则（操作前必读）

These rules are non-negotiable. Read them before every response.

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.

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

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.
Cite the source page URL in every answer. Format:
```
Source: [Page Title](https://getstream.io/...)
```
- a complete, clickable URL.
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.
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.
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.
Code examples from docs are authoritative. Use them verbatim unless the user's context requires adaptation.
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.

以下规则不可协商，每次响应前需确认已阅读。

仅在推理发生时告知用户。 若SDK/版本并非来自用户明确输入，需在第一句说明——且仅在推理发生的那次对话中告知：
- "正在查看Chat React v13（从你的package.json中检测到）..."
- "从你关于'通话'的问题中推断为Video产品——若并非此意，请告知..."
在同一场SDK对话的后续提问中无需重复说明——用户已知当前加载的SDK。仅当切换SDK时需重新告知。对于明确输入（如
```
/stream Chat React v14
```
），无需前置说明，直接给出答案。

面向用户而非技能本身输出内容。 用户无需知晓本技能的工作原理——他们只需要答案。输出中不得出现内部工作流术语、状态说明或流程注释，答案本身即可证明内容已成功获取。

禁止表述：

错误表述（泄露内部逻辑）	错误原因
"framework index", "CLI index", "the index"	内部术语——应称为「文档」或直接省略标签
"slug", "per `llms.txt` ", "per Step 1d"	用户看不到的工作流黑话
"docs map", "table of contents"	听起来像数据转储而非答案
"正在读取文档搜索模块并进行搜索..."	对自身工具使用的元叙述
"正在获取Video Android框架索引..."	流程操作说明
"带版本的URL返回200状态码"、"索引已载入上下文"	获取状态——用户默认操作成功
后续提问中说"仍在Chat React v14环境"	冗余表述——用户未切换SDK则已知晓

当SDK刚加载完成时（如显式调用

/stream Video Android

），以友好的口语化语句开场，然后直接进入主题。示例：

"Video Android文档已加载。 以下是实用入门内容："
"Chat React v14（Beta）文档已加载——你想查询什么内容？"
"已获取Video iOS文档。你可以探索以下几个方向："

之后列出实际页面/主题。不得将其称为「地图」「索引」或「目录」——直接展示内容即可。

列表格式规则（适用于所有输出链接场景：SDK加载介绍、「另请参阅」提示、错误恢复信息）：

每个链接需为带简短标题的Markdown链接：
```
[安装](https://getstream.io/chat/docs/sdk/react/basics/installation.md)
```
——不得在正文中使用裸URL、URL堆砌或逗号分隔的内嵌URL。
每行仅放一个链接。读者习惯垂直扫描，将五个链接放在一行会隐藏其中四个。
精选内容而非全部导出。展示入门内容时，挑选5-8个经过筛选的条目，按简短分类标题分组。包含30个URL的完整清单是站点地图而非入门介绍。若用户需要完整索引，他们会主动询问。
使用简短加粗标题分组，而非前缀描述。单独一行使用
```
**入门指南**
```
，下方放置链接——而非
```
入门指南：link1, link2, link3
```
。

正确示例：

**Video Android文档已加载。** 以下是实用入门内容：

**入门指南**
- [安装](https://getstream.io/video/docs/android/basics/installation.md)
- [快速开始](https://getstream.io/video/docs/android/basics/quickstart.md)

**核心API**
- [加入通话](https://getstream.io/video/docs/android/guides/joining-and-creating-calls.md)
- [通话状态](https://getstream.io/video/docs/android/guides/call-and-participant-state.md)

你想查询什么内容？

错误示例（URL堆砌）：

- 入门指南：https://.../installation.md, https://.../quickstart.md, https://.../intro.md
- 核心API：https://.../call.md, https://.../state.md, https://.../participant.md

仅基于获取的内容作答。 不得使用训练数据、主观假设或类似「我认为可能是...」的表述。若未在本次对话中获取相关内容，则不得声称知晓。
每个答案都需标注来源页面URL。格式：
```
来源：[页面标题](https://getstream.io/...)
```
——需为完整可点击的URL。
URL锚定规则——所有使用的URL和slug必须来自本次对话中的工具结果。slug来自
```
llms.txt
```
（步骤1b中获取）。页面URL来自步骤2中的框架索引
```
WebFetch
```
。绝不能凭记忆、模式或「推测的正确格式」构造slug或URL。许多Stream URL看似可推测，但实际存在差异——
```
chat-sdk-react
```
、
```
chat-react
```
、
```
chat-javascript
```
均存在且指向不同产品。
禁止使用占位符。引用必须是完整的
```
https://
```
格式URL。以下为禁止示例：
- 省略号：
```
https://getstream.io/video/docs/android/...
```
  ×
- 模式或模板：
```
https://getstream.io/chat/docs/sdk/{framework}/...
```
  ×
- 描述性替代：
```
Video Android文档索引（目录）
```
  ×
- 通配符：
```
/components/*.md
```
  ×
若无确切页面URL，可选方案：
- (a) 引用实际获取的索引URL（如
```
https://getstream.io/cli/docs/video-android.md
```
  ）——真实获取的URL始终有效
- (b) 重新获取索引并要求返回原始URL
- (c) 告知用户「我已获取SDK概述，但需获取具体页面以提供精确链接」
编造的引用并非真实引用——只是伪装成引用的虚假内容。
若文档未覆盖相关内容，直接告知用户。不得用猜测填补空白。说「未找到关于X的信息」比给出错误答案更好。
不得编造交叉引用。若页面提及某主题但索引中无对应专属页面，需说明「文档提及此主题但无专属页面」——不得猜测URL。
文档中的代码示例具有权威性。除非用户上下文需要调整，否则直接使用原文示例。
允许多页面作答，但每个问题最多获取3个页面。若需要更多内容，可引导用户查看框架索引URL。

Invocation

调用方式

This skill is reached through

/stream

(router routes here based on signals) or directly via

/stream-docs

. The same input shapes work either way:

/stream <Product> <Framework> [Version]    Load a specific SDK
/stream <question about the SDK>           Answer from the docs
/stream-docs <Product> <Framework>          Direct invocation (skips router)

Examples that route here:

/stream Chat React v14
/stream Video iOS
/stream Moderation
/stream how do I add reactions to messages?
/stream-docs Feeds Node

本技能可通过

/stream

路由（根据信号路由至此）或直接通过

/stream-docs

调用。两种方式支持相同的输入格式：

/stream <产品> <框架> [版本]    加载指定SDK
/stream <SDK相关问题>           从文档中获取答案
/stream-docs <产品> <框架>          直接调用（跳过路由）

触发路由至此的示例：

/stream Chat React v14
/stream Video iOS
/stream Moderation
/stream how do I add reactions to messages?
/stream-docs Feeds Node

Shortcut: SDK named with no question

快捷方式：仅指定SDK无问题

If the user invokes

/stream Chat React v14

(or any product/framework/version) with no follow-up question, fetch

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

, resolve the slug, fetch the framework index, and present 5-8 curated starting points using the list formatting rules above. Wait for the user to pick a topic.

若用户调用

/stream Chat React v14

（或任何产品/框架/版本）但未附加问题，需获取

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

，解析slug，获取框架索引，并按照上述列表格式规则展示5-8个精选入门内容。等待用户选择主题。

Shortcut: bare

/stream

with no args

快捷方式：仅输入

/stream

无参数

That's handled by the

stream

router (it lists the sub-skills). Don't intercept it here.

此情况由

stream

路由处理（列出子技能），不得在此拦截。

Step 1: Identify the SDK

步骤1：识别SDK

Precedence

优先级

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.
Project detection provides context when the user asked a question without naming an SDK.
Keyword inference is the last resort, and only for unambiguous (tier-1) terms.

用户明确输入始终优先。若用户指定了产品/框架/版本（如
```
/stream Chat React v14
```
），即使项目中包含其他SDK，也使用用户指定的内容。
项目检测用于用户未指定SDK的问题场景，提供上下文信息。
关键词推理为最后手段，仅适用于无歧义的（一级）术语。

Resolution order for "question without named SDK"

「未指定SDK的问题」解析顺序

Stop at the first step that gives a confident answer:

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

找到明确答案后立即停止：

运行项目检测（下文步骤1a）
检查一级关键词匹配（步骤1c，无歧义术语）
结合项目+二级关键词（仅当项目已缩小范围时，二级关键词才安全）
仍不明确 -> 询问：「这是关于Stream的哪款产品——聊天、视频、动态流还是内容审核？使用的是哪个SDK/框架？」

Step 1a - Project detection

步骤1a - 项目检测

Check project signals first. The

stream-cli

skill's

preflight.md

> Project signals runs once per session for the CLI and builder skills, populating

PKG

(Stream npm packages with versions) and

NATIVE

(non-npm project files). If those signals are already in conversation context, use them directly - no extra probe.

Only run a fresh probe if:

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

优先检查项目信号。

stream-cli

技能的

preflight.md

> 项目信号会在会话中为CLI和构建技能运行一次，填充

PKG

（带版本的Stream npm包）和

NATIVE

（非npm项目文件）信息。若对话上下文中已存在这些信号，可直接使用——无需额外探测。

仅在以下情况运行新探测：

本次对话中尚未运行项目信号（罕见——通常意味着在路由分类前就开始作答）
项目信号未检测到内容，但用户问题暗示存在项目文件（如用户说「在我的Flutter项目中」但
```
NATIVE
```
探测为空）
会话中途完成了脚手架搭建或安装操作，可能已添加新包

Fallback probes (when project signals are missing)

回退探测（无项目信号时）

npm:

bash

grep -oE '"(stream-chat-react|stream-chat-react-native|stream-chat-expo|stream-chat-angular|stream-chat|@stream-io/video-react-sdk|@stream-io/video-react-native-sdk|@stream-io/video-client|@stream-io/node-sdk|@stream-io/stream-node|@stream-io/feeds-react-sdk)": *"[^"]*"' package.json 2>/dev/null

Non-npm:

bash

ls pubspec.yaml go.mod requirements.txt pyproject.toml Podfile build.gradle 2>/dev/null

Either way, extract the major version from semver (e.g.

"stream-chat-react": "^13.2.0"

) for Chat SDK slugs, then map packages to product + framework using Step 1b (which resolves to a slug via

llms.txt

npm项目：

bash

grep -oE '"(stream-chat-react|stream-chat-react-native|stream-chat-expo|stream-chat-angular|stream-chat|@stream-io/video-react-sdk|@stream-io/video-react-native-sdk|@stream-io/video-client|@stream-io/node-sdk|@stream-io/stream-node|@stream-io/feeds-react-sdk)": *"[^"]*"' package.json 2>/dev/null

非npm项目：

bash

ls pubspec.yaml go.mod requirements.txt pyproject.toml Podfile build.gradle 2>/dev/null

无论哪种情况，从语义化版本中提取主版本号（如

"stream-chat-react": "^13.2.0"

）用于Chat SDK的slug，然后使用步骤1b（通过

llms.txt

解析为slug）将包映射到产品+框架。

Multiple SDKs detected

检测到多个SDK

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?"

若一级关键词明确匹配其中一个 -> 使用该SDK，并告知匹配结果
若存在歧义 -> 询问：「我在你的项目中检测到Chat React v13和Video React。此问题针对哪一个？」

Step 1b - Resolve to a slug via

llms.txt

步骤1b - 通过

llms.txt

解析为slug

You MUST fetch
https://getstream.io/cli/llms.txt
before constructing any
cli/docs/*.md
URL for the first time in a conversation.

llms.txt

is the live, authoritative list of every SDK slug Stream publishes - don't guess slugs from memory.

chat-sdk-react

chat-react

, and

chat-javascript

all look plausible but point to different products, and a wrong slug silently returns the wrong docs.

llms.txt

is the only source of truth; once fetched, it stays in context for the rest of the conversation.

Fetch prompt:

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

Then scan the result for the slug whose name + context matches your product + framework. The sections below tell you what to match, but the slug you use must exist in

llms.txt

会话中首次构建任何
cli/docs/*.md
URL前，必须获取
https://getstream.io/cli/llms.txt
。

llms.txt

是Stream发布的所有SDK slug的实时权威列表——不得凭记忆猜测slug。

chat-sdk-react

、

chat-react

、

chat-javascript

看似相似，但指向不同产品，错误的slug会静默返回错误文档。

llms.txt

是唯一可信来源；获取后，将在整个会话的上下文中保留。

获取提示：

"返回llms.txt中的SDK slug及其章节标题的原始列表，逐字返回，不得总结。"

然后扫描结果，找到名称和上下文与产品+框架匹配的slug。下文小节会说明匹配规则，但使用的slug必须存在于

llms.txt

中。

Slug-name patterns (scanning hints)

Slug命名模式（扫描提示）

Slugs follow predictable patterns - use these to guide your scan, then verify the match exists in

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.

If your constructed slug isn't in

llms.txt

, don't use it. If you can't find a match at all, tell the user the combination isn't in the docs and list what is available.

Slug遵循可预测的模式——可借助这些模式引导扫描，然后验证匹配项是否存在于

llms.txt

中：

Chat UI SDK：
```
chat-sdk-{framework}
```
（如
```
chat-sdk-react
```
、
```
chat-sdk-ios
```
）。带版本——见步骤1d。
Chat底层/服务端SDK：
```
chat-{framework}
```
（如
```
chat-javascript
```
、
```
chat-node
```
、
```
chat-python
```
）。无版本后缀。
Video SDK：
```
video-{framework}
```
（如
```
video-react
```
、
```
video-ios
```
、
```
video-api
```
）。无版本后缀。
Feeds（v3）：
```
activity-feeds-{framework}
```
（如
```
activity-feeds-react
```
、
```
activity-feeds-node
```
）。Feeds v2仅支持服务端语言——在以下语言后追加
```
-v2
```
：
```
node
```
、
```
python
```
、
```
go-golang
```
、
```
java
```
、
```
ruby
```
、
```
php
```
、
```
dotnet-csharp
```
、
```
javascript
```
。React、React Native、iOS、Android或Flutter无v2 slug。

Moderation SDK：

moderation-{framework}

（如

moderation-node

、

moderation-python

）。无版本后缀。

若构造的slug不在

llms.txt

中，不得使用。若完全找不到匹配项，告知用户该组合不在文档中，并列出可用的选项。

Framework-name normalization

框架名称标准化

Normalize user input to the tokens slugs use:

User says	Use
React	`react`
React Native	`react-native`
iOS, Swift	`ios` (Chat low-level: `ios-swift` )
Android, Kotlin	`android`
Flutter, Dart	`flutter` (Chat low-level: `flutter-dart` )
Angular	`angular`
Node, NodeJS, Node.js	`node`
Python	`python`
Go, Golang	`go-golang`
.NET, C#, CSharp	`dotnet-csharp`
PHP	`php`
Ruby	`ruby`
Java	`java`
JavaScript, JS	`javascript`
Unity	`unity`
Unreal	`unreal`
ESP32	`esp32`

将用户输入标准化为slug使用的标识：

用户输入	标准化后标识
React	`react`
React Native	`react-native`
iOS、Swift	`ios` （Chat底层SDK： `ios-swift` ）
Android、Kotlin	`android`
Flutter、Dart	`flutter` （Chat底层SDK： `flutter-dart` ）
Angular	`angular`
Node、NodeJS、Node.js	`node`
Python	`python`
Go、Golang	`go-golang`
.NET、C#、CSharp	`dotnet-csharp`
PHP	`php`
Ruby	`ruby`
Java	`java`
JavaScript、JS	`javascript`
Unity	`unity`
Unreal	`unreal`
ESP32	`esp32`

npm packages -> product + framework

npm包 -> 产品+框架

When Step 1a detected a package, map it to a product + framework, then find the matching slug in

llms.txt

Package	Product + framework
`stream-chat-react`	Chat + React (UI)
`stream-chat-react-native` or `stream-chat-expo`	Chat + React Native (UI)
`stream-chat-angular`	Chat + Angular (UI)
`stream-chat` alone	Chat JS (client) or Chat Node (server) - see special case
`@stream-io/video-react-sdk`	Video + React
`@stream-io/video-react-native-sdk`	Video + React Native
`@stream-io/video-client`	Video + JavaScript
`@stream-io/node-sdk`	Video or Feeds - see special case
`@stream-io/stream-node`	Moderation + Node
`@stream-io/feeds-react-sdk`	Feeds + React

For Chat UI packages, extract the major version from semver (e.g.

"stream-chat-react": "^13.2.0"

) - you'll need it for Step 1d.

当步骤1a检测到包时，将其映射到产品+框架，然后在

llms.txt

中找到匹配的slug：

包名	产品+框架
`stream-chat-react`	Chat + React（UI）
`stream-chat-react-native` 或 `stream-chat-expo`	Chat + React Native（UI）
`stream-chat-angular`	Chat + Angular（UI）
仅 `stream-chat`	Chat JS（客户端）或Chat Node（服务端）——见特殊情况
`@stream-io/video-react-sdk`	Video + React
`@stream-io/video-react-native-sdk`	Video + React Native
`@stream-io/video-client`	Video + JavaScript
`@stream-io/node-sdk`	Video或Feeds——见特殊情况
`@stream-io/stream-node`	Moderation + Node
`@stream-io/feeds-react-sdk`	Feeds + React

对于Chat UI包，从语义化版本中提取主版本号（如

"stream-chat-react": "^13.2.0"

）——步骤1d会用到此信息。

Special case:

stream-chat

alone

特殊情况：仅

stream-chat

stream-chat

is used both client-side (JS apps) and server-side (Node apps). If a UI wrapper is also present (

stream-chat-react

stream-chat-angular

, etc.), prefer the wrapper's product -

stream-chat

is just a peer dependency there.

If only

stream-chat

is detected:

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

stream-chat

同时用于客户端（JS应用）和服务端（Node应用）。若同时存在UI包装器（如

stream-chat-react

、

stream-chat-angular

等），优先使用包装器对应的产品——

stream-chat

仅为其对等依赖。

若仅检测到

stream-chat

：

服务端文件中导入（如
```
api/
```
或
```
server/
```
中的
```
StreamChat.getInstance
```
） -> Chat + Node
其他情况 -> 默认使用Chat + JavaScript（客户端），并提供切换选项：「正在使用Chat JavaScript文档（客户端）。若你询问的是服务端Node使用方式，请告知，我将切换。」

Special case:

@stream-io/node-sdk

特殊情况：

@stream-io/node-sdk

Serves both Video and Feeds v3. Probe usage:

bash

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

同时支持Video和Feeds v3。探测使用场景：

bash

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.
```
占主导 -> Video + 服务端
```
.feeds.
```
占主导 -> Feeds + Node
两者都有或都没有 -> 询问用户

Non-npm project files -> product + framework

非npm项目文件 -> 产品+框架

File	Contains	Product + framework
`pubspec.yaml`	`stream_chat_flutter`	Chat + Flutter (UI)
`pubspec.yaml`	only `stream_chat` (no UI)	Chat + Flutter (low-level)
`Podfile` / `*.xcodeproj`	`StreamChat`	Chat + iOS (UI)
`Podfile` / `*.xcodeproj`	`StreamVideo`	Video + iOS
`build.gradle`	`io.getstream:stream-chat-android`	Chat + Android (UI)
`build.gradle`	`io.getstream:stream-video-android`	Video + Android
`requirements.txt` / `pyproject.toml`	`getstream`	Chat or Video + Python (ask if ambiguous)
`go.mod`	`github.com/GetStream/getstream-go`	Chat or Video + Go (ask if ambiguous)

文件	包含内容	产品+框架
`pubspec.yaml`	`stream_chat_flutter`	Chat + Flutter（UI）
`pubspec.yaml`	仅 `stream_chat` （无UI）	Chat + Flutter（底层）
`Podfile` / `*.xcodeproj`	`StreamChat`	Chat + iOS（UI）
`Podfile` / `*.xcodeproj`	`StreamVideo`	Video + iOS
`build.gradle`	`io.getstream:stream-chat-android`	Chat + Android（UI）
`build.gradle`	`io.getstream:stream-video-android`	Video + Android
`requirements.txt` / `pyproject.toml`	`getstream`	Chat或Video + Python（若存在歧义则询问）
`go.mod`	`github.com/GetStream/getstream-go`	Chat或Video + Go（若存在歧义则询问）

Step 1c - Inference tiers

步骤1c - 推理层级

Only applies when the user asked a question without naming an SDK.

仅适用于用户未指定SDK的问题场景。

Tier 1: Unambiguous (proceed and announce)

一级：无歧义（直接处理并告知用户）

Each keyword maps to exactly one product:

Keywords	Product
"call state", "join a call", "make a call", "start a call", "ringing", "screen share", "screensharing"	Video
"HLS", "RTMP", "livestream viewer", "egress"	Video
"channel", "channel members", "message thread", "read receipts", "typing indicator", "unread count"	Chat
"activity", "follow feed", "aggregated feed", "timeline feed", "notification feed"	Feeds
"review queue", "flagged content", "block list", "moderation policy", "ban list"	Moderation

每个关键词仅对应一款产品：

关键词	产品
"通话状态"、"加入通话"、"发起通话"、"开始通话"、"来电提醒"、"屏幕共享"	Video
"HLS"、"RTMP"、"直播观众"、"输出"	Video
"频道"、"频道成员"、"消息线程"、"已读回执"、"输入状态"、"未读计数"	Chat
"活动"、"关注动态流"、"聚合动态流"、"时间线动态流"、"通知动态流"	Feeds
"审核队列"、"标记内容"、"黑名单"、"审核策略"、"封禁列表"	Moderation

Tier 2: Ambiguous (needs project context OR ask)

二级：有歧义（需项目上下文或询问用户）

These appear across multiple products - never infer from them alone:

Term	Possible products
"notifications"	Chat push, Feeds notification feeds, Video ringing
"streaming"	Video streaming, Feeds activity stream
"messages"	Chat messages, Feeds comments
"users"	Any product
"reactions"	Chat message reactions, Feeds activity reactions
"moderation" without specifics	Dedicated Moderation product OR in-SDK moderation for Chat/Feeds

When the only signal is a tier-2 keyword:

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

这些术语出现在多款产品中——绝不能仅通过这些术语推理：

术语	可能对应的产品
"通知"	Chat推送通知、Feeds通知动态流、Video来电提醒
"流"	Video直播流、Feeds活动流
"消息"	Chat消息、Feeds评论
"用户"	任意产品
"反应"	Chat消息反应、Feeds活动反应
无具体说明的"审核"	专属Moderation产品或Chat/Feeds的SDK内置审核功能

当唯一信号为二级关键词时：

项目检测已解析 -> 使用该结果并告知用户
无项目上下文 -> 询问用户

Step 1d - Version handling (Chat SDKs only)

步骤1d - 版本处理（仅Chat SDK）

Video, Feeds, and Moderation slugs don't have version suffixes. Skip this step for those - if the user said something like

/stream Video Android Latest

, silently ignore the "Latest" token and use

video-android

. Don't ask about it and don't mention that "Latest" was meaningless - just proceed.

For Chat SDK slugs (

chat-sdk-*

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

This approach costs 1 fetch in the common case, 2 only when falling back.

Video、Feeds和Moderation的slug无版本后缀。这些产品可跳过此步骤——若用户输入类似

/stream Video Android Latest

，可忽略"Latest"标识，直接使用

video-android

。无需询问或提及"Latest"无意义——直接继续即可。

对于Chat SDK的slug（

chat-sdk-*

）：

若用户指定版本（如
```
v14
```
） -> 优先尝试带版本的URL：
```
chat-sdk-react-v14.md
```
。若返回200状态码，操作完成。若返回404，回退到基础URL（
```
chat-sdk-react.md
```
）——这意味着用户指定的版本即为当前最新版本。
若用户未指定版本或输入"latest" -> 直接使用基础URL。该URL始终返回最新版本。页面的
```
# 标题
```
行会标注当前版本（如
```
# React v13（Latest）
```
）——引用时需使用此版本信息。
若用户通过版本号指定最新版本（如用户输入"v13"且v13为当前最新版本） -> 带版本的URL会返回404（当前最新版本仅在基础URL中）。回退到基础URL。

此方法在常见场景下仅需1次获取，仅在回退时需要2次获取。

Step 2: Fetch the framework index

步骤2：获取框架索引

Construct the URL from Step 1 and fetch it:

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

Fetch prompt matters.

WebFetch

summarizes content by default, which drops the exact URLs you need for Step 3. On the first fetch, explicitly ask for the verbatim list - e.g.:

"Return the top-level heading, and every page in the index as
Title - URL
with the exact URL as listed. Do not summarize."

Verify after fetching. Scan the tool result for actual

https://

URLs. If the response is a prose summary without URLs - even after you asked for them - the prompt failed. Re-fetch once with a stricter prompt (e.g. "Return the raw markdown content with zero summarization. I need the exact URLs."). If the second fetch still has no raw URLs, tell the user the index came back without URLs and stop - do not proceed with constructed URLs. This is rule #5 (URL grounding) in action: no URL goes into an answer unless you saw it verbatim in a tool result.

Getting the URLs on the first fetch lets follow-ups in the same SDK pick pages without re-fetching. If you need page URLs later for a specific topic and don't have them, re-fetch with a targeted prompt (e.g. "return exact URLs for any pages about MessageComposer, verbatim, no summary").

If the index 404s, see Recovery below.

根据步骤1构造URL并获取：

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

获取提示至关重要。

WebFetch

默认会总结内容，这会丢失步骤3所需的精确URL。首次获取时，需明确要求返回原始列表——例如：

"返回顶级标题，以及索引中的每个页面，格式为
标题 - URL
，包含列出的精确URL。不得总结。"

获取后验证。扫描工具结果中的实际

https://

URL。若响应为无URL的 prose 摘要——即使已要求返回URL——说明提示失效。重新获取一次，使用更严格的提示（如"返回原始Markdown内容，不得进行任何总结。我需要精确的URL。"）。若第二次获取仍无原始URL，告知用户索引未返回URL并停止操作——不得使用构造的URL继续。这是规则#5（URL锚定）的实际应用：除非在工具结果中看到精确URL，否则不得将其加入答案。

首次获取时获取URL，可让同一场SDK对话的后续提问无需重新获取即可选择页面。若后续针对特定主题需要页面URL但未保存，可重新获取并使用针对性提示（如"返回关于MessageComposer的所有页面的精确URL，逐字返回，不得总结"）。

若索引返回404，见下文错误恢复部分。

Step 3: Find and fetch the page

步骤3：查找并获取页面

Scan the framework index for the title that best matches the user's question.

扫描框架索引，找到最匹配用户问题的标题。

Matching strategy

匹配策略

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

Fetch the chosen page and answer from its content.

优先选择精确关键词匹配（如"reactions" -> 包含"reaction"的标题）
回退到更宽泛的主题（如"自定义反应" -> "消息交互"）
根据用户问题类型选择对应页面：
- "How do I X?" -> 指南、实操教程、入门内容
- "What is X?" -> 概述、介绍、概念
- "API for X?" -> 参考、API页面
若存在多个候选页面，优先获取最具体的页面
每个问题最多获取3个页面

获取选中的页面并根据内容作答。

Step 4: Answer

步骤4：作答

Apply the honesty rules (top of file). Every answer must:

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

End with a source citation:

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

遵循诚信规则（本文档顶部）。每个答案必须：

仅在规则#1要求时（本次对话进行了推理，或刚切换SDK）以推理说明开场——否则直接给出答案
直接引用或转述获取的内容

结尾标注来源：

来源：[页面标题](https://getstream.io/...)

When the docs cover it partially

当文档仅部分覆盖问题时

Quote what's there, then explicitly note what's missing:

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

引用已有内容，然后明确说明缺失部分：

文档描述了添加反应的方法，但本页面未覆盖自定义反应UI渲染。另请参阅消息交互。

When the docs don't cover it at all

当文档完全未覆盖问题时

I couldn't find information about {topic} in the {SDK name} docs.

You can browse the full index at https://getstream.io/cli/docs/{slug}.md or try:
- A different framework (same question, different SDK)
- The broader product docs at https://getstream.io/{product}/

Never fabricate an answer.

我在{SDK名称}文档中未找到关于{主题}的信息。

你可以浏览完整索引：https://getstream.io/cli/docs/{slug}.md，或尝试：
- 使用不同框架（相同问题，不同SDK）
- 查看产品全局文档：https://getstream.io/{product}/

绝不能编造答案。

Cross-references to other skills

与其他技能的交叉引用

Full guidance lives in the

stream

skill's

RULES.md

> Cross-track follow-ups. This skill's specific guarantee: never execute a cross-skill action from inside docs search - only offer. The user re-routes by asking, which re-enters the router (or jumps to the named sub-skill). This keeps the no-side-effects promise intact even when a docs answer naturally enables a CLI run, scaffold, or integration.

完整指引位于

stream

技能的

RULES.md

> 跨流程后续操作。本技能的特定承诺：绝不在文档搜索内部执行跨技能操作——仅提供选项。用户需通过提问重新路由，重新进入路由（或直接跳转到指定子技能）。即使文档答案自然涉及CLI运行、脚手架搭建或集成操作，此规则也能保证无副作用。

Recovery from failures

错误恢复

404 on framework index

框架索引返回404

The slug was wrong - but you already have

llms.txt

in context from Step 1b. Re-scan it:

Check spelling, version suffix, product prefix against
```
llms.txt
```
(verbatim)
Retry once with a corrected slug from
```
llms.txt
```
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

slug错误——但步骤1b已将

llms.txt

载入上下文。重新扫描：

对照
```
llms.txt
```
（逐字）检查拼写、版本后缀、产品前缀
使用
```
llms.txt
```
中的正确slug重试一次
若仍返回404或
```
llms.txt
```
中无匹配slug，告知用户该SDK不在文档中，并列出可用选项

404 on Chat SDK versioned URL

Chat SDK带版本的URL返回404

The version the user named is the current latest - fall back to the base URL (

chat-sdk-react.md

instead of

chat-sdk-react-v13.md

). This is expected behavior, not a real failure.

用户指定的版本即为当前最新版本——回退到基础URL（如使用

chat-sdk-react.md

而非

chat-sdk-react-v13.md

）。这是预期行为，并非真正的错误。

Fetched page doesn't answer the question

获取的页面无法解答问题

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

检查框架索引中的相关页面（同一章节、类似标题）
再获取一个页面（不超过3页限制）
仍无答案 -> 告知用户已检查的页面，并提供尝试其他SDK的选项

Empty or malformed framework index

框架索引为空或格式错误

Fall back to

llms.txt

. This shouldn't happen under normal conditions - if it does, tell the user.

回退到

llms.txt

。正常情况下不会发生此问题——若发生，告知用户。

User asks a follow-up that doesn't match any index page

用户后续提问无匹配索引页面

Don't invent cross-references. Say: "That specific topic isn't in the {SDK} index. Want me to check a related SDK or the global index?"

不得编造交叉引用。告知用户：「该特定主题不在{SDK}索引中。需要我检查相关SDK或全局索引吗？」

Conversation economy

会话资源优化

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

llms.txt
在会话中仅获取一次（步骤1b）。无需重新获取——后续所有slug查找均可使用上下文内容。
同一会话中，框架索引会保留在上下文中。针对同一SDK的后续提问无需重新获取。
每个问题最多获取3个页面（文档页面，不包含
```
llms.txt
```
或框架索引）。
切换SDK——针对不同SDK的后续提问 -> 重新执行步骤1（但
```
llms.txt
```
已加载，仅需选择不同slug）。

Worked example

实操示例

User:

/stream how do I add reactions?

(in a React project with

stream-chat-react@^13.2.0

)

Step 0 (in the
stream
router): intent classifier - "how do I" + no operational verb + project context likely -> docs search, no CLI gate.

Step 1 - Identify the SDK:

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)..."

Step 2 - Fetch the framework index:

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

-> 200.

Heading confirms:
```
# React v13 (Latest)
```
.

Step 3 - Find and fetch the page:

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

Step 4 - Answer:

Quote the add-reaction example from the page.

Cite:

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

Counterfactual - no project detected:

Step 1c tier check on "reactions" -> tier-2 alone, no project context -> ask: "Is this about Chat message reactions or Feeds activity reactions?"

用户：

/stream how do I add reactions?

（在包含

stream-chat-react@^13.2.0

的React项目中）

步骤0（
stream
路由中）：意图分类——"how do I" + 无操作动词 + 存在项目上下文 -> 文档搜索，无需CLI前置操作。

步骤1 - 识别SDK：

无明确SDK -> 情况B。
步骤1a（项目检测）：找到
```
stream-chat-react@13
```
。
步骤1b：获取
```
llms.txt
```
，将
```
stream-chat-react
```
映射为Chat + React（UI），在
```
llms.txt
```
中找到slug
```
chat-sdk-react
```
，主版本号13。
步骤1c（层级）："reactions"为二级关键词，但项目已解析为Chat——继续操作。
步骤1d（版本）：用户未指定 -> 使用基础URL。
告知用户：「正在查看Chat React（从你的package.json中检测到）...」

步骤2 - 获取框架索引：

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

-> 返回200。

标题确认：
```
# React v13（Latest）
```
。

步骤3 - 查找并获取页面：

扫描索引查找"reaction" -> 找到「消息交互」和「自定义反应」。
用户提问为基础实操问题 -> 优先选择「消息交互」（基础）而非「自定义反应」（进阶）。

获取

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

。

步骤4 - 作答：

引用页面中的添加反应示例。

标注来源：

来源：[消息交互](https://getstream.io/chat/docs/sdk/react/.../message-interactions/)

反事实场景 - 未检测到项目：

步骤1c层级检查"reactions" -> 仅二级关键词，无项目上下文 -> 询问：「这是关于Chat消息反应还是Feeds活动反应？」

stream-docs

Original

Translation

Stream - Docs search (live SDK documentation)

Stream - 文档搜索（实时SDK文档）

Honesty rules (read before anything else)

诚信规则（操作前必读）

Invocation

调用方式

Shortcut: SDK named with no question

快捷方式：仅指定SDK无问题

Shortcut: bare /stream with no args

快捷方式：仅输入/stream无参数

Step 1: Identify the SDK

步骤1：识别SDK

Precedence

优先级

Resolution order for "question without named SDK"

「未指定SDK的问题」解析顺序

Step 1a - Project detection

步骤1a - 项目检测

Fallback probes (when project signals are missing)

回退探测（无项目信号时）

Multiple SDKs detected

检测到多个SDK

Step 1b - Resolve to a slug via llms.txt

步骤1b - 通过llms.txt解析为slug

Slug-name patterns (scanning hints)

Slug命名模式（扫描提示）

Framework-name normalization

框架名称标准化

npm packages -> product + framework

npm包 -> 产品+框架

Special case: stream-chat alone

特殊情况：仅stream-chat

Special case: @stream-io/node-sdk

特殊情况：@stream-io/node-sdk

Non-npm project files -> product + framework

非npm项目文件 -> 产品+框架

Step 1c - Inference tiers

步骤1c - 推理层级

Tier 1: Unambiguous (proceed and announce)

一级：无歧义（直接处理并告知用户）

Tier 2: Ambiguous (needs project context OR ask)

二级：有歧义（需项目上下文或询问用户）

Step 1d - Version handling (Chat SDKs only)

步骤1d - 版本处理（仅Chat SDK）

Step 2: Fetch the framework index

步骤2：获取框架索引

Step 3: Find and fetch the page

步骤3：查找并获取页面

Matching strategy

匹配策略

Step 4: Answer

步骤4：作答

When the docs cover it partially

当文档仅部分覆盖问题时

When the docs don't cover it at all

当文档完全未覆盖问题时

Cross-references to other skills

与其他技能的交叉引用

Recovery from failures

错误恢复

404 on framework index

框架索引返回404

404 on Chat SDK versioned URL

Chat SDK带版本的URL返回404

Fetched page doesn't answer the question

获取的页面无法解答问题

Empty or malformed framework index

框架索引为空或格式错误

User asks a follow-up that doesn't match any index page

用户后续提问无匹配索引页面

Conversation economy

会话资源优化

Worked example

实操示例

Shortcut: bare
`/stream`
with no args

快捷方式：仅输入
`/stream`
无参数

Step 1b - Resolve to a slug via
`llms.txt`

步骤1b - 通过
`llms.txt`
解析为slug

Special case:
`stream-chat`
alone

特殊情况：仅
`stream-chat`

Special case:
`@stream-io/node-sdk`

特殊情况：
`@stream-io/node-sdk`