Ask, Don't Click: Moving SitecoreAI Content with an AI Agent Skill

A week ago I needed to reproduce a production bug in a lower environment. The page in question had a specific combination of renderings and datasources that existed only on PROD, and the old me would have reached for the Package Designer. The Package Designer, of course, is gone.

Its replacement on SitecoreAI is a pair of REST APIs - the Content Transfer API and the Item Transfer API - and between them the "copy this page over there" workflow is an eight-step dance: create a transfer, poll it, download binary chunks from the source, upload them byte-exact to the target, complete the chunk set, tell the target to consume the resulting .raif file, verify per item, clean up - all under an org-level OAuth token. Powerful, scriptable, and absolutely not something you want to perform by hand twice.

So I did not perform it. I asked an AI agent to, watched it work through the steps in the terminal, and had my PROD page sitting in the lower environment a few minutes later - presentation included, because a page's layout is just its __Final Renderings field and it travels with the item.

This post is about turning that one-off into something reusable and shareable: an open-source agent skill, and a small repo to grow more of them.

The week the community closed the gap

Before getting to the agent part, credit where it is due, because two colleagues shipped excellent work on these APIs within a day of each other:

• Chirag Khanna explained the APIs themselves - a proper end-to-end walkthrough of both APIs with a tokenized Postman collection you can clone and run. If you want to understand every call in the chain, start there.
• Kiran Patil built Content Courier - a free, open-source Next.js app that wraps the whole workflow in a guided wizard: pick environments, pick paths, watch the seven orchestration steps run. It also blocks the one merge strategy known to crash CM environments, which tells you it was built by someone who tested against the sharp edges.

Between them you get the knowledge layer and the human interface. What I kept wanting was a third thing: an interface for agents, so the workflow can run without anyone sitting in front of it.

What an agent skill is

If you use Claude Code (or Cursor, or any coding agent that reads Markdown and runs scripts), a skill is embarrassingly simple: a folder containing a SKILL.md with instructions, and optionally a script the instructions point at. The agent discovers the skill by its description, so when you type

copy /sitecore/content/MySite/Home from prod to dev

the agent recognizes the task, reads the skill, checks the prerequisites, runs the transfer script, parses the result, and tells you what happened - including the part everyone forgets, which is that transferred items land in the target master database and still need a publish before the live site changes.

The skill I published wraps the whole eight-step workflow in a single zero-dependency Node script (Node 20+, no npm install):

node scripts/transfer.mjs \
  --source-host cm-source-env.sitecorecloud.io \
  --target-host cm-target-env.sitecorecloud.io \
  --path "/sitecore/content/MySite/Home" \
  --scope SingleItem \
  --merge-strategy OverrideExistingItem

It logs each step, prints a machine-readable summary at the end, and exits with a code an agent can act on. Credentials come from a git-ignored .env - one organization automation client covers both environments, because the JWT is org-scoped and the CM host in the URL decides which environment you hit.

The repo is here: sitecore-agent-skills. Installation is copying one folder into .claude/skills/ in your project (or ~/.claude/skills/ for everywhere). Cursor users can point a rule at the same SKILL.md; the file is plain Markdown and the script is plain Node.

Why an agent instead of a UI?

Three reasons, in increasing order of how much they changed my week:

1. You stop being the orchestrator. A wizard still needs you at the keyboard for every transfer. An agent takes "move these four trees" as one sentence.
2. Parallelism. Each transfer gets its own ID, so runs do not interfere. One person can have several agent sessions open - one moving content, one running an audit, one drafting the Jira update about both. I have genuinely started treating sessions like browser tabs.
3. The gotchas live in files now. Every trap we hit is written down where the agent will find it, which means nobody on the team has to rediscover them. That is the part I find most valuable - a UI encodes a workflow, but a skill encodes experience.

Some of those written-down traps, so this post is useful even if you never touch the repo:

A word on safety

The automation client these APIs require has organization admin scope, which is a production-grade credential. The skill tells the agent to confirm before writing into a production environment and to prefer the non-destructive merge strategies; the .gitignore keeps .env out of the repo. Treat the secret accordingly, and test against non-production targets first - the same advice Chirag and Kiran both give.

What's next

The repo is deliberately named sitecore-agent-skills, plural. The content transfer skill is the first resident; publish-and-verify and Authoring GraphQL audit skills are on the list. If you have a Sitecore workflow you are tired of performing by hand, the bar for contributing is low: a SKILL.md an agent can follow cold, a script where one helps, and the gotchas written down.

Hopefully this saves you the clicking - and if you build a skill of your own, I would love to see it.