stream-docs

What this skill does

# Stream - Docs search (live SDK documentation)

> **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`](../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.

---

## Honesty rules (read before anything else)

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

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.

---

## 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
```

### Shortcut: SDK named with no question

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 a