Rules every skill follows
Every skill in the pack follows the same rules, defined in skills/stream/RULES.md. They hold on every call, whether you reach a skill through /stream or invoke it directly, so the entry point never changes how generated code behaves. The platform packs add their own RULES.md on top for platform-specific concerns.
RULES.md has the full list; these are the ones you'll notice most.
Never log or echo secrets
API keys, server secrets and user tokens are routine in Stream code. The skills won't read, print, or hardcode them: they don't cat or grep a .env, and they never echo secrets to the terminal. The getstream CLI owns them: getstream env writes the key (and, for server targets, the secret) into the right file, and the server secret never reaches the client bundle.
Never auto-seed demo data
The skills never create demo users or sample content on their own. The token route upserts only the requesting user. Seeding is opt-in: it only happens when you explicitly ask for sample data.
Moderation review stays in the Dashboard
The skills never build an in-app moderation review queue, review panel, or flagged-item UI. Reviewing flagged content always happens in the Dashboard, which gives you versioning, review and audit. During scaffold the skills may configure blocklists and automod via the CLI, and generated apps are limited to end-user actions (report, block, mute).
Install with npm, and --legacy-peer-deps for Stream packages
For a new scaffold the skill installs with npm and passes --legacy-peer-deps for Stream packages, because the SDKs declare peer ranges a plain install rejects. It never uses bun. When adding Stream to an existing project, it matches whatever package manager is already there.
Keep React strict mode on
The skills keep strict mode enabled, because it catches real lifecycle bugs. They rely on the official client hooks (useCreateChatClient(), useCreateFeedsClient()) to stay strict-mode safe rather than disabling it.