/uipath-bundles

name: uipath-bundles
description: "UiPath Orchestrator bundles — versioned file trees in an Orchestrator folder, one command group per kind: knowledge bundles (`uip or kb`, Open Knowledge Format documents an agent reads as context, changed through reviewed change proposals) and skill bundles (`uip or skill-bundles`, the agent skills an agent loads, published directly, with version tags). Find, create, download, read a version or file, publish, compare a workspace, propose and merge (knowledge), tag (skills). PREVIEW: both command groups exist only on a prerelease `uip` build, and only on tenants with that kind's feature enabled — Step 0 checks; a miss means stopping. For Orchestrator assets, queues, buckets, jobs→uipath-platform. For context grounding / semantic search indexes→uipath-platform. For `uip solution` lifecycle→uipath-solution. For building the agent that uses the skills→uipath-agents."
when_to_use: "User says 'bundle', 'knowledge bundle', 'skill bundle', 'OKF', 'Open Knowledge Format', 'download the bundle', 'publish docs to Orchestrator', 'publish the skills to Orchestrator', 'what version of the bundle', 'bundle manifest', 'change proposal on a bundle', 'merge the proposal', 'comment on the proposal', 'tag the skill bundle', 'pin the skills to a version', 'roll the tag back', 'uip or kb', 'uip or skill-bundles'. Also when the documents an agent reads, or the skills it loads, are said to live in an Orchestrator folder rather than in the repo."
allowed-tools: Bash, Read, Write, Glob, Grep
user-invocable: true

UiPath Bundles — `uip or kb` and `uip or skill-bundles`

A bundle is a folder-scoped Orchestrator entity holding a versioned file tree. Versions are immutable and numbered (v1, v2, …). Content is addressed by hash, so transfers move only what changed. Each kind has its own command group, and the two lifecycles differ where it matters most:

| | Knowledge bundle | Skill bundle | |---|---|---| | Holds | Markdown documents (Open Knowledge Format) an agent reads as context | Agent skills an agent loads | | Command group | `uip or kb` | `uip or skill-bundles` (alias `uip or skill-bundle`) | | Bundle argument | Its key (GUID) | Its name or its key | | Version 1 | `publish` or `create --input` | `publish` or `create --input` | | Later versions | Only by merging a reviewed change proposal | `publish` from a workspace | | Reads take | A version number or `latest` | A number, a tag, a `sha256:` tree digest, or `latest` | | Only here | Change proposals, `share`, `build` | Version tags |

Critical Rules

1. **Identify the kind first, and keep each key with its group.** The kind is the one the user or task names (knowledge documents / OKF / proposals → `kb`; skills / tags → `skill-bundles`). When only a key is known, the group whose `get` (or `list`) returns the record owns it. Never pass one kind's key to the other group: it is refused with `This key is not a knowledge bundle.` or `This key is not a skill bundle.` — switch groups, do not retry. 2. **Preflight that group before anything else** (Step 0). `unknown command` means a stable build; a command the platform refuses means the tenant's feature for that kind is off. Both are stop conditions — say so and stop, never substitute the other group, bucket, asset or context-grounding commands. 3. **Every command needs a folder.** `--folder-path <FOLDER_PATH>` or `--folder-key <FOLDER_KEY>` every time. The one exception: inside a downloaded knowledge-bundle workspace `kb` reads the folder and bundle from the marker. Skill-bundle commands always take the folder; only `skill-bundles status` runs without one. 4. **Keys and ids come from the CLI, never from you.** Bundle keys from `list` or `get`, proposal ids from `change-proposal list`. Do not construct, guess, or carry one over from another folder. 5. **Later versions follow the kind.** A knowledge bundle's `publish` and `create --input` only ever make version 1; every later version comes from merging a change proposal. A skill bundle's `publish` takes the directory as the whole next version, so publish only from a full workspace: a base file the directory lacks is **deleted** (hidden files excepted, see Skill bundles). 6. **A 409 is never solved by deleting the bundle.** Deleting and re-creating destroys the version history, the review record and every tag. What each 409 means is in Failures. 7. **A refusal is not a login problem, and a content 404 does not prove the bundle is missing.** A 403 or a feature refusal needs an administrator. A 404 `BundleDto does not exist.` from a content command needs the `get` check in Step 0 before anything else. Never re-run `uip login`, retry, or re-create the bundle to get past either. 8. **Paths are bundle-relative and cannot climb.** A `--path` or `--artifact` with a `.` or `..` segment is refused before any request is sent; pass the path as the manifest lists it. 9. **Irreversible steps need their check first.** Knowledge: `diff` before `merge` — a merge publishes a version that cannot be edited. Skills: an immutable tag can never be moved or deleted, by anyone, so pass `--immutable` only when the user asked for an immutable tag in those words; confirm the version with `versions` before `tags set`; `publish --yes` only after the user approved the `DeletedPaths`.

Step 0: Preflight — is this surface available?

Run once per session, for the group the kind needs:

uip or kb --help
uip or skill-bundles --help

• **Succeeds** → continue.
• **`unknown command`** (either group) → the installed `uip` is a stable build. Both groups register only on a prerelease build (`preview` / `dev` channel). Tell the user that plainly and stop — do not substitute the other group, bucket, asset or context-grounding commands, and do not guess an older command name.
• **The platform refuses a command** (`permission_denied`, a feature refusal) → the tenant lacks that kind's feature (knowledge bundles and skill bundles are enabled separately),