• Components → run

  design-matching.md

  : read its procedure half in full — everything above the

  # Reference

  divider (Steps 1–5; it may span two Reads, so page past a mid-procedure truncation) — then Grep its Reference half per region while implementing.
• Custom (livestream / overlay / bespoke) → run

  custom-ui.md

  instead — same region-by-region rigor, different mechanism.

1. Theming —

   StreamTheme

   (a

   ThemeExtension

   on

   MaterialApp.theme.extensions

   ) owns design foundations (spacing / radius / typography / colors) and all fine-grained/leaf styling including the whole message row (

   messageItemTheme

   bubble/text/attachment/metadata,

   reactionsTheme

   ,

   reactionPickerTheme

   ,

   avatarTheme

   ,

   textInputTheme

   ,

   mediaViewerTheme

   , …), while

   StreamChatThemeData

   (passed to

   StreamChat(themeData:)

   ) owns only the chat composite-widget slots (the three headers, message-list background/wallpaper, channel-list item, quoted message, thread tile, poll themes).
2. Widget replacement — the component factory, populated via core named slots on

   StreamComponentBuilders(...)

   (~48 leaf slots:

   messageBubble

   ,

   messageText

   ,

   reactions

   ,

   reactionPicker

   ,

   mediaViewer

   ,

   jumpToUnreadButton

   ,

   textInput

   ,

   avatar

   , …) and chat slots via

   streamChatComponentBuilders(...) → extensions:

   (~30 composite slots:

   messageItem

   ,

   messageComposer

   + sub-slots,

   channelListItem

   , per-attachment builders, …), passed to

   StreamChat(componentBuilders: StreamComponentBuilders(...))

   (global) or

   StreamComponentFactory(builders: …, child: …)

   (scoped); plus per-widget builders (

   messageBuilder

   ,

   itemBuilder

   ) for a single instance.

• (a) overriding a composite widget (

  messageItem

  builder,

  messageComposer

  builder,

  messageBuilder

  on

  StreamMessageListView

  ) silently drops the sub-features the default rendered — the incoming-message avatar, grouping, reactions, replies, status, or the send/voice/edit/slow-mode button — unless you read the default's

  build()

  and reproduce them (grouping state is available inside a custom

  messageItem

  via

  StreamMessageLayout.of(context)

  );
• (b) model-driven title logic must live in one shared helper used by both the channel list

  itemBuilder

  and the header, so the two surfaces cannot diverge;
• (c) route deliberately — bubble padding / color / shape live on

  StreamTheme

  (

  StreamTheme.messageItemTheme.bubble

  ); structural changes (send button outside the field, metadata inside the bubble, a bubble tail, a Slack-style flat row) need widget replacement (component factory or a per-widget builder).

design-matching.md

stream_chat_flutter

StreamTheme

StreamChatThemeData

StreamComponentBuilders

streamChatComponentBuilders

StreamComponentFactory

design-matching.md

stream_chat_flutter_core

livestream

stream_chat_flutter_core

stream_chat_flutter

custom-ui.md

StreamTheme

StreamChatThemeData

custom-ui.md

messageItem

design-matching.md

messaging

livestream

RULES.md

Does this chat look like a standard messenger (channel list + bubbles), or a bespoke surface like livestream/overlay chat? It decides whether we customize the pre-built components or build custom UI on

stream_chat_flutter_core

.

Do you want me to wire this into the project, or just map the Flutter SDK pattern and widgets?

• Tracks A, B, D -> run Project signals once per session, then continue in

  builder.md

  and

  sdk.md

  . If the styling-depth flag was raised, run the design-match phase alongside per the UI-strategy decision —

  design-matching.md

  for the pre-built components (the common case; read its procedure half in full — everything above the

  # Reference

  divider, which may span two Reads — then Grep its Reference half per region) or

  custom-ui.md

  for a bespoke

  stream_chat_flutter_core

  surface (design-match rigor is a mandatory phase, not an optional add-on).
