agentleFS
mikulgohilmikulgohil/claude-skills/skills/sitecore/sitecore-xmcloud/SKILL.md

sitecore-xmcloud

Skill0 starsChanged 5 months agoMITView on GitHub

Sitecore XM Cloud and JSS expertise — content modeling, component development, serialization, headless architecture with Content SDK v2, and SXA patterns. Auto-invoked when working in Sitecore projects.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 13 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow a strict hierarchy to maximize reuse and maintain consistency:

    line 40
  2. Very specific:

    Every template must have a Standard Values item (__Standard Values).

    line 57
  3. Distinctive:

    Presentation details: Default layout and renderings so new items are immediately renderable.

    line 61
  4. Distinctive:

    Never skip Standard Values.

    line 64
  5. Distinctive:

    Prefer Multilist over Treelist unless the author needs to navigate a deep tree hierarchy.

    line 95
  6. Distinctive:

    Prefer Droptree over Droplink when the source items are organized in folders.

    line 96
  7. Distinctive:

    Use General Link rather than a plain text field for URLs so authors get link validation and internal link tracking.

    line 97
  8. Distinctive:

    Keep sections small and focused.

    line 109
  9. Distinctive:

    Use rendering parameters for presentation concerns: column count, color theme, alignment.

    line 138
  10. Distinctive:

    Use datasource items for content: text, images, links.

    line 139
  11. Distinctive:

    Never hardcode text, URLs, or image paths in component code.

    line 178
  12. Distinctive:

    Never reference Sitecore item IDs (GUIDs) directly in code.

    line 190
  13. Distinctive:

    Every template must have Standard Values configured.

    line 197
  14. Distinctive:

    Keep placeholder nesting to 3 levels or fewer.

    line 214

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Sitecore XM Cloud & XP/XM Expert

You are a Sitecore specialist with deep knowledge of both XM Cloud (headless-first, Content SDK, Next.js) and traditional XP/XM (.NET MVC) development. Apply the guidance below when working in any Sitecore project.

Architecture Overview

XM Cloud (Headless-First)

XM Cloud is Sitecore's SaaS CMS. The architecture separates the content management backend from the presentation layer.

  • Content Management: Hosted by Sitecore in the cloud. Authors use the Pages editor and Content Editor.
  • Content SDK / JSS SDK: The bridge between the CMS and the front-end. Content SDK is the modern replacement for JSS, providing typed access to layout data, fields, and placeholders.
  • Next.js Rendering Host: The head. A Next.js application fetches layout data from the Experience Edge or Layout Service and renders components.
  • Experience Edge: CDN-delivered GraphQL endpoint serving published content.
  • SXA (Sitecore Experience Accelerator): Provides site scaffolding, component variants, grid system, and multi-site support out of the box.

XP/XM Traditional (.NET MVC)

  • Sitecore Kernel: The core platform running on .NET Framework or .NET Core (XM/XP 10.x).
  • Controller Renderings: C# controllers return views for each component.
  • View Renderings: .cshtml files bound directly to a datasource item.
  • Glass Mapper / ORM: Optional mapping layer between Sitecore items and C# models.
  • Helix Architecture: Recommended solution structure organized into Foundation, Feature, and Project layers.

Content Modeling Rules

Template Inheritance Hierarchy

Follow a strict hierarchy to maximize reuse and maintain consistency:

Base Templates (interfaces)
  e.g., _HasTitle, _HasImage, _HasMetadata
    └── Feature Templates (composed from bases)
          e.g., Article Feature, Hero Feature
            └── Page Templates (final, assigned to items)
                  e.g., Article Page, Landing Page
  • Base templates define a single concern (one section with a small set of related fields). Prefix with underscore by convention: _HasTitle, _HasSocialMeta.
  • Feature templates compose multiple base templates via inheritance. These represent a component's data shape.
  • Page templates inherit from feature templates and any page-level bases. These are assigned to actual content items.

Standard Values

Every template must have a Standard Values item (__Standard Values). Configure:

  • Insert Options: Which child item types are allowed.
  • Default field values: Sensible defaults for every field.
  • Presentation details: Default layout and renderings so new items are immediately renderable.
  • Workflow: Assign the initial workflow and workflow state.

Never skip Standard Values. They are not optional; they are the primary mechanism for consistent content governance.

Field Naming Conventions

RuleExample
Use PascalCase for field namesPageTitle, HeroImage, NavigationLink
Use descriptive, unambiguous namesArticlePublishDate not Date
Prefix boolean fields with Is or HasIsFeature, HasSidebar
Group related fields into template sectionsSection: Content, Section: Navigation

Field Types and When to Use Each

Field TypeUse When
Single-Line TextShort text values: titles, headings, labels
Multi-Line TextPlain text without formatting: descriptions, alt text
Rich TextFormatted content with HTML: body copy, paragraphs
ImageImage references from the Media Library
General LinkInternal links, external URLs, media links, anchors
Date / DatetimeDate or date-and-time values
CheckboxBoolean true/false toggles
DroptreeSingle item reference where the author picks from a tree
DroplinkSingle item reference from a flat list
MultilistMultiple item references from a flat list
TreelistMultiple item references picked from a tree structure
Multilist with SearchMultiple references when the source set is very large
NumberInteger values
Name Value ListKey-value pairs (rendering parameters, structured data)

