Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From craft-developer
Content modeling methodology for Craft CMS projects. Use when designing content architecture, planning sections and fields, configuring Matrix fields, setting up CKEditor, advising on content model decisions, or structuring any CMS project. Trigger this skill when the user asks about sections vs channels vs structures, Matrix nesting strategy, entry type sharing, when to use CKEditor vs Matrix, field naming conventions, how to model relationships, color strategy for entry types, or any "how should I structure this content" question. Also trigger when planning new Craft projects from scratch, reviewing existing content models for improvements, onboarding a client to Craft CMS content architecture, or designing the content model for an Assembly pilot's public-facing site. Covers the three-layer approach (Foundation, Structure, Experience), design system conventions, and all Craft 5.5–5.9 field types and features.
npx claudepluginhub design-machines-studio/depot --plugin craft-developerHow this skill is triggered — by the user, by Claude, or both
Slash command
/craft-developer:content-modelingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A methodology for designing content models that are flexible, author-friendly, and maintainable.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
A methodology for designing content models that are flexible, author-friendly, and maintainable.
Content modeling is iterative. Instead of trying to design everything upfront, work in layers:
The building blocks. Things that exist independently.
Connect the foundation pieces.
Refine for authors.
Labels — What authors see in the control panel
Handles — What templates reference
Generic fields, semantic overrides: Create fields for field types, not content purposes:
richText → override label to "Body", "Description", "Bio"plainText → override to "Heading", "Subhead", "Caption"image → override to "Hero Image", "Thumbnail", "Avatar"Use color to create visual hierarchy:
Section entry types:
Matrix block entry types:
Entry types — Which blocks are available Groups — Organize the "+ Add" menu (5.8+), searchable when 5+ types View mode:
Nesting is configured in entry type field layouts, not Matrix settings.
To enable nesting:
Example: Section block contains Content builder field → Section blocks can nest other blocks.
Control what nests what:
In Craft 5, entry types exist in a global pool:
Plan for this: Design entry types generically enough to reuse, but specific enough to be meaningful.
Entry types can have descriptions (5.8) — useful as info tooltips in entry type chips. They can be duplicated with "Save as a new entry type" (5.8). Names and handles can be overridden per section or Matrix field (5.6).
Start with one Content builder Matrix. Split into specialized matrices when authors need clearer constraints.
CKEditor embeds:
Matrix blocks:
Both together:
Create multiple configurations:
Less is more. Cluttered toolbars invite off-brand formatting.
Singles — One entry, one purpose (homepage, settings) Channels — Collections, order from queries (blog, products) Structures — Hierarchical, manual ordering (pages, docs)
Use a Single when:
Use a Channel when:
Use a Structure when:
Use Entries fields to connect content:
Build Categories and Tags as entry types in their own sections. Use Entries fields for relationships. This is more flexible and is Craft's direction.
Categories section (Structure if hierarchical, Channel if flat) Tags section (Channel, simple entry type)
Craft doesn't create bi-directional relationships automatically. The data lives on the entry with the Entries field.
Query from either direction:
relatedTo to find ArticlesA new field type for structured content that lives within an entry. Unlike Matrix (which manages nested entries), Content Block is a simpler container. Cards and table views can now display fields nested within Content Block fields (5.9).
Computed fields whose values are generated from other fields. Displayed in element indexes and sortable (5.9). Useful for combining fields (e.g., "Full Name" from first + last) or computed values.
Native JSON storage — useful for API responses, configuration objects, or structured data that doesn't map to Craft's field types.
An alternative to Dropdown/Radio Buttons with a more compact visual display. Options support icons and colors (as do Dropdown, Radio Buttons, Checkboxes, and Multi-select since 5.7).
Slider input for numeric values — good for ratings, percentages, or constrained numbers.
Field tabs and individual fields can be conditionally shown based on:
This replaces the need for many single-purpose entry types. Instead of separate "Video Article" and "Text Article" types, use one "Article" type with conditional fields.
When to use conditions vs separate entry types:
Editability conditions (5.7): Individual fields can be made read-only based on conditions — useful for locking certain fields for specific user groups while keeping them visible.
Field editability conditions (5.9): Custom fields can now have editability conditions based on the edited element itself, not just user permissions.
Working through layers reveals requirements:
This is expected. Return to earlier layers as needed. That's the iterative process working correctly.
For detailed patterns, see:
${CLAUDE_SKILL_DIR}/references/matrix-patterns.md${CLAUDE_SKILL_DIR}/references/ckeditor-patterns.md