CommunityCoding & Developmentgithub.com

emilkowalski/ask-sonner

Guide to Sonner, the React toast library — install and wire up the Toaster, pick the right toast() call, promise and loading toasts, updating, dismissing and persisting toasts, styling, theming and icons, positioning and multiple toasters. Use when working with Sonner or troubleshooting it — toasts that don't appear, appear twice, lose their styles, ignore Tailwind classes, sit behind a modal, or don't follow dark mode.

What is ask-sonner?

ask-sonner is a Claude Code agent skill that guide to Sonner, the React toast library — install and wire up the Toaster, pick the right toast() call, promise and loading toasts, updating, dismissing and persisting toasts, styling, theming and icons, positioning and multiple toasters. Use when working with Sonner or troubleshooting it — toasts that don't appear, appear twice, lose their styles, ignore Tailwind classes, sit behind a modal, or don't follow dark mode.

Works with~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/emilkowalski/skills/tree/main/skills/ask-sonner

Installed? Explore more Coding & Development skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

Working With Sonner

Initial Response

When this skill is first invoked without a specific question, respond only with:

I'm ready to help you set up, style, and troubleshoot Sonner, my knowledge comes from its author, Emil Kowalski.

Do not provide any other information until the user asks a question.

A guide skill for Sonner, the toast library. When a task involves Sonner — wiring it up, rendering toasts, styling them, or fixing them — answer from this file first. Full prop tables for <Toaster /> and toast() live in API.md; read it when you need an exact prop name, type, or default.

Setup

Two pieces, and only two:

  1. One <Toaster />, mounted once, as close to the root as possible (in Next.js: layout.tsx — it works inside server components). Never render it per-page or conditionally; a second mounted Toaster duplicates every toast.
  2. toast() called from client code — event handlers, effects, callbacks. It's a plain function, no hook or provider needed, but it does nothing on the server: in a server action, return the result and call toast() in the client code that receives it.
import { Toaster } from 'sonner'; // once, in layout
import { toast } from 'sonner';   // anywhere client-side

Picking the right call

You wantCall
Plain messagetoast('Title') — add { description } for a second line
Success / error / info / warning icontoast.success('…'), toast.error('…'), etc.
Spinner while you manage state yourselftoast.loading('…'), then update it by id
Loading → success/error tied to a promisetoast.promise(promise, { loading, success, error }) — success/error accept functions receiving the resolved value/error
Button that does something{ action: { label, onClick } } — closes the toast unless onClick calls event.preventDefault(); cancel is the secondary variant
Custom JSX, default toast shelltoast(<jsx />)
Custom JSX, no styles at alltoast.custom((t) => <jsx />) — headless, t gives you the id to dismiss

Recipes

Update a toast — call toast() again with the same id; only the props you pass change. Switching to toast.success(…, { id }) changes the type. This is how loading → success flows work without toast.promise:

const id = toast.loading('Uploading…');
toast.success('Uploaded', { id });

Persist{ duration: Infinity }. Dismisstoast.dismiss(id), or toast.dismiss() for all. Read active toastsuseSonner() in React, toast.getActiveToasts() outside it.

Links or components in the text — pass a function for the title or description: toast(() => <a href="…">View</a>).

Multiple toasters — give each an id and target with toast('…', { toasterId: 'canvas' }). Without toasterId, every toaster renders the toast.

Close callbacksonDismiss fires on close button or swipe; onAutoClose fires on timeout. They are separate; there is no single "closed" callback.

Styling — the escalation ladder

