// Bump the Umbraco CMS version across all required files. Use when the user asks to bump, update, or set the version number — e.g., "bump version to 17.3.4", "set version to 18.0.0-rc", "update version". Accepts the target version as an argument.
| name | umb-bump-version |
| description | Bump the Umbraco CMS version across all required files. Use when the user asks to bump, update, or set the version number — e.g., "bump version to 17.3.4", "set version to 18.0.0-rc", "update version". Accepts the target version as an argument. |
| argument-hint | <version> (e.g., 17.3.4, 18.0.0-rc) |
Updates the Umbraco CMS version string across all files that track it.
Do NOT use AskUserQuestion if a version argument is provided. Only ask if $ARGUMENTS is empty or cannot be parsed as a version.
$ARGUMENTS - Required: the target version string (e.g., 17.3.4, 18.0.0-rc)The following 5 files must be updated with the new version:
| # | File | Field |
|---|---|---|
| 1 | version.json | "version" |
| 2 | src/Umbraco.Web.UI.Client/package.json | "version" |
| 3 | src/Umbraco.Web.UI.Client/package-lock.json | top-level "version" AND packages[""].version |
| 4 | tests/Umbraco.Tests.AcceptanceTest/package.json | "version" |
| 5 | tests/Umbraco.Tests.AcceptanceTest/package-lock.json | top-level "version" AND packages[""].version |
Note: For major version bumps (e.g., 17.x to 18.x), src/Umbraco.Web.UI.Login/package.json has a caret-ranged dependency on @umbraco-cms/backoffice (e.g., ^17.2.0) that will need manual updating. This skill does not handle that — major bumps involve many other changes beyond version strings.
Extract the version from $ARGUMENTS. It must be a valid semver-like string (e.g., 17.3.4, 18.0.0-rc, 17.4.0-preview.1). If no version is provided or it cannot be parsed, ask the user for the target version.
Read version.json and extract the current "version" value. If the current version already equals the target version, report that the version is already set and stop — do not edit, stage, or commit anything.
Otherwise, display both versions:
Bumping version: {current} -> {target}
Update each of the 5 files listed above, replacing the old version with the new version. For each file:
version.json: Replace the "version" value.package.json files: Replace the "version" value (near the top of the file).package-lock.json files: Replace BOTH the top-level "version" value AND the "version" inside the "packages": { "": { ... } } block. These are always in the first ~10 lines of the file.Use targeted edits — do NOT rewrite entire files. Be precise to avoid changing version strings in dependency entries.
After all edits, grep for the target version value across the 5 files to confirm all updates landed correctly:
grep -n "\"version\": \"{version}\"" version.json src/Umbraco.Web.UI.Client/package.json src/Umbraco.Web.UI.Client/package-lock.json tests/Umbraco.Tests.AcceptanceTest/package.json tests/Umbraco.Tests.AcceptanceTest/package-lock.json
Expect exactly 7 matches (one per package.json and version.json, two per package-lock.json).
Stage only the 5 changed files:
git add version.json src/Umbraco.Web.UI.Client/package.json src/Umbraco.Web.UI.Client/package-lock.json tests/Umbraco.Tests.AcceptanceTest/package.json tests/Umbraco.Tests.AcceptanceTest/package-lock.json
Then commit with the message Bump version to {version}. — replacing {version} with the target version:
git commit -m "Bump version to {version}."
Output a summary:
Version bumped to {version} in:
- version.json
- src/Umbraco.Web.UI.Client/package.json
- src/Umbraco.Web.UI.Client/package-lock.json
- tests/Umbraco.Tests.AcceptanceTest/package.json
- tests/Umbraco.Tests.AcceptanceTest/package-lock.json
Changes staged and committed.
Add a value summary extension so a feature's typed value can be displayed compactly in collection views (e.g., table columns). Use when a feature or property editor already has a value type and needs a renderer for collection table cells. Two variants — simple (element only, no API call) and resolver (batch API resolution needed). Prerequisite: a value type constant must already exist — use the general-add-value-type skill first if it doesn't.
Add a new value type — a named, typed string constant that extends UmbValueTypeMap. Use when a feature needs to declare what type of value it holds so it can be referenced in collection columns or value summary manifests. Also use when a property editor needs to expose its value type for use in collection views.
Create or extend a repository in the Umbraco backoffice. Covers detail (CRUD), item (batch lookup), collection (paginated list), and action-specific (publish, duplicate, move, etc.) repositories. Use when the user says "create a repository", "add a data source", or when a feature needs to fetch or post data. Each repository type has its own template — pick the right one based on the operation.
Automated PR code review for Umbraco CMS. Analyzes changed files for intent, impact on consumers, breaking changes, architecture compliance, and code quality. Non-interactive — outputs a full structured review. Use this skill whenever the user asks to review a branch, review a PR, check their changes for issues, analyze a diff, or validate breaking change patterns — even if they don't say "review" explicitly. Does NOT apply to writing new code, fixing bugs, refactoring, explaining architecture, writing tests, or reviewing documentation content.
Create a new package in the Umbraco backoffice client with its first module. Use when adding a new domain feature area that needs its own package under src/packages/ — e.g., a new CMS feature like data types, tags, or relations. Packages are self-contained domain modules that can theoretically be uninstalled independently. Also use when the user says things like "scaffold a new package", "add a new feature package", or "create a new domain module".
Create a new workspace for an entity in the Umbraco backoffice. Supports two workspace types — default (simple, manifest-only, for root/listing pages) and routable (entity detail editing with create/edit flows). Use when the user says "create a workspace", "add a workspace for X", or "scaffold a workspace". For routable workspaces, the entity must already have a package, entity type, repository, and data source.