sanity-best-practices_skill

This skill guides Sanity developers in GROQ performance, schema design, and integration to optimize content workflows.

JavaScript

90

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill sanity-io/agent-toolkit --skill sanity-best-practices

SKILL.md3.1 KB

Overview

This skill collects practical Sanity development best practices across ten priority areas to help teams design, build, and optimize Sanity applications. It highlights high-impact rules for GROQ performance, schema design, Visual Editing, images, Portable Text, page builders, Studio setup, TypeGen, localization, and migrations. Use it as a checklist during development, reviews, and performance tuning.

How this skill works

The skill organizes rules by priority and category, each rule containing rationale, incorrect and correct examples, and extra context. It inspects schema design, GROQ queries, Studio configuration, image handling, Portable Text usage, page builder patterns, TypeGen setup, localization strategies, and migration guidance. Framework-specific notes (Next.js, Astro, Remix, etc.) are provided when available to show integration points and concrete code patterns.

When to use it

Writing or optimizing GROQ queries and data fetching
Designing content schemas and modeling relationships
Implementing Visual Editing and live preview workflows
Optimizing image delivery, Portable Text rendering, and page builders
Configuring Sanity Studio structure and developer ergonomics
Planning localization or migrating content from other systems

Best practices

Prioritize GROQ performance: limit projections, use filters before joins, and avoid fetching unused fields
Design schemas for data, not presentation: separate content from layout and keep reusable primitives
Enable Visual Editing carefully: expose only editable fields and validate preview payloads for consistency
Optimize images via Sanity image pipelines: use proper sizes, formats, and caching headers
Model Portable Text with minimal custom blocks and clear serializers to keep rendering predictable
Use TypeGen to enforce types in frontend code and keep schema/type generation in CI

Example use cases

Audit a slow page: identify expensive GROQ filters and reduce projected fields
Refactor a schema to decouple content from presentation for reuse across templates
Implement live preview in Next.js using preview tokens and lightweight GROQ queries
Build an image component that requests optimized sizes and formats from Sanity CDN
Set up TypeGen in CI to fail builds on schema/type drift before deployment

FAQ

Limit projections to required fields, apply filters early, paginate results, and avoid client-side loops that fetch additional documents.

When should I split content from presentation in schemas?

Split when the same content needs multiple layouts or channels; keep semantic fields in content types and layout metadata in page-builder or presentation-only documents.