Official agent skill

Sanity Live Cache Components

by sanity-io in sanity-io/ui

Integrates Sanity Live with Next.js Cache Components in next-sanity v13+ apps.

OfficialMITAuto-check passedDevelopment

Install Sanity Live Cache Components

skills CLI
$ npx skills add sanity-io/ui --skill sanity-live-cache-components -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install sanity-io/ui sanity-live-cache-components --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/sanity-io/ui.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/sanity-live-cache-components .claude/skills/sanity-live-cache-components && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
sanity-live-cache-components
GitHub stars
176
Token cost
~4.2k tokens
SKILL.md length
1,440 words
Files
5
Skills in repo
5
Repo updated
First seen
Licence
MIT

At a glance

Integrates Sanity Live with Next.js Cache Components in next-sanity v13+ apps.

  • Works in 5 steps: Install next-sanity@^13 → Configure next.config.ts → Configure defineLive and export helpers → …
  • Migrating a Next.js app to cacheComponents with Sanity
  • SKILL.md covers Where this skill fits, Prerequisites, Reference files and 1. Install next-sanity@^13, plus 6 more sections
  • Calls npx, npm and pnpm; needs SANITY_API_READ_TOKEN

What it does

Sanity Live Cache Components is an agent skill from sanity-io/ui, published by the product's own GitHub organization. Integrates Sanity Live with Next.js Cache Components in next-sanity v13+ apps. Sets up sanityFetch, a shared cachedSanity 'use cache' boundary, <SanityLive, Visual Editing, Presentation Tool, draft mode handling, and the three-layer (Page/Dynamic/Cached) component pattern with explicit perspective/stega prop-drilling. Sequences with the official Next.js skills (next-cache-components-adoption, next-cache-components-optimizer, next-partial-prefetching-adoption, next-dev-loop). Use when configuring or migrating a…

Its SKILL.md is about 4.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files (for example `reference/dynamic-segments.md`, `reference/layouts.md` and `reference/live-helpers.md`).

It sits in Development, covering Refactoring. It works with Next.js. The repository describes itself as: The Sanity UI design system. The licence is MIT.

When your agent uses it

  • Migrating a Next.js app to cacheComponents with Sanity
  • Adding sanityFetch
  • Wiring <SanityLive/<VisualEditing
  • Refactoring components that hardcode perspective/stega

Example prompts

  • “use cache”
  • “Use the sanity-live-cache-components skill to integrate Sanity Live with Next.js Cache Components in next-sanity v13+ apps”
  • “/sanity-live-cache-components”

Requirements

  • Node.js
  • A credential in SANITY_API_READ_TOKEN

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Install next-sanity@^13
  2. Configure next.config.ts
  3. Configure defineLive and export helpers
  4. Render in a root layout
  5. Apply the three-layer pattern to pages and layouts

What it can do on your machine

Read from SKILL.md and the folder at commit bcd7416. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx
    • npm
    • pnpm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • nextjs.org
    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • SANITY_API_READ_TOKEN

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Sanity Live Cache Components loads about 4.2k tokens when it runs. Until then it costs about 180 tokens; SKILL.md has 1,440 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~180
When it runs · the whole SKILL.md, loaded when a task matches
~4.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from sanity-io/ui at commit bcd7416, republished under its MIT licence (© sanity-io). 1,440 words, ~4,182 tokens.

Download SKILL.mdSave it as .claude/skills/sanity-live-cache-components/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.
name
sanity-live-cache-components
description
Integrates Sanity Live with Next.js Cache Components in next-sanity v13+ apps. Sets up sanityFetch, a shared cachedSanity 'use cache' boundary, <SanityLive>, Visual Editing, Presentation Tool, draft mode handling, and the three-layer (Page/Dynamic/Cached) component pattern with explicit perspective/stega prop-drilling. Sequences with the official Next.js skills (next-cache-components-adoption, next-cache-components-optimizer, next-partial-prefetching-adoption, next-dev-loop). Use when configuring or migrating a Next.js app to cacheComponents with Sanity, when adding sanityFetch, when wiring <SanityLive>/<VisualEditing>, or when refactoring components that hardcode perspective/stega.

Sanity Live + Cache Components

Wires next-sanity into a Next.js 16+ app with cacheComponents: true. Data is fetched with sanityFetch through a single shared 'use cache' boundary (cachedSanity), and <SanityLive> in the root layout revalidates cached content over an EventSource connection to Sanity Content Lake. Visual Editing and Presentation Tool are fully supported when draft mode is enabled.

