---
title: Enforce a target architecture
---

> 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).

## Enforce a target architecture

The default run (lift-and-shift) produces working code with no upfront configuration, but it also lets the agent make structural decisions for you: content retrieval logic lands in controllers, components go into flat directories, and naming follows agent defaults. For production projects, you usually want your own conventions, such as feature folders, shared services, and consistent naming. The skills are **architecture-agnostic by design**, so you can shape the output by giving the agent project-specific [instruction files](https://devblogs.microsoft.com/dotnet/prompt-files-and-instructions-files-explained/).

### Generate instructions from a reference project

To quickly create instructions, point the agent at a well-structured XbyK project and have it generate your instruction files from that project's patterns. Suitable reference projects, in order of preference:

- **Your own baseline project**: the best option if you already have a well-structured XbyK solution. It reflects your real conventions rather than a generic ideal.
- **The open-source [Community Portal repo](https://github.com/Kentico/community-portal)**: our recommended alternative for larger, multichannel projects with many customizations. Its [Operations folder](https://github.com/Kentico/community-portal/tree/main/src/Kentico.Community.Portal.Core/Operations) shows an advanced CQRS and query-caching approach worth modeling content retrieval on.
- **The [Training guides repo](https://github.com/Kentico/xperience-by-kentico-training-guides/tree/finished) (finished branch)**: a cleaner, simpler structure for smaller projects.

An example prompt to generate the files:

```text title="Prompt example: generate instruction files from a reference project"
Review the structure and patterns in [reference project]. Generate instruction files that guide code generation for my project, covering: solution and project structure and dependencies; feature organization; content retrieval; the layering from content types to domain models, repositories, services, controllers, and view models; naming conventions; service registration; C# style; and the docs the agent should consult. Where it helps, split the guidance into focused files scoped with applyTo, each covering a single concern.
```

Based on your needs and the complexity of your project, the result can be a small set of focused files or a single document. For example, a project-structure instruction file might spell out the folder layout you want the agent to follow:

```text title="Sample from a generated project-structure instruction file"
src/
├── DemoProject.Entities/   # Interfaces and generated content type classes
├── DemoProject.Core/       # Domain models and business logic, no infrastructure
├── DemoProject.Web/        # ASP.NET Core app: UI + infrastructure
└── DemoProject.Admin/      # Admin customizations

Web/Features/Blog/
├── BlogPostPageController.cs   # Thin: injects a service, returns a view
├── Repositories/               # Data access, returns domain models
├── Services/                   # Orchestrates repositories + domain logic
├── ViewModels/
└── Views/
```

### What your instruction files should cover

Whether you keep everything in one file or split it across several, aim to cover:

> **Key:** 
>
> - **Project and solution structure**: which project owns what, and how they reference each other.
> - **Feature organization**: how code is grouped, such as feature folders that keep a feature's controller, services, and views together.
> - **Content retrieval**: a consistent approach, such as a shared retriever service and repositories, so queries aren't scattered.
> - **Layering and responsibilities**: the path from content types to domain models, repositories, application services, thin controllers, and view models.
> - **Mapping**: where conversions between generated types, domain models, and view models happen.
> - **Naming conventions**: files, classes, and namespaces.
> - **Dependency injection and startup**: how services get registered, such as per-feature extension methods.
> - **C# style preferences**: the conventions to apply consistently, such as records for DTOs, primary constructors for dependency injection, async usage, and error handling.
> - **Documentation references**: the links the agent should rely on.
> - **Testing**: how and where tests are organized.

## Content remodeling during migration

You reshape your content model during the content migration, before you migrate code. The [content migration skills](https://github.com/Kentico/xperience-by-kentico-kenticopilot/blob/main/plugins/kentico-kx13-migration/README.md#content-migration) handle this and support transformations such as:

- Merging, splitting, or renaming classes
- Renaming fields, converting values, or patching data types and form controls
- Extracting reusable field schemas shared across content types
- Converting source pages and content into reusable Content hub items

Because code migration reads your migrated XbyK database, it works from the remodeled structure instead of just the original KX13 codebase.

Simple remaps are usually reliable. More involved remodeling can work well too. However, the more your target model diverges from the source, the more important review discipline becomes.

> **Tip:** The quality of the migration output depends on the model you use. A more capable LLM makes better architectural decisions and handles edge cases more reliably.