sanity-best-practices

Overview of sanity-best-practices skill

What the sanity-best-practices skill does

The sanity-best-practices skill is a Sanity-specific guidance pack for choosing the right modeling, query, Studio, and integration patterns before you build. It is most useful when you want a cleaner Sanity implementation, fewer avoidable refactors, and a faster path from rough idea to production-ready schema or frontend code.

Who should use it

Use this sanity-best-practices skill if you are working on a Sanity codebase and need help with schemas, GROQ, TypeGen, Visual Editing, Portable Text, localization, migrations, Functions, Blueprints, or framework integrations like Next.js, Nuxt, Astro, Remix, SvelteKit, Angular, Hydrogen, or the App SDK. It is a strong fit for frontend engineers, content platform builders, and teams reviewing an existing Sanity setup.

Why it is worth installing

The main value is decision quality: it helps you avoid generic prompts that miss Sanity-specific constraints, such as when to use defineQuery, how to structure queries for type safety, or when a feature belongs in Studio versus the frontend. If you need a sanity-best-practices guide that helps you build with fewer assumptions, this skill is more useful than a broad “help me with Sanity” prompt.

How to Use sanity-best-practices skill

Install and open the right files first

Use the sanity-best-practices install flow in your skills toolchain, then start with SKILL.md to confirm scope. After that, read only the topic files that match your task; the repository is organized as focused reference pages, not one long manual. For most tasks, the best first reads are references/get-started.md, references/schema.md, references/groq.md, references/typegen.md, and the relevant framework file.

Turn a vague task into usable input

The skill works best when you give it the concrete target, not just the technology. Instead of saying “improve my Sanity setup,” say: “Review this Next.js + Sanity page builder schema and suggest best-practice changes for TypeGen, GROQ, and Visual Editing.” For a sanity-best-practices usage request, include framework, Sanity version, current file, and the failure mode: broken types, slow queries, preview mismatch, or awkward content modeling.

Read the repository by task, not by habit

Use the reference file that matches the work:

• references/schema.md for content models, defineType, and defineField
• references/groq.md for query structure and query safety
• references/visual-editing.md for preview and Presentation setups
• references/typegen.md for typed schemas and typed queries
• references/nextjs.md, references/astro.md, references/nuxt.md, or other framework files for integration details
• references/functions.md and references/blueprints.md for event-driven automation and infrastructure

Use a prompt format that exposes constraints

A strong prompt usually includes: what you are building, what file you want reviewed, what framework you are using, and what must not change. Example: “Audit this post schema for localization and Portable Text best practices. Keep the public API stable, preserve existing field names where possible, and explain any breaking changes.” That level of specificity helps the skill produce actionable sanity-best-practices usage output instead of generic advice.

sanity-best-practices skill FAQ

Is this skill only for new Sanity projects?

No. The sanity-best-practices skill is just as useful when you are fixing an existing project, especially if you need to reduce schema drift, improve query maintainability, or align a frontend with Studio behavior.

How is this different from a normal prompt?

A normal prompt usually asks for an answer in isolation. This skill gives you a Sanity-centered workflow and reference path so the result reflects best practices for schemas, GROQ, previews, TypeGen, and framework integration rather than generic JavaScript advice.

Is it beginner-friendly?

Yes, if you already know you are working in Sanity. It is not a beginner onboarding course by itself, but it does reduce confusion by pointing you to the right topic file instead of making you guess which Sanity feature applies.

When should I not use it?

Skip it if your problem is not Sanity-specific, or if you only need a tiny one-off edit with no modeling, query, or integration decision. It is also not the right fit when you need a pure frontend debugging session unrelated to Sanity content flow.

How to Improve sanity-best-practices skill

Give the skill the real decision you need

The best results come from stating the actual tradeoff: “Should this field be a reference or inline object?” or “Should this query live in the frontend or be normalized in the schema?” That is better than asking for a broad cleanup, because the skill can then optimize for architecture, not just syntax.

Include the current shape of the code

Paste the schema, query, or integration snippet you want reviewed, plus enough surrounding context to see how content moves through the system. For sanity-best-practices for Frontend Development, include the framework, rendering mode, and whether you need preview, SSR, static build, or live updates.

Ask for the next iteration, not just the first answer

After the first pass, ask the skill to tighten for one outcome: type safety, editor experience, query performance, or content authoring clarity. Common failure modes are over-normalized schemas, under-specified GROQ filters, and frontend code that does not match Studio assumptions. The quickest improvement usually comes from adding constraints and asking for a revised version with fewer moving parts.

Use repository evidence to stay aligned

When in doubt, anchor your follow-up in the relevant reference file path, such as references/localization.md, references/migration.md, or references/page-builder.md. That keeps the sanity-best-practices skill grounded in the repository’s intended patterns and makes the final output easier to implement.