• Track C -> skip the probe if the product + package are explicit. Only run it on demand if the SDK layer is ambiguous.
• Track M -> run

  sendbird-migration.md

  : detect the existing Sendbird integration shape, swap packages/init/views/channels/messages, re-apply theming via the two axes, and verify design + functional fidelity per screen against the Sendbird original. Reuses Step 0.5 credentials and

  design-matching.md

  /

  custom-ui.md

  rigor; hands off to the shared data-migration runbook when the code migration is done.

To wire everything up with real data, I need a few quick answers:

1. Credentials - Should I fetch your API key from the dashboard and generate a token via the Stream CLI, or will you paste them yourself?
2. Token expiry - If I'm generating the token: should it expire? (e.g.

   1h

   ,

   1d

   ,

   30m

   ) or never expire?
3. Seed channels - Should I pre-create a few channels with random usernames so the app has something to show immediately?

If you want to handle everything yourself, just paste your API key and token and tell me whether to seed channels.

To wire everything up, I need a couple of quick answers:

1. Credentials - Should I fetch your API key from the dashboard and generate a token via the Stream CLI, or will you paste them yourself?
2. Token expiry - If I'm generating the token: should it expire? (e.g.

   1h

   ,

   1d

   ,

   30m

   ) or never expire?

If you want to handle everything yourself, just paste your API key and token.

Guest-viewer requirement — surface this BEFORE building any app that signs viewers in as guests. A guest connects with the

guest

role, which by default has minimal capabilities. On the

livestream

call type guests cannot even read or join a call until the integrator grants those capabilities to the

guest

role. When a guest-based viewer flow is in scope, tell the integrator it is a prerequisite to grant the

guest

role

read-call

and

join-call

(plus

create-call

if a viewer may open the call before the host) on the relevant call type via Stream Dashboard → Video & Audio → Call Types → <type> → Roles & Permissions (or the API), or to use authenticated

User.regular

viewers instead. Details:

references/VIDEO-FLUTTER.md

→ Guest users, and

references/LIVESTREAM-FLUTTER.md

→ Roles, permissions, and backstage security.

To wire everything up, I need a few quick answers:

1. Credentials - Should I fetch your API key from the dashboard and generate a token via the Stream CLI, or will you paste them yourself?
2. Token expiry - If I'm generating the token: should it expire? (e.g.

   1h

   ,

   1d

   ,

   30m

   ) or never expire?
3. Feed groups - I need to create 3 feed groups in your Stream project (user, timeline, notification). Should I set these up automatically, or have you already created them?
4. Seed posts - Should I add a few sample posts so the feed has content from the first run?

If you want to handle credentials yourself, just paste your API key and token.

getstream api CreateFeedGroup --request '{"id": "user", "type": "flat"}'
getstream api CreateFeedGroup --request '{"id": "timeline", "type": "flat"}'
getstream api CreateFeedGroup --request '{"id": "notification", "type": "notification"}'

Please create these in Stream Dashboard → Activity Feeds → Feed Groups:

user

(Flat),

timeline

(Flat),

notification

(Notification).

main

connect()

1. _setupFollows(client)

   — always called, unconditionally. Makes

   timeline

   follow

   user

   so the user's own posts appear there. Do not merge this into seed logic — once seed data exists the guard returns early and the follow call never runs.

2. _seedPosts(client)

   — only if the user said yes to seeding. Adds sample activities and exits early if data already exists.

references/FEEDS-FLUTTER.md

stream_feeds: ^0.5.1

stream_feed

stream_feed_flutter_core

messaging

getstream api UpdateUsers --request '{
  "users": {
    "<token_user_id>": {"id": "<token_user_id>", "name": "<Display Name>"},
    "alice": {"id": "alice", "name": "Alice"},
    "bob":   {"id": "bob",   "name": "Bob"},
    "carol": {"id": "carol", "name": "Carol"},
    "dave":  {"id": "dave",  "name": "Dave"}
  }
}'

