AI coding assistants have moved from novelty to necessity. Tools like Claude Code and GitHub Copilot are shipping features, reviewing pull requests, and navigating codebases — all from the terminal. But with a platform like Xperience by Kentico, generic AI help only gets you so far. The AI needs to know your platform’s APIs, patterns, and conventions.

That’s where MCP servers (Model Context Protocol) come in. Kentico publishes a documentation MCP server that gives AI agents real-time access to official docs. Instead of hallucinating an API that doesn’t exist, the agent can look it up. This is a game changer for platform-specific development.

But access to docs is only half the story. You also need workflows — structured instructions that tell the AI how to approach a complex task like migrating from KX13 or building a Page Builder widget from scratch. In plugin ecosystems like Claude Code, these workflows are called skills: user-triggered commands that guide the AI through a specific process.

The Starting Point: Manual Workflows

Kentico created something called KentiCopilot — a collection of AI workflows stored in a GitHub repository. It covers two major scenarios:

  • KX13 Migration — migrating controllers, views, Page Builder widgets, routing, and shared components from Kentico 13 to Xperience by Kentico
  • Widget Creation — researching requirements against the official docs, then generating all the widget files

The workflows worked, but here’s where the friction started.

To use KentiCopilot, you had to clone the repository, copy prompt files into your project’s .claude/commands/ directory, and manually configure MCP servers by running claude mcp add-json commands. You could commit those files to your project repo so the whole team had access — that part was fine. But you were now maintaining copies of the workflows inside each project. When the upstream workflows changed, there was no update path. MCP configuration lived separately from the workflows themselves. And every new project meant repeating the whole setup.

It worked, but it was manual and fragile.

The New Way: Plugin Marketplaces

Both Claude Code and GitHub Copilot CLI now support plugin marketplaces — a proper distribution system where workflows are installed with a single command, MCP servers auto-configure, and updates roll out without copying files around. Instead of maintaining workflow copies in every repo, you install from a single source of truth.

What We Built: A Plugin Marketplace

We packaged KentiCopilot into a proper plugin marketplace. It lives at simplea/xperience-by-kentico-ai-marketplace and offers:

  • kx13-migration — 5 skills for the full KX13 → XbyK migration workflow
  • widget-creation — 2 skills for researching and generating Page Builder widgets
  • kentico-docs-mcp — AI access to Kentico documentation
  • kentico-cm-mcp — Content Modeling MCP for AI-powered schema design

Each plugin bundles its own MCP configuration. Install it once, and the documentation access is configured automatically. No manual setup.

How It Works Now

Claude Code

# One-time setup
/plugin marketplace add https://github.com/simplea/xperience-by-kentico-ai-marketplace.git

# Install workflow plugins
/plugin install kx13-migration@xperience-by-kentico
/plugin install widget-creation@xperience-by-kentico

# Optional: Install MCP plugins for documentation access
/plugin install kentico-docs-mcp@xperience-by-kentico
/plugin install kentico-cm-mcp@xperience-by-kentico

That’s it. The skills are registered, MCP servers are configured, and you’re ready to migrate.

GitHub Copilot CLI

# Add the marketplace and install workflow plugins
copilot plugin install kx13-migration@xperience-by-kentico
copilot plugin install widget-creation@xperience-by-kentico

# Optional: Install MCP plugins for documentation access
copilot plugin install kentico-docs-mcp@xperience-by-kentico
copilot plugin install kentico-cm-mcp@xperience-by-kentico

Using the KX13 Migration Workflow

The migration breaks down into five focused skills:

# Step 1: Set up XbyK project structure
/kx13-migration:migrate-global-code

# Step 2: Migrate widgets for a page
/kx13-migration:migrate-page-widgets "Home" /en/home

# Step 3: Migrate the page itself
/kx13-migration:migrate-page "Home" /en/home /home

# Step 4: Fix visual differences
/kx13-migration:migrate-page-visual /en/home /home

# Step 5: Migrate shared components
/kx13-migration:migrate-shared-component header

Each step tells the AI what to do — which documentation to check, which files to generate, how to validate the output. The AI doesn’t guess; it follows a process and verifies everything against official docs.

Using the Widget Creation Workflow

Creating a new widget is two stages.

Stage 1 — Research. Create a folder with a requirements.md file describing your widget, then:

/widget-creation:research-widget widgets/promo-banner

The AI reads your requirements, validates them against the docs via MCP, and produces an implementation-instructions.md with the full plan: widget identifier, properties with [EditingComponent] decorators, view model structure, everything.

Stage 2 — Generate. Review the plan, then:

/widget-creation:create-widget widgets/promo-banner

All files are generated — view component class, properties class, Razor view, view model, resource files — following your project’s conventions.

Why This Matters

Before: You copy workflow files into each project repo, configure MCP servers separately, and maintain those copies yourself. When the upstream workflows improve, you have to manually pull changes and update every project.

Now: One install command. MCP servers auto-configure. Updates come from a single source. Every project gets the same setup without maintaining copies.

But the bigger win is the structure. The workflows aren’t just loose prompt files anymore — they’re proper plugins with declared dependencies, allowed tools, and bundled reference files. This means they’re maintainable, versioned, and distributable.

A Note on the Technical Decisions

If you’re building your own Claude Code plugins, here’s what we did:

skills/ directory — Claude Code’s plugin spec recommends skills/<name>/SKILL.md over the legacy commands/ directory. This structure supports bundled reference files and is the way forward.

disable-model-invocation: true — All our skills are user-triggered. Without this flag, Claude might auto-run a migration command if it detects relevant context in your conversation. You don’t want the AI deciding to migrate your project on its own.

allowed-tools with MCP pre-approval — Each skill declares which tools it needs. This means Claude won’t prompt you for permission on every MCP call during a long workflow.

Bundled .mcp.json — The plugin includes MCP server configuration that’s automatically applied on install:

{
  "mcpServers": {
    "kentico.docs.mcp": {
      "type": "http",
      "url": "https://docs.kentico.com/mcp"
    }
  }
}

That’s the story of how we took a manual workflow and turned it into something teams can actually adopt. If you’re building Xperience by Kentico projects, check out the marketplace and give it a try. And if you’re building your own AI plugins for any platform, these patterns — proper structure, pre-configured dependencies, one-command install — should guide your approach too.