home / skills / sanity-io / agent-toolkit / sanity-best-practices

sanity-best-practices skill

/skills/sanity-best-practices

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

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

Review the files below or copy the command above to add this skill to your agents.

Files (23)
SKILL.md
3.1 KB
---
name: sanity-best-practices
description: Comprehensive Sanity development best practices covering integration guides (Next.js, Nuxt, Astro, Remix, SvelteKit, Hydrogen), GROQ performance, schema design, Visual Editing, images, Portable Text, page builders, Studio configuration, TypeGen, localization, and migrations. Use this skill when building, reviewing, or optimizing Sanity applications.
license: MIT
metadata:
  author: sanity
  version: "1.0.0"
---

# Sanity Best Practices

Comprehensive best practices and integration guides for Sanity development, maintained by Sanity. Contains integration guides and topic references covering schema design, query optimization, and frontend integration.

## When to Apply

Reference these guidelines when:
- Setting up a new Sanity project or onboarding
- Integrating Sanity with a frontend framework (Next.js, Nuxt, Astro, Remix, SvelteKit, Hydrogen)
- Writing GROQ queries or optimizing performance
- Designing content schemas
- Implementing Visual Editing and live preview
- Working with images, Portable Text, or page builders
- Configuring Sanity Studio structure
- Setting up TypeGen for type safety
- Implementing localization
- Migrating content from other systems
- Building custom apps with the Sanity App SDK
- Managing infrastructure with Blueprints

## Quick Reference

### Integration Guides

- `get-started` - Interactive onboarding for new Sanity projects
- `nextjs` - Next.js App Router, Live Content API, embedded Studio
- `nuxt` - Nuxt integration with @nuxtjs/sanity
- `astro` - Astro integration with @sanity/astro
- `remix` - React Router / Remix integration
- `svelte` - SvelteKit integration with @sanity/svelte-loader
- `hydrogen` - Shopify Hydrogen with Sanity
- `project-structure` - Monorepo and embedded Studio patterns
- `app-sdk` - Custom applications with Sanity App SDK
- `blueprints` - Infrastructure as Code with Sanity Blueprints

### Topic Guides

- `groq` - GROQ query patterns, type safety, performance optimization
- `schema` - Schema design, field definitions, validation, deprecation patterns
- `visual-editing` - Presentation Tool, Stega, overlays, live preview
- `page-builder` - Page Builder arrays, block components, live editing
- `portable-text` - Rich text rendering and custom components
- `image` - Image schema, URL builder, hotspots, LQIP, Next.js Image
- `studio-structure` - Desk structure, singletons, navigation
- `typegen` - TypeGen configuration, workflow, type utilities
- `seo` - Metadata, sitemaps, Open Graph, JSON-LD
- `localization` - i18n patterns, document vs field-level, locale management
- `migration` - Content import overview (see also `migration-html-import`)
- `migration-html-import` - HTML to Portable Text with @portabletext/block-tools

## How to Use

Read individual reference files for detailed explanations and code examples:

```
references/groq.md
references/schema.md
references/nextjs.md
```

Each reference file contains:
- Comprehensive topic or integration coverage
- Incorrect and correct code examples
- Decision matrices and workflow guidance
- Framework-specific patterns where applicable

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

How do I reduce costly GROQ queries?

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.