Migrating from shadcn + custom AI components

You do not have to choose. Slipstream uses the same registry convention as shadcn, so the two coexist in one codebase — adopt Slipstream where AI surfaces need more than primitives, keep shadcn where it already works.

Why teams add Slipstream

Your agent reads a spec, not guesses

Every component ships a COMPONENT_MANIFEST; the MCP validate_usage tool checks generated JSX before it hits your diff. shadcn documents for humans only.

AI surfaces are already built

Conversation, PromptInput, streaming-safe Response, ToolCall, Confirmation, citations — the parts you would otherwise hand-roll per project.

Same install ergonomics

npx shadcn add works with Slipstream registry URLs — real source files in components/, yours to edit, exactly like shadcn.

Still stateless and accessible

No runtime lock-in, jest-axe on every component, dark mode through CSS variables — the standards you already hold shadcn to.

Strategy A — side-by-side (start here)

Add Slipstream next to your existing shadcn components. Nothing is renamed or removed.

bash

# packages for your app code
pnpm add @slipstream-ui/core @slipstream-ui/ai

# or copy source into your components dir (shadcn-compatible)
npx shadcn@latest add https://slipstreamui.com/registry/conversation.json
npx shadcn@latest add https://slipstreamui.com/registry/prompt-input.json

# give your coding agent the spec
pnpm add -D @slipstream-ui/mcp-server

tsx

// Before: shadcn primitives + your hand-rolled chat glue
// After: Slipstream owns the AI surface, shadcn keeps the rest
import { Conversation, PromptInput, Response } from '@slipstream-ui/ai';
import { Button } from '@/components/ui/button'; // still shadcn

export function Assistant() {
  /* your state */
}

Strategy B — converge shared primitives

Where a Slipstream primitive overlaps yours (Button, Input, Dialog…), you can either keep yours and map props, or copy the Slipstream source in and delete yours. The registry gives you the same source-copy workflow shadcn users expect — including the manifest JSON that travels with each component.

Strategy C — AI surfaces first

Short on time? Ship only the AI-facing pieces — Conversation, PromptInput, Response, MessageActions — and revisit the rest later. Migration is per-component by design: there is no global swap step to get wrong.

When to stay on shadcn alone

If your product has no generative surfaces and no agents writing UI, shadcn plus your own docs is a perfectly good system. Slipstream earns its place when code is generated by models or your UI is chat-shaped — that is where manifests, validation, and AI primitives pay off.

Installation paths

Packages, CLI, or registry — all three explained.

Agent integration

Wire validate_usage into your coding agent.

Was this page helpful?