getstream api GetOrCreateChannel --type messaging --id <channel-id> \
  --request '{"data": {"custom": {"name": "<Channel Name>"}}}'

general

random

team-alpha

add_members

Filter.in_('members', [userId])

getstream api UpdateChannel --type messaging --id <channel-id> \
  --request '{
    "add_members": [
      {"user_id": "<token_user_id>"},
      {"user_id": "alice"},
      {"user_id": "bob"}
    ],
    "user_id": "<token_user_id>"
  }'

general

random

team-alpha

alice

bob

carol

dave

Filter.in_('members', [tokenUserId])

Created channels:

general

(token_user, alice, bob),

random

(token_user, carol, dave),

team-alpha

(token_user, alice, carol)

• Never put the API secret in app code - the CLI uses it server-side only.
• Never invent or fabricate credentials.
• Never ask "should I continue?" between Step A, B, C, and D - execute the whole sequence once the user's upfront answers are in.

bash -c 'echo "=== FLUTTER ==="; find . -maxdepth 2 -name "pubspec.yaml" -print 2>/dev/null; echo "=== STREAM ==="; grep -rE "stream_chat|stream_video|stream_feed" . --include="pubspec.yaml" -l 2>/dev/null; echo "=== EMPTY ==="; test -z "$(ls -A 2>/dev/null)" && echo "EMPTY_CWD" || echo "NON_EMPTY"'

• Flutter app detected - stream_chat_flutter already in pubspec.yaml

• Flutter app detected - stream_video_flutter already in pubspec.yaml

• Flutter app detected - stream_feed already in pubspec.yaml

• Flutter app detected - no Stream dependency yet, ready to install

• No Flutter project found - user needs to run flutter create first

pubspec.yaml

version:

pubspec.lock

stream_chat_flutter

stream_chat_flutter_core

Your project uses

stream_chat_flutter

v<found>. These instructions cover v10. A lot changed between v9 and v10 (widget names, controllers, theming, reaction/delete APIs). The official migration guides are at https://github.com/GetStream/stream-chat-flutter/tree/master/migrations — refer to the relevant version's guide for step-by-step instructions. Once you're on v10, I can continue with the full feature set.

^10.0.0

^10.0.0

builder.md

sdk.md

builder.md

sdk.md

sdk.md

builder.md

sdk.md

sendbird-migration.md

design-matching.md

custom-ui.md

sdk.md

../stream/sendbird-data-migration.md

design-matching.md

# Reference

custom-ui.md

Feeds note (Track A/B): Use Twitter-style UI by default. Only deviate if the user explicitly requests a different style (e.g., "Instagram grid", "Reddit-style votes").

sdk.md

references/

• Reference:

  references/<PRODUCT>-<PACKAGE>.md

• Blueprints:

  references/<PRODUCT>-<PACKAGE>-blueprints.md

• Chat + pre-built UI (

  stream_chat_flutter

  ):

  references/CHAT-FLUTTER.md

  +

  references/CHAT-FLUTTER-blueprints.md

• Chat + custom UI (

  stream_chat_flutter_core

  ):

  references/CHAT-CORE.md

  +

  references/CHAT-CORE-blueprints.md

• Chat advanced (push, offline, lifecycle — both UI tiers):

  references/CHAT-ADVANCED-FLUTTER.md

  +

  references/CHAT-ADVANCED-FLUTTER-blueprints.md

  - push notifications, offline/local persistence, connection lifecycle & backgrounding
• Video (

  stream_video_flutter

  ):

  references/VIDEO-FLUTTER.md

  +

  references/VIDEO-FLUTTER-blueprints.md

• Livestream (

  stream_video_flutter

  ):

  references/LIVESTREAM-FLUTTER.md

  +

  references/LIVESTREAM-FLUTTER-blueprints.md