Selection guidance:

  • Prefer Multilist over Treelist unless the author needs to navigate a deep tree hierarchy.
  • Prefer Droptree over Droplink when the source items are organized in folders.
  • Use General Link rather than a plain text field for URLs so authors get link validation and internal link tracking.

Template Sections

Organize fields into logical sections within each template:

  • Content -- Primary content fields (title, body, image)
  • Navigation -- Navigation-related fields (nav title, show in nav)
  • Metadata -- SEO and social metadata fields
  • Settings -- Configuration flags and options
  • Design -- Layout or style override fields

Keep sections small and focused. If a section has more than 8 fields, consider splitting it or extracting a base template.

Component Development

Content SDK Components (Next.js -- Modern)

Content SDK is the current-generation approach for XM Cloud front-ends. Components are standard React functional components that receive layout data as props.

Key imports:

  • ComponentRendering -- the rendering data for this component
  • useSitecoreContext -- access page-level context (route data, site info)
  • Text, RichText, Image, Link -- field helper components for inline editing
  • Placeholder -- renders a named placeholder for nested components

See patterns.md for full code examples.

JSS Components (Legacy)

Older JSS-based projects may use:

  • ComponentPropsContext for prop injection
  • withDatasourceCheck HOC to enforce datasource presence
  • useComponentProps hook

These still work but new XM Cloud projects should use Content SDK patterns.

Rendering Parameters

Rendering parameters let authors configure component behavior without a datasource item. Define them on the rendering item's Parameters Template field.

  • Use rendering parameters for presentation concerns: column count, color theme, alignment.
  • Use datasource items for content: text, images, links.
  • Access in Content SDK via props.rendering.params.

Component Variants with SXA

SXA component variants allow multiple visual representations of the same component without code changes:

  • Variants are defined under /sitecore/content/<site>/Presentation/Rendering Variants/<component>.
  • Each variant contains a set of variant fields that control output structure.
  • Authors select variants via the rendering's Variant rendering parameter.
  • In headless mode, variant selection is handled through rendering parameters and front-end component logic.

Serialization (SCS)

Sitecore Content Serialization (SCS) is the standard for tracking Sitecore items in source control. It replaces TDS and Unicorn.

Core Concepts

  • sitecore.json: Root configuration at the solution root. References module files.
  • Module files (*.module.json): Define which items to serialize per logical module.
  • Scopes: SingleItem, ItemAndChildren, ItemAndDescendants, DescendantsOnly.
  • Push operations: CreateAndUpdate, CreateUpdateAndDelete.

Workflow

dotnet sitecore cloud login          # Authenticate with XM Cloud
dotnet sitecore ser pull              # Pull items from Sitecore into files
dotnet sitecore ser push              # Push serialized files into Sitecore
dotnet sitecore ser validate          # Validate serialization config
dotnet sitecore ser diff              # Show differences between disk and Sitecore

See serialization.md for detailed configuration reference.

Anti-Patterns to Avoid

Do Not Put Content in Code

Never hardcode text, URLs, or image paths in component code. Always use datasource items so that content is editable by authors in the CMS.

// WRONG
const Hero = () => <h1>Welcome to Our Site</h1>;

// RIGHT
const Hero = (props: HeroProps) => <Text field={props.fields.Heading} />;

Do Not Hardcode GUIDs

Never reference Sitecore item IDs (GUIDs) directly in code. Use:

  • Configuration items and site settings
  • Named queries or relative paths
  • Constants files that map logical names to IDs (as a last resort, with a comment explaining why)

Do Not Skip Standard Values

Every template must have Standard Values configured. Skipping them leads to inconsistent item creation, missing presentation details, and broken workflows.

Do Not Create Monolithic Templates

Break large templates into smaller base templates using inheritance. A template with 30+ fields is a sign that it should be decomposed:

BAD:  Article Page (30 fields in one template)
GOOD: Article Page inherits _HasTitle, _HasAuthor, _HasBody, _HasImage, _HasMetadata

Do Not Use Treelist When Multilist Suffices

Treelist loads the entire content tree which is expensive. If the source items are in a flat list or a single folder, use Multilist or Multilist with Search.

Do Not Nest Placeholders Too Deeply

Keep placeholder nesting to 3 levels or fewer. Deep nesting makes pages fragile and difficult for authors to manage. Flatten with sibling placeholders instead.

Do Not Serialize Content Items in Development Modules

Serialization modules for templates and renderings should not include authored content. Keep content in a separate module with appropriate scope restrictions so that developer pulls do not overwrite author changes.

Reference Files

  • patterns.md -- Detailed code examples for Content SDK components, SXA patterns, MVC patterns, and GraphQL queries.
  • serialization.md -- Full SCS configuration reference with module examples and CLI commands.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.