All skills
sanity-io avatar

/content-modeling-best-practices

@ad50ea4 official
by Sanitysanity-io/agent-toolkit187 stars
30

Structured content modeling guidance for schema design, content architecture, content reuse, references versus embedded objects, separation of concerns, and taxonomies across Sanity and other headless CMSes. Use this skill when designing or refactoring content types, deciding field shapes, debating reusable versus nested content, planning omnichannel content models, or reviewing whether a schema is too page-shaped or presentation-driven.

Use this Skill: https://skilld.dev/gh/sanity-io/agent-toolkit/content-modeling-best-practices

This session only. Nothing lands on disk.

referencestaxonomy-classification.md

≈852 tokens on demand. Your agent reads this file only when SKILL.md points to it.

Taxonomy and Classification

Organizing content with taxonomies enables filtering, navigation, and content relationships. Well-designed taxonomies scale; poorly designed ones become maintenance nightmares.

Types of Classification

Flat Taxonomy

Simple list of terms with no hierarchy.

Use for: Tags, simple categories Example: Blog tags: "javascript", "react", "tutorial"

defineType({
  name: 'tag',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string' }),
    defineField({ name: 'slug', type: 'slug' }),
  ]
})

Hierarchical Taxonomy

Terms with parent-child relationships.

Use for: Product categories, content sections Example: Electronics > Phones > Smartphones

defineType({
  name: 'category',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string' }),
    defineField({ name: 'slug', type: 'slug' }),
    defineField({ 
      name: 'parent', 
      type: 'reference', 
      to: [{ type: 'category' }],
      description: 'Parent category (leave empty for top-level)'
    }),
  ]
})

Faceted Classification

Multiple independent dimensions.

Use for: Complex filtering (e-commerce) Example: Filter by color AND size AND price range

// Multiple taxonomy types
defineField({ name: 'color', type: 'reference', to: [{ type: 'color' }] })
defineField({ name: 'size', type: 'reference', to: [{ type: 'size' }] })
defineField({ name: 'material', type: 'reference', to: [{ type: 'material' }] })

Design Principles

1. Mutual Exclusivity (When Appropriate)

Categories should be distinct. If items frequently belong to multiple categories, consider tags instead.

Categories: One primary classification Tags: Many optional classifications

2. User-Centric Naming

Use terms your audience uses, not internal jargon.

Bad: "Content Assets" (internal term) Good: "Resources" or "Downloads" (user term)

3. Balanced Depth

Too shallow: Everything lumped together Too deep: Users can't find anything

Rule of thumb: 3-4 levels max for hierarchies

4. Scalable Structure

Design for 10x growth. Will your structure work with 10,000 items?

Querying Taxonomies

Get all items in a category

*[_type == "product" && category._ref == $categoryId]

Get items in category OR children

// First get all descendant category IDs
*[_type == "product" && category._ref in 
  *[_type == "category" && (
    _id == $categoryId || 
    parent._ref == $categoryId ||
    parent->parent._ref == $categoryId
  )]._id
]

Get category tree

*[_type == "category" && !defined(parent)]{
  title,
  slug,
  "children": *[_type == "category" && parent._ref == ^._id]{
    title,
    slug,
    "children": *[_type == "category" && parent._ref == ^._id]{
      title,
      slug
    }
  }
}

Common Mistakes

Over-categorization

Creating a category for everything results in mostly-empty categories.

Fix: Start minimal, add categories as content grows.

Inconsistent Granularity

Some categories broad ("Technology"), others narrow ("React 18 Server Components").

Fix: Define clear criteria for category creation.

No Governance

Anyone can create taxonomy terms, leading to duplicates and inconsistency.

Fix: Limit who can create/edit taxonomy documents. Use validation.

Source: SKILL.md on GitHub

No alerts16d5 checks · Risk SAFE
  • Gen Agent Trust Hub16d

    This skill consists of purely instructional documentation regarding content modeling and schema design best practices for Sanity and headless CMS structures. It contains no executable scripts, system commands, external network connections, or data operations, and is completely safe.

  • Socket16d

    No alerts

  • Snyk16d

    Risk: LOW · No issues

  • Runlayer6mo

    5 files scanned · No issues

  • ZeroLeaks5mo

    Score: 93/100 · 2 sections analyzed

Signed by skilld at ad50ea4. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 2 weeks ago.

Activeupdated 6 months ago
  • sanity
  • headless-cms
  • content-modeling
  • schema-design
  • content-architecture
  • references
  • taxonomies
  • structured-content

README badge

README badge for sanity-io/agent-toolkit/content-modeling-best-practices

Guides schema design for Sanity and headless CMSes through principles like content-as-data, single source of truth, and editor-centric structure. Covers references vs embedded objects, separation of concerns, content reuse patterns, and taxonomy design to avoid page-shaped or presentation-driven schemas.

Generated from the current SKILL.md.

Does this skill apply to CMSes other than Sanity?
Yes. The skill covers general content modeling principles that apply to any headless CMS, with Sanity-specific implementation notes included where relevant.
What specific decisions does this skill help with?
It guides decisions on schema design, references versus embedded objects, content reuse patterns, taxonomy structures, and whether a model is too page-shaped or presentation-driven.
Does this skill provide code examples or just principles?
The skill provides structured guidance documents covering separation of concerns, reference vs embedding, content reuse, and taxonomy classification. It is principles-focused rather than code-focused.
Can I use this when refactoring an existing content model?
Yes. The skill is designed for both new projects and refactoring existing structures to improve reusability and flexibility.

Generated from the current SKILL.md. These answers refresh after source changes.