Content Modeling Design Suite

Structured content modeling toolkit for designing flexible, reusable content architectures for CMS platforms, headless content APIs, and multi-channel content delivery systems.

When to Use This Skill

Choose Content Modeling when:

• Designing content types and schemas for a CMS (Contentful, Sanity, Strapi)
• Building headless content APIs for multi-platform delivery
• Migrating content from one CMS to another
• Creating content governance models for editorial teams
• Designing content relationships and taxonomies

Consider alternatives when:

• Need database schema design — use database modeling tools
• Need static site content — use file-based Markdown/MDX
• Need e-commerce catalog — use commerce-specific platforms

Quick Start

Copy
# Activate content modeling
claude skill activate expert-content-modeling-design-suite

# Design content model
claude "Design a content model for a SaaS marketing site with blog, docs, and landing pages"

Example: Content Model Design

Copy
// Content type definitions (CMS-agnostic)
interface BlogPost {
  // System fields
  id: string;
  slug: string;
  createdAt: Date;
  updatedAt: Date;
  publishedAt: Date | null;
  status: 'draft' | 'review' | 'published' | 'archived';

  // Content fields
  title: string;                    // Required, max 100 chars
  excerpt: string;                  // Required, max 200 chars
  body: RichText;                   // Structured rich text
  featuredImage: MediaAsset;        // Required
  author: Reference<Author>;        // Required, single reference
  category: Reference<Category>;    // Required
  tags: Reference<Tag>[];           // 1-5 tags
  relatedPosts: Reference<BlogPost>[]; // 0-3 related posts

  // SEO fields
  seo: {
    metaTitle: string;              // Max 60 chars
    metaDescription: string;        // Max 155 chars
    ogImage: MediaAsset;            // Optional override
    noIndex: boolean;
  };

  // Localization
  locale: string;                   // 'en-US', 'fr-FR'
  localizedVersions: Reference<BlogPost>[];
}

interface Author {
  name: string;
  role: string;
  avatar: MediaAsset;
  bio: string;
  socialLinks: { platform: string; url: string }[];
}

interface Category {
  name: string;
  slug: string;
  description: string;
  parentCategory: Reference<Category> | null;
}

// Page builder with modular sections
interface LandingPage {
  title: string;
  slug: string;
  sections: ContentSection[];
  seo: SEOFields;
}

type ContentSection =
  | HeroSection
  | FeatureGridSection
  | TestimonialSection
  | CTASection
  | FAQSection
  | PricingTableSection;

interface HeroSection {
  type: 'hero';
  headline: string;
  subheadline: string;
  ctaText: string;
  ctaLink: string;
  backgroundImage: MediaAsset;
}

Core Concepts

Content Model Components

Component	Description	Example
Content Types	Templates defining field structure	Blog Post, Page, Author
Fields	Individual data points on a type	Title (text), Body (rich text), Image (media)
References	Links between content types	Blog Post → Author, Category
Taxonomies	Classification systems	Categories, Tags, Content Types
Components	Reusable field groups	SEO fields, Address, Social Links
Locales	Language/region variants	en-US, fr-FR, de-DE

Field Types

Type	Description	Validation
Short Text	Titles, names (single line)	Max length, pattern
Long Text	Descriptions, excerpts	Max length
Rich Text	Formatted body content	Allowed marks, embeds
Number	Counts, prices, ratings	Min/max, decimal places
Date	Publish dates, events	Range, required
Boolean	Toggles, flags	Default value
Media	Images, files, videos	File types, max size
Reference	Link to another content entry	Content type filter
JSON	Structured data, config	Schema validation
Enum	Fixed option list	Allowed values

Configuration

Parameter	Description	Default
cms_platform	Target CMS: contentful, sanity, strapi	contentful
locales	Supported locales	["en-US"]
preview_enabled	Enable draft preview	true
versioning	Content versioning strategy	major
webhooks	Post-publish webhook targets	[]
validation_strictness	Field validation: strict, moderate, loose	strict

Best Practices

1. Design for multi-channel delivery from the start — Content should be structured (not formatted) so it can render on web, mobile, email, and future channels. Avoid embedding HTML in rich text fields — use structured blocks that each channel can render appropriately.

2. Create reusable components for repeated field groups — SEO fields, social links, and address information appear on multiple content types. Define them as reusable components (Contentful's "embedded entries," Sanity's "objects") to ensure consistency and reduce duplication.

3. Use references instead of duplicating content — When an author appears on 50 blog posts, reference the Author entry rather than embedding author data on each post. References ensure updates propagate automatically and prevent data drift.

4. Define validation rules at the field level, not just the application level — Set required fields, max lengths, regex patterns, and reference type constraints in the CMS. This prevents content editors from creating invalid content that breaks the frontend.

5. Plan your taxonomy hierarchy before building content types — Define categories, tags, and content type relationships on paper first. Flat taxonomies are simpler but limit navigation. Hierarchical taxonomies enable browsing but add complexity. Match the depth to your content volume and user navigation patterns.

Common Issues

Content model becomes too rigid as requirements evolve. Design with extensibility in mind. Use modular section-based pages instead of fixed-field pages. Add new section types without modifying existing ones. Use optional fields for future capabilities rather than adding required fields retroactively.

Rich text fields contain unstructured HTML that breaks across platforms. Enforce structured rich text (blocks, marks, embeds) instead of raw HTML. Most modern CMS platforms support portable text formats. Convert legacy HTML content to structured format during migration.

Content editors bypass the model by misusing flexible fields. If editors consistently misuse a "Notes" field for something it wasn't designed for, the model is missing a field. Observe how editors actually create content and adjust the model to match their needs rather than enforcing rules they'll work around.