Skip to content
Harsh Baid

Three More Sitecore Agent Skills: Authoring, Publishing, and Config

·7 min read
sitecoreengineering
sitecorexm-cloudexperience-edgeauthoring-apiai-agentsclaude-code
View as Markdown

Every headless Sitecore developer knows this twenty-minute detour. An editor pings you: "I updated the homepage hero, it is not showing on the live site." You open the CMS, the change is right there. You hard-refresh the live site. Nothing. Is it published? Is it the wrong language? Is it cached? Is it the right item - or did they edit the page when the hero is actually a datasource? You start bisecting the pipeline by hand, and half an hour later you arrive at an answer you already knew. Here is the good part: it is a problem you only have to solve once, as long as you capture the answer somewhere it will be found again.

That rabbit hole is now an agent skill. So are two others. This is a follow-up to my last post, where I published a single skill for moving content between environments and a repo to grow more of them. The repo has grown.

The idea, restated

A skill is a folder an AI coding agent reads: a SKILL.md with instructions, and optionally a script it drives. The agent discovers the skill from its description, so you ask for the outcome and it does the steps. What I said last time still holds and is the whole point: a UI encodes a workflow, but a skill can encode experience. Every trap you have hit lives in a file where the agent - and the next person on your team - will find it.

The first skill was about an API. These three are more about the hard-won knowledge around the APIs.

1. Multi-environment authoring (sitecore-authoring)

The Marketer MCP is great, but it talks to one environment per session. A huge share of real content work is inherently cross-environment: is this field the same on DEV, UAT, and PROD? Promote this value from DEV up. Audit which of these forty pages drifted.

This skill is a small CLI over the Authoring and Management GraphQL API that fans every command out across all your environments at once, because an organization automation client's token is accepted by every CM in the org:

# is the homepage title in sync everywhere?
npm run sc -- compare --env all --path "/sitecore/content/MySite/Home" --fields "Title,Text"
 
# promote DEV's value to UAT + PROD (guarded envs need --yes)
npm run sc -- set --env uat,prod --path "/sitecore/content/MySite/Home" --set "Title=Welcome" --yes

Writes to guarded environments refuse to run without an explicit --yes, so an agent cannot casually touch PROD. It also wraps the higher-level Agent API v2.0 when you need revertable jobs, and ships a companion sub-agent that runs bulk audits in an isolated context and hands back only a drift table instead of flooding your conversation with GraphQL JSON. The one thing it will not let you forget: authoring writes to master, and nothing is live until you publish - which is a neat segue.

2. Publish and verify (sitecore-publish-verify)

This is the twenty-minute rabbit hole from the top, turned into a diagnostic. The mental model it encodes is the pipeline a change flows through, and the insight that a change is invisible if it is stuck at any hop:

Master (CM)  --publish-->  Edge PREVIEW  ==publish==>  Edge LIVE  --render+cache-->  Visitor

The decisive check is comparing the item on Experience Edge's live context against its preview context. Preview mirrors master; live is what the site serves. If the value is on preview but missing from live, you have a publish gap. If both agree, the problem is downstream in your front-end cache, not in Sitecore at all. The skill bundles a zero-dependency script that does exactly this and prints a verdict:

node scripts/edge-diff.mjs \
  --live-context <liveContextId> \
  --preview-context <previewContextId> \
  --path "/sitecore/content/MySite/Home/Data/hero" \
  --fields "Title,Text"

The sitecoreContextId in the Edge URL is the auth, so no token is needed. The script tells you PUBLISH_GAP, FIELD_DRIFT, IN_SYNC, or NOT_FOUND, and the SKILL.md maps each to a fix. If the answer is "the front-end is serving stale HTML," that is a revalidation problem - the subject of my XM Cloud + Vercel ISR series.

But the reason this skill exists is the traps that neither a publish nor a cache purge will fix, written down in a gotchas reference. My two favorites, because they cost me the most time:

  • The page layout is a snapshot resolved at publish time. A datasource field can be correct on the item endpoint yet stale inside the page's rendered layout at the same instant, because the layout embeds datasource values from when the page was last published. Publishing only the datasource does not regenerate it.
  • A Smart publish of the page is a no-op if the page item itself has not changed. So after a datasource-only edit, a Smart republish of the page skips layout regeneration entirely. You need a Full republish (the "Republish" action) to force it. I once spent an afternoon clicking a Revalidate button that returned 200 every time and changed nothing, because the stale value lived in the layout snapshot, not the cache.

There are more in the file - internal links resolving to an empty href until their target is published, a publishRelatedItems: true that cascaded into tens of thousands of items and jammed the publish queue, hidden versions that silently block a publish while still showing in preview. Each one is a scar.

I will be honest about the edge of my own map here: I am already on Sitecore Publishing V2 (Edge Runtime publishing), which assembles a page's layout at delivery time rather than baking it in at publish - so in theory a published datasource change surfaces without the Full republish those traps describe. The lever I have not tuned yet is Experience Edge content dependencies (the ComputeContentDependencies setting, off by default), which tells the platform which pages a datasource feeds so revalidation can target them precisely. I have not proven that out end to end, so if you have, I would love your feedback on any of the social channels.

3. XM Cloud config review (sitecore-xmcloud-config-review)

The third is less dramatic and more preventative. When you move from on-prem XP to XM Cloud, the instinct is to bring your App_Config patches with you. But XM Cloud is a managed CM: a meaningful set of settings are locked or silently ignored, so a patch that "works" on XP may do nothing here.

This skill reviews a platform project's config includes against XM-Cloud-appropriate best practices and returns a prioritized, honest list - what is already covered, what is worth adding, and crucially what to verify before trusting. It leads with the framing that matters more than any single setting: scope patches to the role with role:require="ContentManagement", and confirm every change actually took effect via /sitecore/admin/showconfig.aspx rather than assuming the patch merged. The highest-value, lowest-risk win it usually surfaces is item-name length and character validation - because long PIM or SEO names hit the 100-character default and stray characters break your Edge and front-end URLs.

Usage

Ask for the outcome in plain language and the agent does the rest: it reads the skill, runs the script under the hood, and reports back. This is the "ask, don't click" idea from the first post, now pointed at three more jobs:

  • Authoring - Ask: "Is Title on /sitecore/content/MySite/Home the same across DEV, UAT, and PROD? If DEV is right, promote it up." The agent compares all three, shows the drift, and applies the change once you approve the guarded environments.
  • Publish and verify - Ask: "The hero at /sitecore/content/MySite/Home/Data/hero is updated in the CMS but not showing live. Where is it stuck?" The agent diffs the item on Edge live versus preview, then names the stuck hop and the fix.
  • Config review - Ask: "Review our platform project's App_Config patches for XM Cloud." The agent hands back a prioritized list: what is covered, what is worth adding, and what to verify before trusting.

Get them

All three live in the same repo: sitecore-agent-skills. Installation is copying a skill folder into .claude/skills/ in your project, or ~/.claude/skills/ for everywhere. The publish-verify script is zero-dependency Node and the config review is just a checklist; only the authoring CLI needs a one-time npm install, with credentials in a git-ignored .env as before.

If you have a Sitecore workflow you are tired of performing by hand, the bar for contributing is unchanged: a SKILL.md an agent can follow cold, a script where one helps, and the gotchas written down. Those gotchas are the part I keep coming back to. The scripts do the mechanical work; the written-down experience is what stops the next person losing an afternoon to a Revalidate button that was working the whole time.