---
title: Build a website with KentiCopilot
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

This Kickstart series walked you through building a simple Xperience website by hand: modeling content types, creating a channel, building pages, and writing the presentation layer that renders them.

With KentiCopilot tools, you can use an AI assistant to build the same site: you write a specification of what you want, and the agent handles the mechanical work. Watch the demo below, then read what it takes to run a session like this yourself.

> **Info:** **New to this series? Start with the fundamentals.**
>
> Before using an AI assistant to build with Xperience, complete the [Developer kickstart series](https://docs.kentico.com/guides/development/developer-kickstart.md), building the project by hand. This will help you understand how the content model, channel, pages, and underlying Xperience APIs work together. That foundation is essential when working with AI-generated code. It enables you to review the proposed solution, identify any incorrect assumptions, troubleshoot issues, and adapt the code only when you are 100% sure. Once you understand the manual build, return to this page to explore how an AI assistant can help you complete the same work faster.

🎮 [Build an Xperience by Kentico website with KentiCopilot (interactive demo)](https://app.arcade.software/share/tfiKDh95fhXw9HhPbErK)

**Tools we used**

- **IDE:** Visual Studio Code
- **AI harness:** GitHub Copilot in agent mode
- **KentiCopilot plugin:** the [web development plugin](https://docs.kentico.com/guides/development/kenticopilot.md#ai-assisted-web-development)
- **MCP servers:** [Documentation](https://docs.kentico.com/documentation/developers-and-admins/installation/mcp-server.md) and [Management API](https://docs.kentico.com/documentation/developers-and-admins/api/management-api.md)
- **Models:** Claude Opus 5 for the specification, Claude Sonnet 5 for the readiness audit and the implementation

> **Tip:** The model split above matches the work: the heavier reasoning job, sharpening ambiguous requirements into a specification, got the more capable model, while a well-specified implementation and a checklist-driven audit ran reliably on a faster one. See [Choose a model that fits the task](https://docs.kentico.com/guides/development/kenticopilot/work-effectively-with-kenticopilot.md#choose-a-model-that-fits-the-task) for making that call on your own project.

## Before you start

To have a good starting point, ensure you have:

- An Xperience by Kentico project you can [build and run locally](https://docs.kentico.com/documentation/developers-and-admins/development/website-development-basics/set-up-local-hosting.md).
- An AI coding assistant that supports [MCP](https://modelcontextprotocol.io/) and [agent skills](https://agentskills.io/home).
- The [KentiCopilot web development plugin](https://docs.kentico.com/guides/development/kenticopilot.md#add-kenticopilot-into-your-project).
- The [Management MCP server](https://docs.kentico.com/documentation/developers-and-admins/api/management-api/configure-management-mcp-server.md) and the [Documentation MCP server](https://docs.kentico.com/documentation/developers-and-admins/installation/mcp-server.md), both configured in your workspace.

> **Tip:** Let your assistant handle the installation for you. Ask it to add the KentiCopilot plugins and configure both MCP servers. If something fails for a reason specific to your machine, ask it to help diagnose that issue as well, rather than troubleshooting by hand.

> **Note:** **Things to watch out for**
>
> Installing the KentiCopilot plugins doesn't configure any MCP server. Add both the Documentation and the Management MCP server to your workspace yourself, then open your assistant's MCP servers list and confirm exactly one entry for each is running.
>
> If you started from the Xperience project boilerplate, note that it ships with `AddAuthorization()` and `UseAuthorization()` commented out in `Program.cs`. The management API returns HTTP 500 until you enable them.

## Prepare your project

Before you hand the assistant any real work, make sure the project itself is ready for it.

### Check your project's readiness

Ask your assistant to run the `agentify` skill from the KentiCopilot web development plugin against your project. It audits three things: agent instructions, design and coding standards guidance, and whether the Documentation and Management MCP servers are configured. It reports what it finds and waits for your approval before making any changes.

Run the audit before you start. A project that passes it gives every new session the same starting context, instead of one that depends on what happened to be in a previous conversation.

### Base the AGENTS.md instructions on a project that already has conventions

Without instructions, the agent makes its own structural decisions: content retrieval calls land wherever they're used, files sit in flat directories, and naming follows whatever the agent defaults to. That's fine for a quick prototype, but on a real project, you want your own conventions – feature folders, a shared retrieval service, consistent naming – and the skills are built to be shaped this way, not to assume one.

The fastest way there is to point the agent at a well-structured Xperience by Kentico project and have it derive your instructions from that project's patterns. In order of preference:

- Your own baseline project, if you have one. It reflects your real conventions rather than a generic ideal.
- The [Training guides repository](https://github.com/Kentico/xperience-by-kentico-training-guides) is a good fit for a project this size.
- The [Community Portal](https://github.com/Kentico/community-portal), for a larger, multichannel project – its content retrieval layer is a solid model for a caching and query-composition approach.

```text title="Prompt example: generate instruction files from a reference project"
Review the structure and patterns in [reference project]. Generate instruction files covering: project and solution structure, feature organization, content retrieval, naming conventions, and the documentation I should check against.
```

For a project this size, the result can be a single instruction file. A larger project might split it into several, one per concern. Either way, a project-structure file might spell out the layout you want the agent to follow – for example, something close to how this demo's own project ended up organized:

```text title="Sample from a generated project-structure instruction file"
src/
├── Kickstart.Entities/     # Generated content type classes -- never hand-edited
├── Kickstart.Web/          # ASP.NET Core app: UI + infrastructure, organized by feature
└── Kickstart.Web.Tests/    # Tests mirroring the Features/ tree

Web/Features/LandingPages/
├── LandingPageController.cs    # Thin: retrieves the page, returns a view
├── LandingPageViewModel.cs
└── LandingPagePageTemplate.cshtml
```

Whatever comes out of it, one file or several, aim to cover:

- Project and solution structure.
- Feature organization.
- A consistent approach to content retrieval, so queries aren't scattered across the codebase.
- Naming and dependency injection conventions.
- Documentation the agent should consult.

### Point it at your source material

The assistant still needs to know what to build. In the demo, that material is the Developer kickstart guides themselves, sitting in the workspace as markdown, but the format isn't the point. Pasted documentation URLs, a static HTML design, or a requirements document work just as well. What matters is that the requirements come from something real, not from a well-worded prompt.

## Start with a specification, not a prompt

The single biggest factor in the result is what you hand the assistant before it writes anything.

Have the assistant write a specification _before_ it builds anything, and review it properly. In the demo, the first draft models the site's slogan as a text field on the page; several pages share the same slogan, so it belongs in the Content hub as reusable content instead. That's a content modeling decision, and no assistant can make it for you – but correcting it in a specification costs two sentences, where correcting it in a half-built site costs a rebuild.

The demo uses a third-party, open-source skill by Matt Pocock, shared on his [AI Hero](https://www.aihero.dev/) site: [/grill-with-docs](https://www.aihero.dev/skills-grill-with-docs). It interviews the developer before writing the specification. It's one example of a good habit, rather than a requirement. Other equivalents work too, including writing the skill yourself or simply instructing the agent to ask. A skill makes more sense here, since it's something you'll reuse throughout your Xperience by Kentico development. For a much more formal and structured framework, which may be helpful in enterprise projects, take a look at [GitHub's spec-kit](https://github.com/github/spec-kit).

> **Info:** A specification with acceptance criteria also gives the assistant somewhere to stop. It has a definition of done to check its own work against, so it stops when the criteria are met instead of continuing to make changes.

## Work in slices, and verify each one

The demo builds the whole site in a single implementation run. That works here because the site is small – four content types, two pages, one navigation menu – but the example is small; treat it as such, not as a recommendation.

On a real project, divide the work first and run the same loop for each slice: specify, review, implement, verify. Slice by page, by content type, or by feature, whatever matches how the work is already broken down. Size each slice so that one cycle stays reviewable in one sitting: if you can't read the resulting changes carefully, you're not really verifying anything.

Before you move on to the next slice, check that it's stable: the solution builds, the generated classes exist for anything new, the page renders, and the objects show up in the administration interface. If something doesn't build or render correctly, ask the agent to find the root cause and fix it; if you're not sure what to do next, ask it to propose the next step based on where the project actually stands.

The specification is what makes this work across iterations. It stays in the repository as the current agreement, so each new session, and each new slice, starts from the same record rather than from a conversation someone has to remember.

> **Info:** Iterating also gives you a place to correct course. A specification you've already reviewed once is easier to extend for the next slice than to write from scratch, and each verified slice narrows what can go wrong in the next one.

## What the agent did reliably in the demo

- **Created the website channel and the four content types** using the [Management MCP server](https://docs.kentico.com/documentation/developers-and-admins/api/management-api.md).
- **Generated the strongly-typed content type classes** with Xperience's own `dotnet run --kxp-codegen` command – the same one you'd run yourself – and confirmed the solution still built.
- **Looked up the content retrieval API** through the [Documentation MCP server](https://docs.kentico.com/documentation/developers-and-admins/installation/mcp-server.md) before writing any retrieval code.
- **Created and published the demo content and pages**, including the shared slogan and the navigation items, again through the Management MCP server.
- **Placed the Rich text and Form widgets** on the Contact us page, using the Management MCP server's Page Builder tools.
- **Verified each acceptance criterion** against the running site and the administration interface, and reported each one as passed or failed.

The agent logs each tool call as it happens, so you can see exactly which one it reached for at every step, and audit the session afterward.

## Where your input is required

- **The contact form is the one thing you build by hand.** At this time, the Management MCP server doesn't yet expose a way to create forms, so the specification records it as a manual step: you build the form in Form Builder, and the assistant places the Form widget that displays it. See the [Reference - Management MCP capabilities](https://docs.kentico.com/documentation/developers-and-admins/api/management-api/reference-management-mcp-capabilities.md) for what's supported today.
- **Content lives in the database, not the repository.** Content types, the channel, and content created through the MCP server exist only in your local database until you serialize them. See [Continuous Integration](https://docs.kentico.com/documentation/developers-and-admins/api/management-api/use-management-mcp-server.md#continuous-integration) for storing them to the repository.
- **Read the generated code as if it were a pull request.** Check the retrieval patterns, the registrations, and that it followed your repository's conventions, not just that it compiles.
- **Verify against the running site**, in the administration interface and the live channel, rather than trusting the chat transcript.

## Useful resources

Read [Work effectively with KentiCopilot](https://docs.kentico.com/guides/development/kenticopilot/work-effectively-with-kenticopilot.md) for the habits that make sessions like this one reliable: exploring before planning, delegating investigation to subagents, and keeping your project's context durable.

For the rest of the KentiCopilot tooling – the MCP servers, the plugins, and the skills they contain – see [KentiCopilot](https://docs.kentico.com/guides/development/kenticopilot.md). For more resources and community examples, visit the [Kentico AI development hub](https://community.kentico.com/resource-hub/xperience-by-kentico-ai-development-hub).

For more on why the environment you set up matters more than the prompt you write, read [I thought AI coding was about prompts. I was wrong.](https://community.kentico.com/blog/i-thought-ai-coding-was-about-prompts-i-was-wrong).

## Continue learning

When you're ready, move on to the next page: [Next steps](https://docs.kentico.com/modules/developer-kickstart/next-steps.md).