Climb only as far as the change requires; jumping to the top rung too early is fine (it's the recommended end state), lingering in the middle is not.

  1. Defaults — plus richColors on the Toaster for colorful success/error, invert to flip against the theme.
  2. Inline tweakstoastOptions={{ style: {…} }} on the Toaster for all toasts, or style per toast() call.
  3. Classes on partstoastOptions={{ classNames: { toast, title, description, actionButton, cancelButton, closeButton } }}. Sonner's injected styles win the cascade, so every class needs !important (Tailwind: !text-red-900). If you're marking more than a few things important, stop — go headless.
  4. Headlesstoast.custom() with your own JSX, keeping Sonner's positioning, stacking, and swipe. The recommended approach for a design-system toast: wrap it in your own toast() abstraction. (unstyled: true exists as a halfway house, but headless gives more control for the same effort.)

Icons — swap defaults per-type with the Toaster's icons prop, per-toast with icon, remove with null.

Themetheme defaults to 'light' and does not track the OS. Pass theme="system", or wire your theme provider: <Toaster theme={resolvedTheme} /> from next-themes.

Troubleshooting

SymptomCause → fix
Toast never appearsNo <Toaster /> mounted, or it unmounted (conditional render, per-page placement). Mount one at the root. If calling from a server action: toast() is client-only — call it with the action's result on the client.
Same toast appears twiceTwo Toasters mounted (layout and page) — keep one. Or toast() fired in an effect under React StrictMode's dev double-invoke — fire from the event handler instead, or pass a stable id so the second call updates rather than duplicates.
Tailwind/CSS classes have no effectDefault styles override them. Mark them !important, or use unstyled / headless (see the ladder above).
Toasts render completely unstyled (common in Astro, view transitions)Sonner's injected stylesheet was lost — import it explicitly in a layout: import 'sonner/dist/styles.css'.
Unstyled inside Shadow DOMStyles land in document.head, not the shadow root. Copy the style tag whose text includes [data-sonner-toaster] into the shadow root.
Toast behind a modal/overlay, or clippedAn ancestor creates a stacking context (transform, filter, overflow) or the overlay out-z-indexes the toaster. Move <Toaster /> to the document root, outside any dialog/portal container.
Dark mode ignoredtheme defaults to 'light' — set theme="system" or pass the resolved theme (see Theme above).
Success/error look gray, not green/redThat's the default. Add richColors to the Toaster.
Toast never closesduration: Infinity, dismissible: false, or a toast.promise whose promise never settles — the loading toast waits forever.
toast.promise stuck on loadingIt needs a promise (or a function returning one) as its first argument, and the promise must actually resolve/reject.
Swipe-to-dismiss goes the wrong way / doesn't workDirections derive from position. Override with swipeDirections on the Toaster.
Toast shows up in every toasterMultiple toasters need targeting: give each Toaster an id and pass toasterId in the toast() call.
Toasts too close to the screen edge on mobileoffset (desktop, default 32px) and mobileOffset (<600px, default 16px) — numbers, CSS strings, or per-side objects.

Individual skills in this repo

This repo contains 10 individual skills — each has its own dedicated page.

emilkowalski/animate

Build an animation from scratch, making the decisions in the order that determines whether it feels right — should it animate at all, what purpose, which tool, which properties, which curve and duration, how it interrupts, how it exits. Writes the implementation. Use when asked to animate something, add motion, make a component feel alive, or build a transition. For critiquing existing motion use review-animations; for auditing a whole codebase use improve-animations.

emilkowalski/animate-expo

Build animations in React Native and Expo, making the decisions in the order that determines whether they feel right — should it animate, which thread it runs on, which properties, spring or timing, how the gesture hands off, how it degrades. Writes the implementation with Reanimated, Gesture Handler, Expo Router and expo-haptics. Use when animating anything in an Expo app, adding gestures, sheets, screen transitions, press feedback or haptics, or fixing motion that stutters on device. For web animation use `animate`.

emilkowalski/animation-vocabulary

Reverse-lookup glossary that turns a vague description of a web animation or motion effect into its exact term ("the bouncy thing when a popover opens" → Pop in; "the iOS rubber-band scroll" → Rubber-banding). Use when the user asks "what's it called when…", or describes a motion effect without knowing its name and wants the right word to prompt an AI or designer with. For naming an effect, not designing or building one.

emilkowalski/apple-design

Apple's approach to interface design and fluid, physical motion, translated for the web. Use when building or reviewing gesture-driven UI, spring animations, drag/swipe/sheet interactions, momentum and interruptible transitions, translucent materials and depth, typography (optical sizing, tracking, leading), reduced-motion, or the design foundations (feedback, spatial consistency, restraint) behind Apple-style interfaces.

emilkowalski/find-animation-opportunities

Search a codebase or UI for places that don't animate but should, and reject everything that shouldn't. Read-only; it proposes motion with exact values, it does not implement it. Use when the user asks "what could be animated here?" or wants to "make this feel more alive". For fixing existing animations, use improve-animations or review-animations instead.

emilkowalski/improve-animations

Survey a codebase's animation and motion code as a senior motion advisor, then produce a prioritized audit and self-contained implementation plans for other agents (or cheaper models) to execute. Read-only on source code — it plans improvements, it does not apply them. Use when the user asks to "improve the animations", "audit the motion", "make this app feel better", or wants a roadmap of animation fixes rather than a review of a single diff.

emilkowalski/mobile-native

Make a web app feel native on a phone — the small CSS and meta-tag fixes that separate "a website in a browser" from something that feels installed. Covers sticky hover states, tap highlight flashes, the 100vh bug, inputs that zoom the page, laggy taps, pull-to-refresh hijacking scroll, content under the notch, long-press selecting button text, carousels that scroll the wrong way, mismatched status bars, and the rule that you test on real hardware. Use when a web app is being built for or reviewed on mobile, when something "works in Chrome but feels wrong on my phone", when building a PWA, a bottom sheet, a carousel, a full-screen layout, or any touch interaction. For motion itself use animate; for React Native use animate-expo.

emilkowalski/pick-ui-library

Pick the right library for a given frontend task from a curated, opinionated list — numbers, OTP inputs, charts, command menus, virtualization, drag and drop, toasts, state, styling, and more. Only runs when explicitly invoked; it does not trigger on its own.

emilkowalski/review-animations

Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned.

emilkowalski/write-swift

How to write modern Swift well — modeling with value types, Swift 6 data-race safety and approachable concurrency (@concurrent, main-actor-by-default, actors, task groups), protocols and generics (some vs any), API design, performance and ARC, Swift Testing, macros, and the modern language features agents don't know about yet. Use when writing, reviewing, or migrating Swift, or when a concurrency error, a hang, a data race, a retain cycle, or a performance problem needs fixing.

Related Skills