• Video advanced use cases (

  stream_video_flutter

  ):

  references/VIDEO-ADVANCED-FLUTTER.md

  +

  references/VIDEO-ADVANCED-FLUTTER-blueprints.md

  - audio rooms, multicall, chat+video, livestream feed, querying/events/preferences/moderation
• Ringing / incoming calls + push (

  stream_video_flutter

  +

  stream_video_push_notification

  ):

  references/RINGING-FLUTTER.md

  +

  references/RINGING-FLUTTER-blueprints.md

  - outgoing ring, foreground/background/terminated incoming, CallKit (iOS) + FCM (Android)
• Feeds (

  stream_feed

  /

  stream_feed_flutter_core

  ):

  references/FEEDS-FLUTTER.md

  +

  references/FEEDS-FLUTTER-blueprints.md

• Shared lifecycle / auth / state / client-ownership patterns ->

  sdk.md

• Chat advanced production concerns — push notifications, offline/local persistence, connection lifecycle & backgrounding (both UI tiers) ->

  references/CHAT-ADVANCED-FLUTTER.md

• Chat advanced wiring blueprints (FCM setup + background handler, persistence init, lazy-connect gate) ->

  references/CHAT-ADVANCED-FLUTTER-blueprints.md

• Chat pre-built UI setup, widgets, theming, member/user lists, message search, composer flags (voice/polls/drafts), filter operators, permissions ->

  references/CHAT-FLUTTER.md

• Chat pre-built UI widget blueprints ->

  references/CHAT-FLUTTER-blueprints.md

• Chat custom UI setup and controllers ->

  references/CHAT-CORE.md

• Chat custom UI widget blueprints ->

  references/CHAT-CORE-blueprints.md

• Video setup, call types, controls, state, StreamCallContainer ->

  references/VIDEO-FLUTTER.md

• Video widget blueprints (entry point, join, call container, controls, participant tile) ->

  references/VIDEO-FLUTTER-blueprints.md

• Livestream SDK patterns (call type, backstage, goLive/stopLive, HLS) ->

  references/LIVESTREAM-FLUTTER.md

• Livestream widget blueprints (mode selection, creator, WebRTC viewer, HLS viewer) ->

  references/LIVESTREAM-FLUTTER-blueprints.md

• Video advanced patterns (audio rooms, multicall, chat+video wiring, queryCalls, call events, preferences, moderation, session timers, network handling) ->

  references/VIDEO-ADVANCED-FLUTTER.md

• Video advanced use-case blueprints (audio room screen, TikTok-style livestream feed, floating call panel, chat-with-video) ->

  references/VIDEO-ADVANCED-FLUTTER-blueprints.md

• Ringing SDK patterns (push-enabled init, outgoing ring, incoming foreground/background/terminated, CallKit/FCM setup, accept/reject/end, customization, missed calls) ->

  references/RINGING-FLUTTER.md

• Ringing blueprints (push init, background FCM handler, home-screen observers, outgoing ring, call screen, iOS AppDelegate, Android manifest/Gradle) ->

  references/RINGING-FLUTTER-blueprints.md

• Feeds SDK setup, StreamFeedClient, feed types, activities, reactions, follow/unfollow, realtime ->

  references/FEEDS-FLUTTER.md

• Feeds widget blueprints (Twitter-style by default: home feed, activity card, compose, profile, notifications; also Instagram/Reddit variants) ->

  references/FEEDS-FLUTTER-blueprints.md

• detect the project shape
• choose

  stream_chat_flutter

  vs

  stream_chat_flutter_core

• add Stream dependencies to

  pubspec.yaml

  and run

  flutter pub get

• wire

  StreamChatClient

  and the

  StreamChat

  widget via

  sdk.md

• complete platform setup (Android permissions, iOS Info.plist keys) for the chosen packages
• stop before product-specific UI if the user only asked for setup