@uipath/skills 1.201.0-preview.473 → 1.201.0-preview.489

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uipath/skills",
-  "version": "1.201.0-preview.473",
+  "version": "1.201.0-preview.489",
   "description": "UiPath agent skills for Claude Code, Codex, Cursor, Copilot, Gemini and OpenCode — RPA, UI automation, UI testing, coded agents/apps/workflows, and troubleshooting. Distributed as the UiPath Claude Code plugin.",
   "author": {
     "name": "UiPath"

package/skills/uipath-ixp/SKILL.md

@@ -75,7 +75,7 @@ If the user provides a taxonomy file, use `--skip-taxonomy` and `import-taxonomy
 | "Import this taxonomy" / provides a taxonomy file | [Project Setup Guide](references/project-setup-guide.md) — Option B (`--skip-taxonomy` + `import-taxonomy`) |
 | "Label documents" / "Review predictions" | [Label Documents Guide](references/label-documents-guide.md) |
 | "Improve scores" / "Fix prompts" / "Improve F1" | [Improve Prompts Guide](references/improve-prompts-guide.md) |
-| "Publish the model" / "Tag as live" | `uip ixp projects publish <project-name> --output json` — publishes the latest version, untagged. Add `--tag <live\|staging>` to also tag it. See [cli-reference](references/cli-reference.md) for `--model-version`/`--description`. **Publishing does not deploy the model to an Orchestrator folder** — publishing makes the version usable *inside* the project; `deployments create` (see the "Deploy this model to a folder" row below) is what makes it callable at runtime by activity packs and Maestro Flow. Do NOT chain a deploy onto a publish unless the user asked to deploy — a deploy needs a folder key and changes what runtime callers get. |
+| "Publish the model" / "Tag as live" | `uip ixp projects publish <project-name> --output json` — publishes the latest version, untagged. Add `--tag <live\|staging>` to also tag it. See [cli-reference](references/cli-reference.md) for `--model-version`/`--description`. **Publishing does not deploy the model to an Orchestrator folder** — publish pins the version, and `--tag` moves the `live`/`staging` tag, which selects the version the DU framework serves (including to DU activities that call through it). Callers that resolve models from an Orchestrator folder — Maestro Flow among them — see only `deployments create` (the "Deploy this model to a folder" row below). Do NOT chain a deploy onto a publish unless the user asked to deploy — a deploy needs a folder key and changes what runtime callers get. |
 | "Roll back to a previous version" / "Restore version N" | `uip ixp projects publish <project-name> --model-version <N> --output json` — re-publishes an earlier version. Get available versions from `uip ixp projects list-models <project-name> --output json`. |
 | "Unpublish a model" / "Take a model out of production" | `uip ixp projects unpublish <project-name> --model-version <N> --output json` — removes a version from the published set (it stays trained/listable). `--model-version` is required; find published versions via `list-models` (`Pinned: true`). To change which version is live, `publish` a different one instead. |
 | "Remove the live/staging tag" / "Untag a version" | `uip ixp projects untag <project-name> --tag <live\|staging> --output json` — removes the named tag (the version it pointed at stays published). **`untag` is the only way to remove a tag** — do NOT `unpublish` or re-`publish` to clear it (`unpublish` removes publication, not the tag; `publish` without `--tag` leaves the existing tag untouched). To switch `live`→`staging`, `publish --tag staging` instead. |
@@ -121,7 +121,7 @@ These requests fall outside the skill. Recognise the request, reply with the sta
 |--------------|-------------------|
 | "Create a model" / "create a project" | **Documents or a taxonomy supplied →** use the [Project Setup Guide](references/project-setup-guide.md) (this skill creates the project from them). **Otherwise →** "I work on existing IXP projects rather than creating them from scratch. Create one in-product: https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/managing-projects — then I can label, review, and improve it." |
 | "Upload these files" / "add documents" | **Project named / already in context →** supported; upload it (see the "Upload a document" row in Task Navigation). **Otherwise →** "Name an existing project and I'll upload it — or upload in-product (e.g. for a new project): https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models." |
-| "Deploy this model" / "push to staging / production / folder / environment / tenant" | **Folder deployment is supported** — deploy with `uip ixp deployments create` (see the "Deploy this model to a folder" row in [Task Navigation](#task-navigation)). If the user NAMES a folder rather than giving its key, resolve the name with `uip or folders list --output json` — ask only when no folder was identified at all. For anything that is not an Orchestrator folder: "I deploy model versions to Orchestrator **folders**. Binding to environments or another tenant is a product-side flow: https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models." Note `projects publish --tag staging\|live` tags a version *inside* the project — it deploys nothing. |
+| "Deploy this model" / "push to staging / production / folder / environment / tenant" | **Folder deployment is supported** — deploy with `uip ixp deployments create` (see the "Deploy this model to a folder" row in [Task Navigation](#task-navigation)). If the user NAMES a folder rather than giving its key, resolve the name with `uip or folders list --output json` — ask only when no folder was identified at all. For anything that is not an Orchestrator folder: "I deploy model versions to Orchestrator **folders**. Binding to environments or another tenant is a product-side flow: https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-deploying-models." Note `projects publish --tag staging\|live` moves the tag the DU framework (and DU activities calling through it) resolve — for those consumers that IS the staging/live switch; it creates no folder deployment. |
 | "Give X access" / "share this project" / "change roles or permissions" | "Access, roles, and permissions are managed in-product, not through this skill: https://docs.uipath.com/ixp/automation-cloud/latest/overview/managing-access." |
 | "Use this model in my automation / workflow / agent" / "call the extractor from a process" | "Consuming a published model inside an automation is an authoring task outside this skill. See https://docs.uipath.com/ixp/automation-cloud/latest/user-guide/building-and-consuming-a-workflow." |
 | "Mine these emails / communications" / "set up Communications Mining" | "Communications Mining is a separate IXP capability this skill doesn't cover (this skill is document extraction). See https://docs.uipath.com/ixp/automation-cloud/latest/cm-user-guide/introduction-to-uipath-communication-mining." |

package/skills/uipath-ixp/references/improve-prompts-guide.md

@@ -278,8 +278,8 @@ That is 0.2 at `Annotations` = 5 — one flipped annotation is not evidence —
 
 **A small `Annotations` has two causes with opposite remedies.** `Annotations` counts reviewed **extractions**, not documents — one document can contribute several — so it cannot be compared against a document count directly. Compare the field's own `Documents` against the project-level `ValidatedDocuments`:
 
-- **`Documents` equal to `ValidatedDocuments`, or short by one or two** → the sample is already as large as the labelled data allows (a small shortfall is missing markers — the field legitimately absent from a document — not an unreviewed field). Tag it **UPLOAD**.
-- **`Documents` materially below `ValidatedDocuments`** → some labelled documents carry no label for this field: never reviewed there, or reviewed and skipped because the prediction was wrong. Tag it **REVIEW** — those documents need the standard review pass ([Label Documents Guide](label-documents-guide.md)), which 2a-check's `Recall < 0.5` gate would never trigger here.
+- **`Documents` equal to `ValidatedDocuments`** → this field already has evidence on every labelled document; the sample is as large as the data allows. Tag it **UPLOAD**.
+- **`Documents` below `ValidatedDocuments`** → some labelled documents carry no evidence for this field, and the payload cannot say why — never reviewed there, or reviewed and skipped because the prediction was wrong. Tag it **REVIEW** — the review pass ([Label Documents Guide](label-documents-guide.md)) shows which in seconds, and 2a-check's `Recall < 0.5` gate would never trigger it. Even when the review finds nothing to add, confirming that costs a glance, while an unreviewed document left unfound caps the field for good.
 
 Both tags are **final-report lines, not loop actions**: the loop runs on to its normal stopping criteria — never pause mid-run to ask for documents or to review — and the report then says plainly that a tagged field's score cannot rise further until its sample grows.
 

package/version-manifest.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 2,
-  "skillsVersion": "1.201.0-preview.473",
+  "skillsVersion": "1.201.0-preview.489",
   "targetCli": "^1.201.0"
 }