# Cd Repository Configure > Builds or updates CD Repository filters from CI Repository changes using a discovery context file and PR numbers or commit ranges, while excluding Xperience update-only noise by default. - **Type:** Skill - **Install:** `agentstack add skill-kentico-xperience-by-kentico-kenticopilot-cd-repository-configure` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [Kentico](https://agentstack.voostack.com/s/kentico) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [Kentico](https://github.com/Kentico) - **Source:** https://github.com/Kentico/xperience-by-kentico-kenticopilot/tree/main/plugins/configure-cd-repository/skills/cd-repository-configure ## Install ```sh agentstack add skill-kentico-xperience-by-kentico-kenticopilot-cd-repository-configure ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About You are tasked with creating a scoped CD Repository configuration from CI Repository changes. ## Input Parameters - **Context Folder Path** - Folder that contains `cd-repository-context.json` produced by `cd-repository-discovery`. - **Change Selectors** - Provide **either** PR number(s) **or** a git commit range (not both): - **PR mode:** One or more PR numbers (e.g., `PR 312` or `PR 310, PR 311, PR 312`) - **Commit mode:** One git commit range (e.g., `abc123..def456` or `abc123^..def456`) Choose PR mode when deploying specific, discrete changes; choose commit mode when deploying all changes between two commits. ## Prerequisite Read `cd-repository-context.json` from the provided folder and validate: - `appPath` - `repositoryRoot` - `ciRepositoryPath` - `cdRepositoryConfigPath` - `tooling.preferredChangeSource` - `discovery.repositoryConfigVersion` must be `"2"` If the context file is missing or invalid, stop and ask the user to run `cd-repository-discovery` (or fix the file). **If `discovery.repositoryConfigVersion` is `"1"` or missing:** Stop and inform the user: > "The repository.config file uses the legacy v1 syntax. The `cd-repository-configure` skill requires v2 syntax. Please run the `cd-repository-upgrade` skill to migrate your configuration to v2, then run `cd-repository-discovery` again to generate an updated context file. See [Migrate CI/CD repository.config to v2](https://docs.kentico.com/documentation/developers-and-admins/ci-cd/configure-ci-cd-repositories/config-v2-migration) for details." ## Workflow 1. Load discovery context and confirm paths still exist. 2. Resolve change source strategy: - Prefer `gh` when context says `gh` and `gh` is available. - Otherwise use local git commands. 3. **Collect and classify CI changes for each selector:** - **PR mode:** Collect file list and changes for each PR separately. - **Commit range mode:** - List all commits in the range using `git log --pretty=format:"%H %s"`. - For each commit in the range (oldest to newest): - Run `git show --name-status -- ` to get CI files changed in that commit. - Extract commit subject/message to classify the commit intent. - Classify the commit as **Business/feature** or **Xperience update-only** (see Change Classification Guidance below). - Track CI changes per commit separately. 4. Keep only files under `ciRepositoryPath` that belong to non-excluded commits. 5. Aggregate CI changes across all non-excluded commits into: - **Business/feature changes** (include in deployment filtering) - **Xperience update-only changes** (exclude by default) 6. Exclude entire commits marked as `Xperience update-only` unless user explicitly requests inclusion. 7. Map remaining CI paths to object types and code names. 8. Update `cdRepositoryConfigPath`: - Build minimal `IncludedObjectTypes` allowlist (main object types only). - Add/merge `ObjectFilters` with one `IncludedCodeNames` entry per object type using semicolon-separated code names. - **Determine RestoreMode:** - Analyze git history: if **all** CI `.xml` files under `ciRepositoryPath` are **new** (created), use `Create` mode for better performance. - If **any** CI `.xml` files are **modified** (updated), use `CreateUpdate` mode to preserve existing objects. - **Note:** Create mode has significant performance benefits, especially for content item deployments. Use CreateUpdate only when necessary for file updates. 9. Validate XML and remove duplicate/contradicting filters. 10. Diff and explain exact changes. 11. If available in the repository, run `Export-DeploymentPackage.ps1` to generate the deployment package. **Manually verify** that the generated package contains the expected scoped objects. (The script copies your CD Repository into the package; it does not validate CD filters.) ## Change Classification Guidance Treat changes as **Xperience update-only** when they originate from platform/package update work (for example hotfix/version bump PRs or commits) and do not represent intentional business configuration/content modeling changes. Common signals: - PR/commit title or description indicates Xperience update, hotfix, NuGet/package bump, or version migration. - Bulk CI churn tied to upgrade commits with no explicit feature intent. When uncertain, default to safety: - Exclude ambiguous update-related groups. - Report exclusions clearly so user can opt in. ## Mapping Hints Common CI paths to object types: - `@global/cms.contenttype` -> `cms.contenttype` - `@global/cms.user` -> `cms.systemtable` *(unintuitive: folder is `cms.user` but config uses `cms.systemtable`)* - `@global/cms.member` -> `cms.systemtable` - `@global/cms.contact` -> `cms.systemtable` - `@global/cms.class` -> `cms.class` *(see note below about ambiguity)* - `@global/emaillibrary.emailtemplate` -> `emaillibrary.emailtemplate` - `@global/cms.settingskey` -> `cms.settingskey` *(excluded from CI/CD by default due to potentially sensitive data; flag this to the user if it appears in a diff)* **Channel-scoped content (pages, emails, headless items):** These are stored under `/` rather than `@global/`. For example, `DancingGoat/cms.contentitem/` contains pages for the DancingGoat website channel. When these paths appear in CI changes, use `IncludedContentItemsOfType` / `ContentItemFilters` (v2) rather than `ObjectFilters`. See [CI/CD object type reference](https://docs.kentico.com/documentation/developers-and-admins/ci-cd/reference-ci-cd-object-types#content-management) for details. **Resolving content item code names from channel-scoped diffs:** When a diff shows a change under `/contentitemdata.//`, the folder name encodes the item as `-` but is not directly usable as a `ContentItemFilters` code name. Always resolve the canonical code name by reading the corresponding `/cms.contentitem/.xml` file and extracting the `` element. This is the value to use in ``. **Content type not changed but new items of that type were added:** When a CI diff adds new content item files under `@global/contentitemdata./` or `@global/cms.contentitem/` for a type whose `@global/cms.contenttype/.xml` was **not** changed in any of the included commits, that content type must still be included in **both** `IncludedContentItemsOfType` and `ObjectFilters/IncludedCodeNames ObjectType="cms.contenttype"`. The type definition is unchanged but the type must be present in both places for `kxp-cd-store` to include the new items in the deployment package. **Forms require two object types:** Both `@global/cms.form/` and `@global/cms.formclass/` must be included together. The `cms.formclass` files use a `bizform.` code name prefix (e.g., `bizform.userfeedback.xml`). Include both in `IncludedObjectTypes`: ```xml cms.form cms.formclass ``` **`@global/cms.class` ambiguity:** This folder covers both module class definitions and reusable field schema definitions. Inspect the file code names to determine which is present before scoping `ObjectFilters`. **`@global/cms.contentitemcommondata/` vs `@global/cms.class/cms.contentitemcommondata.xml` — do not confuse these two paths:** - `@global/cms.contentitemcommondata//` — these are **child data files** for individual content items (language variants, draft state, etc.). They are covered automatically when the parent content type is included via `IncludedContentItemsOfType`. Do **not** add `cms.contentitemcommondata` to `ObjectFilters`; the v2 format disallows it and will throw an exception. - `@global/cms.class/cms.contentitemcommondata.xml` — this single file is the **reusable field schema definition** and must be explicitly included via `cms.class` in `ObjectFilters` when changed. **Reusable field schemas** -> Object type `cms.class`. Reusable field schema definitions are tracked via the `CMS.ContentItemCommonData` code name (file path `App_Data\CIRepository\@global\cms.class\cms.contentitemcommondata.xml`). To include them, add both an `IncludedObjectTypes` entry and an `ObjectFilters` entry: ```xml cms.class CMS.ContentItemCommonData ``` See [CI/CD object type reference](https://docs.kentico.com/documentation/developers-and-admins/ci-cd/reference-ci-cd-object-types#content-management) for details. ## Decision Rules - If `IncludedObjectTypes` is populated, it is an allowlist: include every required main object type. - Child and binding objects follow parent inclusion rules. - Prefer explicit object types over broad `IncludeAll` patterns. - Add content-item-specific filters only when content item deployment is intentionally requested. - Keep code name filters minimal and precise. - **When `IncludedObjectTypes` contains `cms.contenttype` and `ObjectFilters` has an `IncludedCodeNames ObjectType="cms.contenttype"` entry, every content type listed in `IncludedContentItemsOfType` must also appear in that `ObjectFilters` code name list** — regardless of whether the type definition itself was changed in the included commits. If a type is missing from `ObjectFilters`, `kxp-cd-store` will silently suppress all content items of that type from the deployment package. ## Formatting Guidelines Write code names one per line for readability. Within a single `` element, list each code name on its own indented line with a semicolon separator (no trailing semicolon on the last entry): ```xml DancingGoat.Cafe; DancingGoat.FAQItem; DancingGoat.BuilderEmail CMS.ContentItemCommonData ``` For `ContentItemFilters`, use a separate `` element per item (not semicolons), one per line: ```xml BostonCoffeePlace-034jwdxo CafePhoto-nu2tjd9a ``` ## Quality Checks - XML is well-formed. - No repeated `IncludedCodeNames` entries for the same object type. - Code names match actual CI object code names from XML files. - Code names listed one per line within elements (see Formatting Guidelines above). - Update-only groups are excluded (unless user opted in). - Final config diff is concise and justified. - **Every `` listed in `IncludedContentItemsOfType` also appears in `ObjectFilters/IncludedCodeNames ObjectType="cms.contenttype"`** (when that filter element is present). Any content type absent from `ObjectFilters` will have its content items silently excluded from the deployment package by `kxp-cd-store`. ## Output Format Finish with a concise deployment summary: - **Source selectors analyzed:** - For commit ranges: list all commits in the range with their subjects and classification (Business/Feature vs. Xperience update-only) - For PRs: list all PR numbers analyzed - **Commits included in deployment scope** (with hashes and subjects) - **Commits excluded as Xperience update-only** (with hashes, subjects, and reason for exclusion) - Selected object types for deployment - Selected code names by object type - Determined RestoreMode and reasoning (Create vs. CreateUpdate based on git history) - Exact impact on `repository.config` - Validation result for deployment package export (if executed) ## Leveraging Kentico Documentation This skill has access to the Kentico Docs MCP server. If you need deeper information on any topic (content item filtering, CD Repository configuration, object types, etc.) use the MCP server to search for "Repository configuration templates" or "Reference - CI/CD object types" for specific syntax and configuration examples. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [Kentico](https://github.com/Kentico) - **Source:** [Kentico/xperience-by-kentico-kenticopilot](https://github.com/Kentico/xperience-by-kentico-kenticopilot) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-kentico-xperience-by-kentico-kenticopilot-cd-repository-configure - Seller: https://agentstack.voostack.com/s/kentico - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.