Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.
RBA RBA Skills

content-type-modeler

Standalone Web-only skill. Copy it into Claude, or drop it into your project.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

Content Type Modeler

Purpose

Define one content type completely: every field with its type, alias, validation rules, localisation decision, indexing flag, and references to other types. Emit a ready-to-use artifact for the target platform. Use once per type — call this skill in a loop for each type when building a broader model.

Distinct from the content-type-modeler skill in the content-modeling-assistant plugin, which designs a full type hierarchy from requirements. This skill goes deep on one type at a time.

Inputs

$ARGUMENTS provides:

  • <TypeName> — the content type name (PascalCase; e.g. ArticlePage, HeroBlock, AuthorProfile)
  • --platform — target platform: sitecore | umbraco | optimizely | agnostic (default: agnostic)
  • --category — type category: page | block | element | base (default: infer from name)

If no arguments are given, ask: "What is the content type name and target platform?"

Additional context the user may supply (accept any format):

  • Brief description of the type's purpose and where it appears on-site
  • List of fields they already know they need
  • An existing type to base it on (inheritance/composition)
  • A wireframe description or page spec to derive fields from

Workflow

Step 1 — Establish the brief

If the brief is thin (no fields listed, no description), ask for:

  1. What this type represents (one sentence)
  2. Where it appears: page, block/component, standalone reusable element, or base/mixin only
  3. Delivery channels: web only, mobile app, email, all (affects localisation and rich text decisions)
  4. Multi-market/multilingual: yes or no (determines localisation per field)
  5. Any fields the user already knows they want

If any of these is clearly inferable from the type name and context, infer it and state the assumption — don't ask if you already know.

Step 2 — Assign category and base types

Map the type to a category using reference.md § Type Categories. Suggest a base or composition to inherit from when applicable:

Scenario Recommendation
Page with SEO requirements Inherit from / compose with an SeoBase mixin
Any published page Include an OpenGraphBase mixin
Authored content Include MetadataBase (author, publish date, expiry)
Navigation item Include NavigationBase (nav title, hide-in-nav flag)
Component / block Keep standalone — no page-level inheritance
Global reusable (card, CTA, testimonial) Mark reusable: true; no base needed

State the category and any base types before proceeding.

Step 3 — Define fields

For every field produce a row in the canonical field table. Add fields in this order:

  1. Identity fields (name/title, slug/alias, ID)
  2. Primary content fields (headline, body, image, summary)
  3. Reference fields (author, related items, category)
  4. Metadata fields (tags, publish date, expiry, sort order)
  5. SEO fields (if not in a base mixin: meta title, meta description, canonical URL, OG image)
  6. Settings / behaviour fields (hide in nav, feature flag, A/B variant key)

Canonical field table:

Field Name Alias (camelCase) Neutral Type Required Localised Indexed Cardinality Validation Reuse Note

Column definitions — see reference.md § Field Column Definitions for the full spec.

Type rules (load reference.md § Neutral Field Types for the full vocabulary):

  • Use structured types (integer, boolean, date, enum, reference) whenever the value has known constraints. Rich text is an explicit choice — document allowed inline elements and embeds.
  • Every rich text field must state: max length (words or chars), allowed inline formats, allowed embedded types (none by default).
  • Multi-value fields must state cardinality: 0..* (unlimited), 1..5 (bounded), 1..* (at least one).
  • Fields driving Coveo search, faceted filtering, or personalisation: mark indexed: true.

Step 4 — Map references

For every field whose neutral type is reference, multi-reference, taxonomy, or media, produce a reference row:

Source Field Relationship Type Target Type Cardinality Direction Notes

Relationship types: Reference (soft link), Composition (nested/embedded), Taxonomy (controlled vocabulary link), Media (asset), Navigation (structural tree link).

Flag any circular reference risk. Note publication order implications if target type must exist before source can be published.

Step 5 — Emit platform artifact

Read reference.md § Platform Adapters and emit the ready-to-use artifact for the target platform.

--platform sitecore — emit a Sitecore template definition block (see templates.md § Sitecore):

  • Template name, path suggestion (/sitecore/templates/<Domain>/<TypeName>)
  • Base templates list
  • Field sections with field name, field type, Shared/Versioned/Unversioned flag, source (own vs inherited)
  • Standard Values notes (default values, workflow, insert options)

--platform umbraco — emit a Document Type definition (see templates.md § Umbraco):

  • Document Type name, alias (camelCase), icon suggestion
  • Compositions list
  • Property groups with alias, property name, property alias, Data Type, mandatory flag, description
  • Content Delivery API JSON key names (aliases)
  • Allowed child types (if page type)

--platform optimizely — emit a C# content type class skeleton (see templates.md § Optimizely):

  • Class name, base class (PageData, BlockData, ImageData, or custom)
  • [ContentType] attribute with GUID placeholder, display name, description, group name
  • Property declarations with [Display], [CultureSpecific], [Searchable], [Required] attributes as appropriate
  • Content Graph indexing comment (// Graph: YES) on types queried headlessly

--platform agnostic — emit a JSON schema object (see templates.md § Agnostic JSON):

  • name, alias, category, description, reusable, bases[], fields[]
  • Each field: name, alias, type, required, localizable, indexed, cardinality, target, validation, notes
  • Compatible with the content-type-modeler plugin's JSON schema format for downstream use

Step 6 — Reuse and governance notes

After the platform artifact, emit a short Reuse & Governance section:

  • Reuse potential — is this type a candidate for reuse across pages/components? Y/N + rationale
  • Shared field candidates — fields that could be promoted to a base/mixin if 2+ other types need them
  • Authoring UX notes — field ordering recommendations, help-text suggestions, conditional display
  • Open questions — list any field or design decisions that require client/stakeholder input (e.g. "Confirm: is expiryDate required or optional?", "Should relatedArticles allow max 6 or unlimited?")

Step 7 — Validate and output

Run the quality checklist before presenting output:

  • Every field has a neutral type, alias, and required/optional flag
  • Every reference field has a target type and cardinality
  • Rich text fields document allowed inline formats and embeds
  • Indexed fields are explicitly marked
  • Localisation decision is explicit for each field (not left as "TBD")
  • Platform artifact uses correct field type vocabulary for the target platform
  • Open questions are listed — no client decisions made unilaterally

Present output as:

  1. Canonical field table
  2. Reference map (if any references exist)
  3. Platform artifact (formatted code block or table per platform)
  4. Reuse & Governance notes

If the user asks to model another type, re-invoke from Step 1 with the new type name.

References

  • reference.md — neutral field type vocabulary, field column definitions, type category guide, platform adapter field type mappings (Sitecore, Umbraco, Optimizely), common anti-patterns
  • templates.md — ready-to-paste output templates for each platform (Sitecore template block, Umbraco Document Type table, Optimizely C# class, agnostic JSON schema object)
  • examples.md — worked examples: ArticlePage (Sitecore), HeroBlock (Umbraco), AuthorProfile (Optimizely), ProductCard (agnostic)
Technical details
Source
Standalone skill
Author
Dakota Smith
Skill name
content-type-modeler
Maturity
experimental
Security review
No security review
Argument hint
<TypeName> [--platform sitecore|umbraco|optimizely|agnostic] [--category page|block|element|base]
Allowed tools
  • Read
  • Write
  • Edit
File
skills/content-type-modeler/SKILL.md

To use this skill in Claude Code, copy SKILL.md into your local .claude/skills/content-type-modeler/ directory. Standalone skills are not exposed via claude plugin install — that path is reserved for plugin bundles.

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.