Read the relevant guide in node_modules/next/dist/docs/ (when available) before writing code. If a guide conflicts with this skill, follow this skill.

This skill assumes familiarity with Cache Components fundamentals — 'use cache', cacheLife, cacheTag, and the cookies/headers/params rule — covered by the Cache Components guide (bundled offline under node_modules/next/dist/docs/). The only Sanity-relevant exception: await draftMode() is allowed inside 'use cache' (Next.js bypasses caching when draft mode is enabled — see the use cache reference).

Where this skill fits

Next.js ships official skills for the framework-generic workflows (see Setting up your project for AI coding agents). This skill covers only the Sanity surface and defers everything else to them. Install them from the Next.js repository:

bash
npx skills add vercel/next.js --skill next-dev-loop
npx skills add vercel/next.js --skill next-cache-components-adoption
npx skills add vercel/next.js --skill next-cache-components-optimizer
npx skills add vercel/next.js --skill next-partial-prefetching-adoption

When their rules apply — blocking-route triage, <Suspense> placement, loading-UI reuse, instant() regression tests, link prefetch audits — follow them; don't re-derive that guidance from here.

Recommended sequence when migrating an app:

  1. next-cache-components-adoption — enables cacheComponents: true and works the app to a passing build, route by route. Tell it to leave the Sanity surface to this skill:

    Adopt Cache Components in this project using the next-cache-components-adoption Skill. Defer draft mode handling and every sanityFetch / <SanityLive> call site to the sanity-live-cache-components skill: leave those routes opted out (export const instant = false) rather than refactoring the Sanity data fetching.

  2. This skill — set up defineLive and the live.ts helpers, refactor sanityFetch call sites to source perspective/stega correctly, wire <SanityLive>/<VisualEditing> and draft mode, then remove the remaining opt-outs on the deferred Sanity routes. Use the adoption skill's per-route loop and success bar for that removal (dev overlay clean, browser-verified, next build passes) — this skill supplies the Sanity-specific fixes, the loop mechanics are the adoption skill's.

  3. Either or both, optional follow-ups:

    • next-cache-components-optimizer — grows a route's static shell and guards it with an @next/playwright instant() test. Prompt: "Make the navigation to /<route> instant using the next-cache-components-optimizer Skill."
    • next-partial-prefetching-adoption — enables partialPrefetching and audits <Link prefetch={true}> usage. Prompt: "Adopt Partial Prefetching in this project using the next-partial-prefetching-adoption Skill."

    Nothing in this skill blocks either one: the three-layer pattern keeps routes fully prerenderable in the published branch, which is exactly the shell those skills grow and prefetch. Sanity content cached via cachedSanity also satisfies the "cached URL-dependent content" requirement for runtime prefetching.

Throughout all of it, verify changes at runtime with next-dev-loop — a passing compile doesn't prove what ended up in the static shell versus streamed.

