Stream Android - skill router + execution flow
Rules: Read
once per session - every non-negotiable rule is stated there, nowhere else.
This file is the single entrypoint: intent classification, local project detection, and module pointers for Stream work in Android apps.
Step 0: Intent classifier (mandatory first - never skip)
Before any tool call, decide the track from the user's input alone - no probes first.
Signals -> track
| Signal in user input | Track |
|---|
| Explicit product/framework token: , , , , , , etc. | C - Reference lookup |
| Words "docs" or "documentation" around Stream Android/Compose work | C - Reference lookup |
| "How do I {X} in Compose/XML/Android?", "What does {SDK type/Composable/View/Fragment} do?" | C - Reference lookup |
| "Build me a new Android app", "create a Compose app", "new Android app" + Stream product | A - New app |
| "Add/integrate Stream into this app", "wire Chat/Video/Feeds into my Android project" | B - Existing app |
| "Install Stream packages", "set up Stream in Android Studio", "wire auth/token flow" with no broader feature request | D - Bootstrap / setup |
| Bare with no args | List the tracks briefly and wait |
Disambiguation flow
If the request is ambiguous between build/integrate and reference lookup, ask one short question and wait:
Do you want me to wire this into the project, or just map the Android SDK pattern and files?
After classification
- Tracks A, B, D -> run Step 0.5 (credentials) first, then Project signals once per session, then continue in and . Do not probe the project before credentials.
- Track C -> skip both steps if the product + UI layer are explicit. Only run Project signals on demand if the SDK or UI layer is ambiguous.
Step 0.5: Credentials, token, and seed data (tracks A, B, D only)
Order: intent classification -> Step 0.5 (this step) -> Project signals probe -> track work. Do this before running the Project signals shell command, even if a track table below lists "Detect" as phase 1. Run once per session for tracks A, B, and D. Skip for Track C.
- collect the Stream API key from the dashboard (or from the user)
- generate a user token via the Stream CLI (or accept one from the user)
- run any product-specific setup (Chat: optionally seed channels; Feeds: confirm feed groups; Video: nothing — calls are ephemeral)
Use the resulting API key and token in every code snippet — never placeholder strings. If a track A/B/D task reaches code work and credentials haven't been collected yet, return to
before continuing.
Project signals (tracks A/B/D - once per session; Track C on demand only)
Read-only local probe. Use it to detect whether the user is in an Android Studio / Gradle project, a Kotlin module, or an empty directory.
bash
bash -c 'echo "=== GRADLE ROOT ==="; find . -maxdepth 2 \( -name "settings.gradle.kts" -o -name "settings.gradle" -o -name "build.gradle.kts" -o -name "build.gradle" \) -print 2>/dev/null; echo "=== APP MODULES ==="; find . -maxdepth 3 -type f \( -name "build.gradle.kts" -o -name "build.gradle" \) -path "*/*/build.gradle*" -print 2>/dev/null; echo "=== VERSION CATALOG ==="; find . -maxdepth 3 -name "libs.versions.toml" -print 2>/dev/null; echo "=== MANIFESTS ==="; find . -maxdepth 4 -name "AndroidManifest.xml" -print 2>/dev/null; echo "=== EMPTY ==="; test -z "$(ls -A 2>/dev/null)" && echo "EMPTY_CWD" || echo "NON_EMPTY"'
Hold the result in conversation context. Don't re-run it unless the user changes directory or the project shape clearly changed.
Use the result to produce a one-line status, for example:
Compose app detected - app/build.gradle.kts - libs.versions.toml present - ready for Stream wiring
Multi-module Gradle project detected - preserve existing module layout
XML / View-based app detected - keep current UI layer unless the user asks to migrate
No Gradle project found - user needs to create the app in Android Studio first
Module map
| Track | Module(s) |
|---|
| A - New app | + + relevant reference files |
| B - Existing app | + + relevant reference files |
| C - Reference lookup | + relevant reference files |
| D - Bootstrap / setup | + |
Reference layout
Shared Android/Kotlin patterns live in
.
Product and UI-layer specifics live under
using a flat naming scheme that can grow with the full Stream Android surface:
- Reference:
references/<PRODUCT>-<UI_LAYER>.md
- Blueprints:
references/<PRODUCT>-<UI_LAYER>-blueprints.md
Current extracted modules:
- Chat + Compose:
references/CHAT-COMPOSE.md
+ references/CHAT-COMPOSE-blueprints.md
- Chat + XML: +
references/CHAT-XML-blueprints.md
- Video + Compose:
references/VIDEO-COMPOSE.md
+ references/VIDEO-COMPOSE-blueprints.md
- Feeds + Compose:
references/FEEDS-COMPOSE.md
+ references/FEEDS-COMPOSE-blueprints.md
Feeds has no pre-built UI components. covers the headless data SDK (FeedsClient, FeedState, ActivityState);
FEEDS-COMPOSE-blueprints.md
is custom Composable scaffolding driven by those state flows. Load both for any Feeds request.
Future Android product coverage should stay in this naming family instead of creating more top-level skills.
If the requested product/UI layer file is not bundled yet, say so plainly, use
for the shared Android patterns, and only switch to live docs if the user asks.
Track A - New app
Full detail: - use the
new-project path.
| Phase | Name | What you do |
|---|
| A1 | Detect | After Step 0.5 (credentials), run Project signals. If there is no Android app yet, tell the user to create one in Android Studio first. |
| A2 | Choose lane | Confirm product(s) and UI layer: Compose, XML/Views, or mixed. |
| A3 | Install + wire | Follow + , then load only the needed product references. |
| A4 | Verify | Confirm Gradle sync, lifetime, auth, and first rendered screen. |
Track B - Existing app
Full detail: - use the
existing-project path.
| Phase | Name | What you do |
|---|
| B1 | Detect | After Step 0.5 (credentials), run Project signals and inspect the existing app structure before editing. |
| B2 | Preserve | Keep the current UI layer, dependency strategy (version catalog vs inline), and navigation setup unless the user asks for a migration. |
| B3 | Integrate | Use for shared wiring, then load only the needed product reference files. |
| B4 | Verify | Confirm the requested Stream flow builds and renders inside the existing app. |
Track C - Reference lookup
Load only the relevant files for the requested product and UI layer.
- Shared lifecycle / auth / state patterns ->
- Chat Compose setup and gotchas ->
references/CHAT-COMPOSE.md
- Chat Compose screen structure ->
references/CHAT-COMPOSE-blueprints.md
- Chat XML setup and gotchas ->
- Chat XML screen structure ->
references/CHAT-XML-blueprints.md
- Video Compose setup and gotchas ->
references/VIDEO-COMPOSE.md
- Video Compose call/screen structure ->
references/VIDEO-COMPOSE-blueprints.md
- Feeds Compose SDK patterns ->
references/FEEDS-COMPOSE.md
- Feeds Compose blueprints ->
references/FEEDS-COMPOSE-blueprints.md
If the user asks for a product/UI-layer combo that is not bundled (e.g. Video XML, Feeds XML), say that clearly instead of inventing API details.
Track D - Bootstrap / setup
Use when the user wants the install and wiring path more than a feature build:
- run Step 0.5 (credentials) first
- detect the project shape
- choose Compose vs XML ownership
- install Stream packages with the project's existing dependency strategy (version catalog or inline)
- wire auth and lifetime via
- stop before product-specific UI if the user only asked for setup