Prerequisites

  • Next.js 16.3+ installed in the project (check package.json or run pnpm list next / npm ls next — don't use pnpm view next version, that reports the registry's latest, not what's installed). next-sanity v13 supports Next.js 16, but the official skills this skill sequences with require 16.3+.
  • AGENTS.md exists. On Next.js 16.3+, next dev auto-generates it (pointing agents at the bundled docs); on older versions follow the guide.
  • These environment variables are set:
    • NEXT_PUBLIC_SANITY_PROJECT_ID
    • NEXT_PUBLIC_SANITY_DATASET
    • SANITY_API_READ_TOKEN
  • Embedded Sanity Studio configuration (sanity.config.ts, sanity.cli.ts, anything under sanity/) needs no changes — this skill only touches the Next.js app surface.

Reference files

FileWhen to read
reference/live-helpers.mdFull client.ts / live.ts, cachedSanity, sanityFetch* and getDynamicFetchOptions details
reference/three-layer-pattern.mdThe Page → Dynamic → Cached pattern for page.tsx, including the searchParams variant
reference/layouts.mdNon-blocking data fetching inside layout.tsx
reference/dynamic-segments.mdHigh-performance [slug] routes: loading.tsx + partial generateStaticParams, or non-blocking dynamic params in a layout

1. Install next-sanity@^13

bash
npm install next-sanity@^13 --save-exact
Migrating an existing Sanity Live setup

If the app is already using defineLive, this skill is a refactor, not a rewrite. The 5-step sequence below still applies, but watch for these specific differences:

  • Don't overwrite client.ts or live.ts if they exist. Append missing options. Preserve any existing token and stega.* settings — see reference/live-helpers.md.
  • Search the codebase for hardcoded perspective: 'published' and stega: false in sanityFetch callsites and refactor them to source perspective/stega via getDynamicFetchOptions and the three-layer pattern.
  • Search for sanityFetch calls inside generateStaticParams → swap for cachedSanityStaticParams.
  • Search for sanityFetch calls inside generateMetadata / sitemap.ts / opengraph-image.tsx / etc. → swap for cachedSanityMetadata.
  • Search for sanityFetch calls directly inside a 'use server' function → swap for cachedSanity.
  • Verify there is exactly one <SanityLive> and one <VisualEditing> in the tree. Multiple renders are undefined behavior.

The "Anti-patterns to grep for" section at the bottom of this file lists the search patterns.


2. Configure next.config.ts

Enable cacheComponents and set cacheLife.default to sanity so default revalidation is 1 year (instead of 15 minutes). sanityFetch is optimized for on-demand revalidation and doesn't need time-based revalidation.

ts
// next.config.ts
import type {NextConfig} from 'next'
import {sanity} from 'next-sanity/live/cache-life'

const nextConfig: NextConfig = {
  cacheComponents: true,
  cacheLife: {default: sanity},
}

export default nextConfig

3. Configure defineLive and export helpers

Create src/sanity/lib/client.ts and src/sanity/lib/live.ts. The core of live.ts:

ts
// src/sanity/lib/live.ts (excerpt)
export const {SanityLive, sanityFetch} = defineLive({
  client,
  serverToken: token,
  browserToken: token,
  strict: true,
})

// The app's one shared 'use cache' boundary. `sanityFetch` calls
// `cacheTag`/`cacheLife` internally but doesn't create the boundary —
// this wrapper provides it once, so callers don't add their own.
export const cachedSanity: StrictDefinedFetchType = async (options) => {
  'use cache'
  return sanityFetch(options)
}

Full file contents (including client.ts, getDynamicFetchOptions, cachedSanityMetadata, cachedSanityStaticParams) and per-helper guidance: reference/live-helpers.md.

The helpers exported from live.ts:

HelperUsed in
cachedSanityThe default for fetching content anywhere server-side: pages, layouts, components, server actions
sanityFetchOnly inside a component that carries its own 'use cache' (also caches the rendered JSX)
cachedSanityMetadatagenerateMetadata, generateViewport, sitemap.ts, robots.ts, opengraph-image.tsx, etc.
cachedSanityStaticParamsgenerateStaticParams only
getDynamicFetchOptionsResolving perspective/stega outside any 'use cache' boundary
SanityLiveRendered once in a root layout

Show full SKILL.md (585 more words)Show less

4. Render <SanityLive> in a root layout

<SanityLive> and <VisualEditing> both belong in a layout.tsx, never a page.tsx. Both must be rendered at most once across the whole tree — duplicate renders are undefined behavior.

  • includeDrafts is required when defineLive is configured with strict: true (the recommended setup). TypeScript will surface the error if it's missing; pass includeDrafts={isDraftMode} so live revalidation includes drafts only in draft mode.
  • Preserve any existing optional callback props on <SanityLive> when migrating: onError, onWelcome, onReconnect. They are commonly wired to a toast/notification helper and silently dropping them regresses UX.
tsx
import {VisualEditing} from 'next-sanity/visual-editing'
import {draftMode} from 'next/headers'

// src/app/layout.tsx
import {SanityLive} from '@/sanity/lib/live'

export default async function RootLayout({children}: LayoutProps<'/'>) {
  const {isEnabled: isDraftMode} = await draftMode()
  return (
    <html lang="en">
      <body>
        {children}
        <SanityLive includeDrafts={isDraftMode} />
        {isDraftMode && <VisualEditing />}
      </body>
    </html>
  )
}
With an embedded Sanity Studio

If a route mounts NextStudio from next-sanity/studio (e.g. app/studio/[[...index]]/page.tsx), <SanityLive> must live in a layout the embedded studio doesn't share. Use route groups: put <SanityLive> in src/app/(website)/layout.tsx and keep the rest of the app under src/app/(website).


5. Apply the three-layer pattern to pages and layouts

Every route that should be statically prerendered uses the same shape:

text
Page/Layout (Layer 1: draftMode branch)
  ├── NOT draft mode → <CachedX perspective="published" stega={false} />  (no Suspense)
  └── draft mode → <Suspense fallback={...}>
                      <DynamicX params={params} />  (Layer 2: awaits dynamic APIs)
                        └── <CachedX perspective={p} stega={s} />  (Layer 3: fetches via cachedSanity)

Critical rules:

  • The cache boundary lives in live.ts (cachedSanity), so route files usually carry no 'use cache' directive at all. In particular the top-level Page / Layout must not have 'use cache' — it awaits params, searchParams, or cookies() (via getDynamicFetchOptions), and those dynamic APIs are forbidden inside 'use cache'. Adding 'use cache' to the top-level function is the most common failure mode — TypeScript and the runtime will both complain.
  • Layer 3 awaiting cachedSanity is enough for the whole route to prerender into the static shell — no <Suspense> needed in the published branch. perspective and stega are part of the wrapper's cache key automatically, so published and draft content never share a cache entry.
  • Only Layer 2 (rendered inside <Suspense>, draft mode only) touches dynamic APIs.

Pick the right reference for the file you're editing:


Verifying the Sanity surface

Use next-dev-loop after each refactor; the loop mechanics and success bar live in the official skills. The Sanity-specific things to confirm:

  • Published branch: the route prerenders fully (◐ or ○ in the build's route table) and content renders without a <Suspense> fallback flash.
  • Draft mode: enabling it streams draft content, <VisualEditing> overlays appear, and switching perspectives in Presentation Tool changes the rendered content.
  • Live updates: editing published content in the Studio revalidates the route (via <SanityLive>) without a rebuild.

Anti-patterns to grep for

When auditing an app, search for these and refactor:

  • perspective: 'published' and stega: false hardcoded together in a sanityFetch / cachedSanity call inside a shared component → use the three-layer pattern, source perspective/stega via getDynamicFetchOptions. (Layer 1's non-draft branch passing literal perspective="published" stega={false} props is the pattern, not a violation.)
  • sanityFetch( directly inside a function whose body begins with 'use server' → swap for cachedSanity (resolve perspective/stega via getDynamicFetchOptions first).
  • sanityFetch( inside generateStaticParams → swap for cachedSanityStaticParams.
  • sanityFetch( inside generateMetadata / generateViewport / sitemap.ts / robots.ts / opengraph-image.tsx etc. → swap for cachedSanityMetadata and resolve perspective via getDynamicFetchOptions.
  • sanityFetch( in a component without its own 'use cache' directive → swap for cachedSanity (or add the directive if caching the rendered JSX is intended).
  • await draftMode() immediately followed by await getDynamicFetchOptions() at the top of a page.tsx or layout.tsx without a sibling loading.tsx → move those dynamic-API calls into a child component wrapped in <Suspense> so the static shell can prerender.
  • More than one <SanityLive> or <VisualEditing> rendered in the tree → consolidate to a single render in the right layout.

© sanity-io, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 4 other files in .agents/skills/sanity-live-cache-components of sanity-io/ui.

  • SKILL.md
  • reference/dynamic-segments.md
  • reference/layouts.md
  • reference/live-helpers.md
  • reference/three-layer-pattern.md

Open the folder on GitHubat commit bcd7416

Compare with similar skills

Sanity Live Cache Components next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Sanity Live Cache Components compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Sanity Live Cache Components this skillsanity-io/ui176—~4.2kAutomated safety check: PassMIT
Nuqstrycompai/crm11k1 repos~1.7kAutomated safety check: PassMIT
React Best Practicesshapeshift/web2061 repos~2kAutomated safety check: PassMIT
Nextjs App Architecturejakubwarkusz/themes1231 repos~2.5kAutomated safety check: PassMIT
Clean Code Refactorerfike/fastapi-blog101—~402Automated safety check: PassMIT
Sanity Live Cache Componentsrobotostudio/turbo-start-sanity183—~2.8kAutomated safety check: PassMIT

Similar skills

  • Nuqs

    trycompai/crm

    nuqs (type-safe URL query state) best practices for Next.js and other React frameworks.

    11k GitHub starsUsed in 1 repo~1.7k tokens
    DevelopmentAuto-check passed
  • React Best Practices

    shapeshift/web

    Comprehensive React and Next.js performance optimization guide with 40+ rules for eliminating waterfalls, optimizing bundles, and improving rendering.

    206 GitHub starsUsed in 1 repo~2k tokens
    DevelopmentAuto-check passed
  • Nextjs App Architecture

    jakubwarkusz/themes

    Build or audit Next.js 16 App Router apps using a next-beats-style React Server Components architecture.

    123 GitHub starsUsed in 1 repo~2.5k tokens
    DevelopmentAuto-check passed
  • Clean Code Refactorer

    fike/fastapi-blog

    Skill for identifying code smells and refactoring code using Clean Code, SOLID, and DRY principles.

    101 GitHub stars~402 tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Sanity Live Cache Components

    robotostudio/turbo-start-sanity

    Integrates Sanity Live with Next.js Cache Components in next-sanity v13+ apps.

    183 GitHub stars~2.8k tokensUpdated 4 days ago
    DevelopmentAuto-check passed
  • React Refactor Tournament

    ragnar-pwninskjold/tech-snacks

    Review React/Next.js code against the real vercel-react-best-practices skill, backlog the performance findings keyed to actual rule ids + impact tiers, rank the most over-subscribed tiers, then fix…

    137 GitHub stars~1.3k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from sanity-io/ui

  • UI Demo

    sanity-io/ui

    Official

    Record polished UI demo videos using Playwright. An agent skill from sanity-io/ui.

    176 GitHub starsUsed in 4 repos~3.8k tokens
    Auto-check passed
  • Official

    Drive a Next.js route to instant navigation by setting up an agentic loop, under Cache Components / PPR, on initial load (hard navigation) and client-side navigation (soft navigation).

    176 GitHub starsUsed in 6 repos~6.3k tokens
    Auto-check passed
  • Official

    Turn on Partial Prefetching in a Next.js app and work through the insights it surfaces.

    176 GitHub starsUsed in 2 repos~5.8k tokens
    Auto-check passed
  • React Devtools MCP

    sanity-io/ui

    Official

    Inspect and profile the React component tree of a running Storybook story through chrome-devtools-mcp (React DevTools over the Chrome DevTools Protocol, via react-devtools-cdt-mcp).

    176 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Sanity Live Cache Components

What does Sanity Live Cache Components do?

Integrates Sanity Live with Next.js Cache Components in next-sanity v13+ apps. Sanity Live Cache Components is an agent skill from sanity-io/ui, published by the product's own GitHub organization.js Cache Components in next-sanity v13+ apps.

When should I use Sanity Live Cache Components?

Sanity Live Cache Components fits situations like: migrating a Next.js app to cacheComponents with Sanity; adding sanityFetch; wiring <SanityLive/<VisualEditing; refactoring components that hardcode perspective/stega.

How do I install Sanity Live Cache Components in Claude Code?

Run `npx skills add sanity-io/ui --skill sanity-live-cache-components -a claude-code`. Or copy the skill folder (.agents/skills/sanity-live-cache-components in sanity-io/ui) into .claude/skills/sanity-live-cache-components in your project. Claude Code loads it when a task matches its description.

How do I install Sanity Live Cache Components in Codex?

Run `npx skills add sanity-io/ui --skill sanity-live-cache-components -a codex`. Or copy the skill folder (.agents/skills/sanity-live-cache-components in sanity-io/ui) into .agents/skills/sanity-live-cache-components in your project. Codex loads it when a task matches its description.

Can I use Sanity Live Cache Components in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add sanity-io/ui --skill sanity-live-cache-components -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/sanity-live-cache-components, .gemini/skills/sanity-live-cache-components, .github/skills/sanity-live-cache-components and .opencode/skills/sanity-live-cache-components in your project.

What does Sanity Live Cache Components need to run?

Going by SKILL.md and its folder, Sanity Live Cache Components needs the command-line tools its instructions call (npx, npm and pnpm) and credentials named SANITY_API_READ_TOKEN. Our summary lists: Node.js; A credential in SANITY_API_READ_TOKEN.

Does Sanity Live Cache Components access the network?

SKILL.md names 2 domains. As links in the text: nextjs.org and github.com. This is read from the text; nothing was executed.

Is Sanity Live Cache Components safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Sanity Live Cache Components use?

Sanity Live Cache Components is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Sanity Live Cache Components use?

About 4.2k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Sanity Live Cache Components?

Skills that share tags, products or a category with Sanity Live Cache Components: Nuqs (trycompai/crm, 11k stars), React Best Practices (shapeshift/web, 206 stars), Nextjs App Architecture (jakubwarkusz/themes, 123 stars) and Clean Code Refactorer (fike/fastapi-blog, 101 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Sanity Live Cache Components?

sanity-io (a GitHub organization, an official publisher) maintains it in sanity-io/ui, which has 176 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 8, 2026.

Source: sanity-io/ui on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.