@uipath/skills 1.201.0-preview.614 → 1.201.0-preview.620

package/CODEOWNERS

@@ -195,5 +195,5 @@
 /tests/tasks/activation/uipath-process-mining.jsonl @UiPath/team-backendhoven
 
 # Automation Hub skills (Open API publish/read of processes via the user's cloud token)
-/skills/uipath-automationhub/ @parth-patil-uipath @abhiram-vad
-/tests/tasks/uipath-automationhub/ @parth-patil-uipath @abhiram-vad
+/skills/uipath-automationhub/ @UiPath/automationhub @parth-patil-uipath @abhiram-vad
+/tests/tasks/uipath-automationhub/ @UiPath/automationhub @parth-patil-uipath @abhiram-vad

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uipath/skills",
-  "version": "1.201.0-preview.614",
+  "version": "1.201.0-preview.620",
   "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-automationhub/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: uipath-automationhub
-description: "Publish and read business processes in UiPath Automation Hub via the Open API, using the user's cloud login — no admin OpenAPI token needed. PUBLISH an approved process and its PDD/SDD documents (schema-driven payload, base64 file upload or link) to AH as the system of record — e.g. a process captured/approved by Process Scribe. GET a process back by id or search, list its attached documents, and DOWNLOAD their file bytes (e.g. for dedup / related-idea lookups or retrieving a published PDD). Authenticates with the user's cloud bearer token and NEVER sends the admin `x-ah-openapi-auth` header. Routes by intent to `references/publish-process.md` (publish/create/upload) or `references/get-process.md` (get/read/fetch/list), over the shared auth + endpoint catalog in `references/api-endpoints.md`. Structured to extend to more Automation Hub Open API operations."
+description: "Publish and read business processes in UiPath Automation Hub via the Open API, using the user's cloud login — no admin OpenAPI token needed. PUBLISH an approved process and its PDD/SDD documents (schema-driven payload, base64 file upload or link) to AH as the system of record — e.g. a process captured/approved by Process Scribe. GET a process back by id or search, list its attached documents, and DOWNLOAD their file bytes (e.g. for dedup / related-idea lookups or retrieving a published PDD). Authenticates with the user's cloud bearer token and NEVER sends the admin `x-ah-openapi-auth` header. CLI-first: when the installed `uip` has the `ah` commands, flows run through them (`references/*-cli-guide.md`); otherwise the raw Open API flows apply. Routes by intent to publish (create/upload) or get (read/fetch/download) references over the shared catalogs. Structured to extend to more Automation Hub operations."
 allowed-tools: Bash, Read, AskUserQuestion
 user-invocable: true
 ---
@@ -9,11 +9,18 @@ user-invocable: true
 
 Work with business processes in UiPath Automation Hub (AH) through the AH Open API, authenticating with the **user's cloud access token** — the user does **not** need an admin-generated OpenAPI token. This one skill covers both writing a process to AH and reading one back; pick the flow below.
 
-## Step 0: Read the API reference
+## Step 0: Preflight — pick the transport once
 
-Always read [`references/api-endpoints.md`](references/api-endpoints.md) first. It is the shared source of truth for the cloud-token auth model, the base/gateway URL, the exact headers (**and which header to never send**), and every endpoint the flows use.
+Run `uip ah --help` once per session:
 
-## Authentication (shared — both flows)
+- **Succeeds** → use the **CLI flows**. Read [`references/cli-commands.md`](references/cli-commands.md) (command catalog + auth), then the matching `*-cli-guide.md` flow. Auth is handled by `uip` itself — never touch a token.
+- **Fails with `unknown command 'ah'`** (CLI predates the AH surface) → use the **raw Open API flows**. Read [`references/api-endpoints.md`](references/api-endpoints.md) (auth model, gateway URL, exact headers — and the header to never send), then the matching flow.
+
+Never mix the two transports in one run. The domain contract — required fields, wrapping rules, document types — is identical either way and lives in `api-endpoints.md`.
+
+## Authentication (raw-API flows only — skip when using the CLI flows)
+
+> On the CLI path, `uip` handles auth itself (Delegate env-auth or `uip login`) — never touch a token there; see [`references/cli-commands.md`](references/cli-commands.md). The resolution order below applies **only** to the raw-API flows.
 
 Resolve the cloud token + base URL + org + tenant in this **priority order**:
 
@@ -40,16 +47,23 @@ The platform injects tenant-routing headers from the `{org}/{tenant}` segments
 
 ## Routing — pick the flow by intent
 
-Classify what the user wants, then follow the matching reference. All flows share the Authentication section above and the endpoint catalog in `references/api-endpoints.md`.
+Classify what the user wants, then follow the matching reference. The **raw-API flows** share the Authentication section above and the endpoint catalog in `references/api-endpoints.md`; the **CLI flows** never touch either — `uip` handles auth itself (see [`references/cli-commands.md`](references/cli-commands.md)).
 
-| The user wants to... | Follow |
-|---|---|
-| **Publish / create / upload** a process (+ its PDD/SDD documents) to AH | [`references/publish-process.md`](references/publish-process.md) |
-| **Get / read / fetch / list** a process (+ its documents) from AH | [`references/get-process.md`](references/get-process.md) |
-| Shared **auth + endpoint catalog** (base URL, headers, every endpoint, error codes) | [`references/api-endpoints.md`](references/api-endpoints.md) |
+| The user wants to... | CLI available (preferred) | CLI unavailable |
+|---|---|---|
+| **Publish / create / upload** a process (+ its PDD/SDD documents) to AH | [`references/publish-process-cli-guide.md`](references/publish-process-cli-guide.md) | [`references/publish-process.md`](references/publish-process.md) |
+| **Get / read / fetch / download** a process (+ its documents) from AH | [`references/get-process-cli-guide.md`](references/get-process-cli-guide.md) | [`references/get-process.md`](references/get-process.md) |
+| Shared **command / endpoint catalog** | [`references/cli-commands.md`](references/cli-commands.md) | [`references/api-endpoints.md`](references/api-endpoints.md) |
 | _(future AH Open API operation — add a row here)_ <!-- uip-check-skip --> | _add `references/<operation>.md` and route to it_ |
 
-To add a new capability (e.g. a future AH `uip` CLI surface or another Open API operation), keep this skill's product shape: add one `references/<operation>.md`, add a row above, and reuse this shared Authentication section — do not create a new per-operation skill.
+**Extending this skill** (new AH operation, new field, new integration like the Studio Web link) — keep the shape, and put each kind of change in exactly one home:
+
+- **A new domain fact** (a field's format, a required rule, an id table): document it once in [`references/api-endpoints.md`](references/api-endpoints.md) — the transport-independent contract — and have the flow steps *reference* it rather than restate it. Never fork a fact across the CLI and API files.
+- **A new operation / user intent**: add a `references/<operation>-cli-guide.md` flow (and, only while the raw-API fallback still exists, an API twin), plus one row in the routing table above and, if new commands are involved, rows in `cli-commands.md`. Do not create a new per-operation skill.
+- **A new optional capability inside an existing flow** (like Step 6b, Studio Web): add it as an optional step in that flow, with its discovery recipe and a never-invent rule.
+- **When the raw-API fallback retires** (once an `ah`-capable `uip` release is ubiquitous): delete the API flow files and the preflight's fallback arm in one commit — the CLI files are self-contained by design.
+
+Every addition keeps the skill's three invariants: collect inputs before the first write, verify before reporting success, and never invent a value the tenant didn't provide.
 
 ## Notes
 

package/skills/uipath-automationhub/references/api-endpoints.md

@@ -67,6 +67,8 @@ Body:
 | `OVR-PROCESS_OWNER` | `ah-section-ovr-0-0` | `"<email>"` (direct string) |
 | `OVR-OVERVIEW_PROCESS_SUBMITTER` | `ah-section-ovr-0-1` | `"<email>"` (direct string) |
 
+**Studio Web link** (optional): the schema's `OVR-OVERVIEW_STUDIO_WEB_LINK` question links the process to a Studio Web solution. Its `value` is a JSON **string** — `{"url": "<{baseUrl}/{org}/studio_/designer/{projectId}?solutionId={id}>", "name": "<solution name>", "hasProcessMap": <bool>}` (`url` required; `hasProcessMap: true` only when the solution's orchestration project has a `.bpmn` — it drives AH's Maestro diagram preview). Settable at create or via the update path; empty string unlinks.
+
 When a required field is missing the API may return `errorDetails: {}` (no field named) with `"Please fill in all the required information"` — usually the un-flagged owner/submitter, but **tenant admins can mark additional questions required** (commonly "Applications used"/"Thin applications used"); diff the payload against every `required`-flagged question in the live schema.
 
 **Response 201** — the standard envelope with the created process **nested under `data`**: `{ "message": "Resource Created", "statusCode": 201, "data": { "process_id": …, "process_uuid": …, "process_name": … } }`. Read **`data.process_id`** — it is NOT at the top level. If you received a 201 the process WAS created — never re-POST because a field read came back undefined; re-read the response instead. *(Used by the publish flow.)*

package/skills/uipath-automationhub/references/cli-commands.md

@@ -0,0 +1,46 @@
+# Automation Hub via the `uip ah` CLI — Command Catalog
+
+> **Preflight (run once per session):** `uip ah --help`. If it errors with `unknown command 'ah'`, the installed CLI predates the Automation Hub surface — tell the user to update `uip` (or follow the raw-API flows in [`api-endpoints.md`](api-endpoints.md) instead). Never mix the two paths in one run.
+
+The CLI wraps the same Open API endpoints as [`api-endpoints.md`](api-endpoints.md) — every domain fact there (required fields, wrapping rules, document-type ids, tenant-required questions) still applies. What the CLI adds: auth is handled for you, every response is one uniform JSON envelope, and windowing/projection quirks are absorbed.
+
+## Auth — nothing to do
+
+`uip` resolves credentials itself, in this order:
+1. **Delegate runtime env-auth**: the Delegate injects `UIPATH_CLI_AUTH_TOKEN` + org/tenant vars; `uip` consumes them natively. No setup.
+2. **`uip login` session** (`~/.uipath/.auth`).
+
+If a command fails with an authentication error, tell the user to run `uip login` — never ask for or handle a raw token yourself.
+
+## Output envelope (every command)
+
+Always pass `--output json`. Success:
+
+```json
+{ "Result": "Success", "Code": "Ah<Group><Verb>", "Data": … }
+```
+
+Failure: `Result` is `Failure`/`ValidationError` with a `Message` and usually an `Instructions` hint — surface both to the user. Exit codes: `0` success, `1` failure, `3` validation.
+
+> ⚠️ **`--output-filter` requires an explicit `--limit`.** List commands default to `--limit 20`, and the CLI rejects an output filter on an implicit page (validation error, exit `3`) because it would silently filter only the first 20 records. Whenever you pass `--output-filter`, also pass a `--limit` sized to cover the full result set (the option's `--help` text states the command's maximum).
+
+## Commands used by the flows
+
+| Command | Purpose | Data shape notes |
+|---|---|---|
+| `uip ah auth-info get` | connectivity + who/where am I | `Data.Tenant.Url`, `Data.User` |
+| `uip ah idea-flows list` | flow names → ids | entries carry `Id`, `Name`, `Phases` |
+| `uip ah automations schema get --idea-flow-id <id> --destination <file>` | write the flow's schema + `user_inputs` template to a file | same document as the raw `/idea-schema` |
+| `uip ah categories get` | category tree | `Data.Levels` + `Data.Categories` (nested `subcategories`; pick `category_is_active: 1` only) |
+| `uip ah users list --limit 50` | owner/submitter discovery | entries carry `Email`, `IsActive` |
+| `uip ah applications list` | app inventory (tenant-required application questions) | entries carry `Id`, `Name` |
+| `uip ah automations create --from-schema --idea-flow-id <id> --file <answers.json>` | **create the process** | `Data.Id` is the new process id |
+| `uip ah documents create <automation-id> --title <t> --description <d> --document-type-id <n> --file <path>` | **upload a document's bytes** | `Data.Id` (document id) + `Data.FileId`; use `--embed-link <url>` *instead of* `--file` for link-only docs (exactly one of the two) |
+| `uip ah documents list <automation-id>` | verify attachments | entries carry `Id`, `Title`, `FileId` (file-backed) or `EmbedLink` (link-backed) |
+| `uip ah documents download <file-id> --destination <path>` | **download a document's bytes** | takes the `FileId` from `documents list`, **not** the document `Id` |
+| `uip ah automations update <id> --file <answers.json>` | edit assessment answers post-create (e.g. set the Studio Web link) | same `user_inputs` document shape as create |
+| `uip ah automations list --search <text> --limit 20` | name → process id | projected records with `Id`, `Name`, `Phase` |
+| `uip ah automations get <id> [--all-fields]` | one process record | default projection has `Id`/`Name`/`Phase`/`Tags`; `--all-fields` for the raw record (needed for `process_slug`) |
+| `uip ah components list --automation-id <id>` | linked components (optional, get flow) | same record shape as the tenant-wide catalogue |
+
+**Version note:** the `ah` surface first appears in `uip` **1.201.0** (as of 2026-08-21 no public release ships it — the latest release is 1.199.0; the Step-0 preflight routes older installs to the raw-API flows). `documents create --file` and `automations create --idea-flow-id` additionally come from CLI PR #3720 — if either flag is rejected as unknown, the installed `uip` has the `ah` surface but predates those flags: tell the user to upgrade `uip` and **stop**. Never switch to the raw-API path mid-run — the transport was already selected at preflight.

package/skills/uipath-automationhub/references/get-process-cli-guide.md

@@ -0,0 +1,58 @@
+# Get a Process from Automation Hub — `uip ah` CLI flow
+
+Fetches one process (by id or search) and its documents, and downloads document bytes on request. Read-only. Auth is handled by the CLI — you never touch a token.
+
+> **Use this flow only after the preflight in [`cli-commands.md`](cli-commands.md) passed.** All commands: append `--output json`.
+
+## Step 1: Resolve the process
+
+- Caller gave an **id** → use it.
+- Otherwise search:
+  ```bash
+  uip ah automations list --search "<name>" --limit 20 --output json
+  ```
+  One clear match → its `Id`. Several → show name + id + owner, ask. None → say so and stop.
+
+## Step 2: Fetch the process
+
+```bash
+uip ah automations get $PROCESS_ID --output json
+```
+
+`Data` is the projected record (`Id`, `Name`, `Phase`, `PhaseStatus`, `Tags`, …). Add `--all-fields` only when you need the raw record (e.g. `process_slug` for the deep link). `Failure` with not-found → no such process; auth error → `uip login`.
+
+## Step 3: Fetch the documents
+
+```bash
+uip ah documents list $PROCESS_ID --output json
+```
+
+Each entry carries `Id` (document id), `Title`, `TypeId`, and **either** a `FileId` (file-backed — downloadable) **or** an `EmbedLink` (link-backed — show the URL; nothing to download).
+
+## Step 3b: Download a document (when the caller wants the bytes)
+
+Only file-backed documents download, and the command takes the **`FileId`** — not the document `Id`:
+
+```bash
+uip ah documents download $FILE_ID --destination "<path>" --output json
+```
+
+> 📁 **Download to the current working directory — never `/tmp`.** Hosted runtimes (e.g. the Delegate) sandbox their file tools to the session workspace: the CLI can write to `/tmp`, but every file-tool access to the download then fails with an access-denied error.
+
+- `Data` reports `Destination` and `Bytes` — confirm the file exists and is non-empty before reporting success.
+- Link-backed documents: present the `EmbedLink` instead. Never invent a download path.
+
+## Step 4: Present
+
+```
+Process: <name>  (process_id: <id>)
+  Status:   <phase/status>
+  Category: <category>
+  Owner:    <owner>
+  View:     {Data.Tenant.Url}/automation-profile/{process_slug}/documentation
+Documents:
+  - PDD  (document_id 12, file_id 42 — downloadable)
+  - SDD  (document_id 13, embed_link — link only)
+```
+
+`process_slug` comes from `automations get --all-fields`; the base from `uip ah auth-info get` → `Data.Tenant.Url`, which is **already the full AH tenant base** (`…/{org}/{tenant}/automationhub_`) — append only `/automation-profile/{process_slug}` (+ `/documentation`), never re-append org/tenant segments. Offer the raw JSON, downloads, or components (`uip ah components list --automation-id <id>`) if relevant.

package/skills/uipath-automationhub/references/publish-process-cli-guide.md

@@ -0,0 +1,104 @@
+# Publish a Process to Automation Hub — `uip ah` CLI flow
+
+Creates one process from a schema-driven payload and attaches its documents (PDD/SDD), using `uip ah` commands. Auth is handled by the CLI (Delegate env-auth or `uip login`) — you never touch a token.
+
+> **Use this flow only after the preflight in [`cli-commands.md`](cli-commands.md) passed.** All commands: append `--output json`. The domain contract (required fields, wrapping rules, document types) is the same one [`api-endpoints.md`](api-endpoints.md) documents — the CLI only changes the transport.
+
+## Step 1: Verify connectivity (and fetch the idea flows)
+
+```bash
+uip ah idea-flows list --output json
+```
+
+- `Result: Success` → keep `Data` (flow names + ids) and tell the user "Connected to Automation Hub."
+- Auth failure → tell the user to run `uip login` (or, in Delegate, to sign in). Never ask for a raw token.
+- `Failure` mentioning the tenant/enablement → AH is not enabled on this tenant; stop.
+
+## Step 2: Pick the idea flow
+
+Default to the entry whose `Name` contains "Business Process" (case-insensitive); take its `Id`. If the caller named a different flow, use that. Several candidates → ask. None → say Business Process flows may not be enabled and stop. Store `IDEA_FLOW_ID`.
+
+## Step 3: Fetch the schema
+
+```bash
+uip ah automations schema get --idea-flow-id $IDEA_FLOW_ID --destination ./ah-schema.json --output json
+```
+
+> 📁 **Working files (`ah-schema.json`, `ah-answers.json`, and any document files you generate for upload) go in the current working directory — never `/tmp`.** Hosted runtimes (e.g. the Delegate) sandbox their file tools to the session workspace: a file written to `/tmp` is readable by the CLI but every file-tool access to it fails with an access-denied error.
+
+Read `./ah-schema.json`: the field catalog is under `properties.schema.properties` (Assessment Type > Section > Question; enums carry `answer_option` codes) and `user_inputs` is the payload template.
+
+> ⚠️ **Do NOT submit `user_inputs` verbatim** — its example values are placeholders the API rejects (category `1`, placeholder answer codes, example emails). Shape only.
+
+## Step 4: Collect the inputs, then assemble the answers file
+
+**Collect every required input BEFORE creating** — same rules as the API flow, with CLI discovery:
+
+First **enumerate the tenant's actual required set from the schema file**: every `required`-flagged question, plus owner + submitter (enforced but never flagged). Tenant admins add required questions (commonly "Applications used"/"Thin applications used") — the baseline table is a minimum, never the whole list. Resolve each: from the caller's material, the recipes below, or `AskUserQuestion` — never by inventing.
+
+| Input | Recipe |
+|---|---|
+| Process **name** | Ask. Non-empty; duplicates fail with a 409-style error. |
+| **Description** | Ask, or derive from the material and confirm. |
+| **Category id** | `uip ah categories get` → pick from `Data.Categories` (**`category_is_active: 1` only**); several plausible → ask with names. Never the template's `1`. |
+| **Documentation** answer code | The `PROCESS_DOCUMENTS` question's own `enum` in the schema — match by label, send its `answer_option` code. |
+| **Owner email** | `uip ah users list` → must be a listed `Email` (prefer `IsActive: 1`). Default to the signed-in user; confirm. |
+| **Submitter email** | Same as owner; usually the same person. |
+| **Application questions** (when tenant-required) | `uip ah applications list` → valid entries; if the material leaves systems unconfirmed, ask — never record an app the material does not support. Follow the question's own schema shape. |
+
+The discovery commands are independent — run the ones you need (`categories get`, `users list`, `applications list`) **in a single shell invocation** rather than one per turn; each is fast, the round-trips between them are not.
+
+Write the answers to `./ah-answers.json` as the filled `user_inputs` structure (the CLI accepts the whole schema-get document or just the answers map). Wrapping rules unchanged: most fields `{ "value": <v> }`; owner/submitter are **direct strings**; enum codes from that field's own `enum`; integers as numbers. Show the user a concise preview and get a confirm before writing.
+
+## Step 5: Create the process
+
+```bash
+uip ah automations create --from-schema --idea-flow-id $IDEA_FLOW_ID --file ./ah-answers.json --output json
+```
+
+- `Result: Success` → **`Data.Id`** is the new process id. A success means it WAS created — never re-run on a confusing field read (that duplicates).
+- `ValidationError`/`Failure` → the `Message`/`Instructions` carry the service's validation text; the same causes as the API flow apply (unnamed required field → owner/submitter first, then diff against the schema's required set; `Invalid Category Id`; placeholder answer codes). Fix and retry **once**.
+
+## Step 6: Attach documents (PDD/SDD)
+
+Attach every supplied document — default to all; ask only when two files look like the same document in different formats (in the Step 4 round). Per document:
+
+```bash
+uip ah documents create $PROCESS_ID \
+  --title "PDD - <name>" --description "<desc>" \
+  --document-type-id <n> --file "<path>" --output json
+```
+
+- `--document-type-id` from the fixed platform table in [`api-endpoints.md`](api-endpoints.md) — read it there; do not guess ids.
+- `--file` uploads the bytes (the CLI base64s it; any file type; 200 MB cap). Use `--embed-link <url>` *instead* only when the caller has a URL and no bytes — exactly one of the two, and never invent a URL.
+- Record `Data.Id` (document id) and `Data.FileId` from each response. On a validation error, surface the message and continue with the remaining documents.
+
+## Step 6b (optional): Link a Studio Web solution
+
+When the caller wants the process linked to a Studio Web solution (or supplies one), set the `OVR-OVERVIEW_STUDIO_WEB_LINK` question — at create time inside `user_inputs`, or afterwards via `uip ah automations update $PROCESS_ID --file <answers.json>`. The answer's exact value format (JSON-string `value` with a required `url`, `hasProcessMap` semantics, empty string to unlink) is a domain fact — read it in [`api-endpoints.md`](api-endpoints.md) (**Studio Web link**), don't restate it.
+
+- **Resolve the solution from the caller — no CLI discovery exists.** No stable `uip` command lists Studio Web solutions today, so ask the user (`AskUserQuestion`) for the solution's **designer URL** — they can copy it from the browser address bar with the solution open in Studio Web. If they instead supply a solution id + project id, build the URL per the catalog's designer-URL shape (`projectId` = the solution's ProcessOrchestration project). **Never invent, guess, or search for a solution id or URL.**
+- If the caller doesn't know whether the solution has a `.bpmn` (the `hasProcessMap` condition), omit that field rather than guessing.
+
+## Step 7: Verify, then report
+
+Both verification reads are independent — run them in **one shell invocation**:
+
+```bash
+uip ah documents list $PROCESS_ID --output json
+uip ah automations get $PROCESS_ID --all-fields --output json   # read process_slug from Data
+```
+
+Every attached document id must appear in the documents list (file-backed ones with a `FileId`). Missing → report it failed; never claim an attach you didn't see in this list.
+
+The report **MUST end with both View deep links** — the URL segment is `process_slug` from the `--all-fields` record.
+
+```
+Published to Automation Hub:
+  Process: <name>  (process_id: <id>)
+  Documents: PDD ✓ (doc 12, file 42), SDD ✓ (doc 13, file 43)
+  View process:   {Data.Tenant.Url}/automation-profile/{process_slug}
+  View documents: {Data.Tenant.Url}/automation-profile/{process_slug}/documentation
+```
+
+Build the links from the tenant the write went to: `uip ah auth-info get` → `Data.Tenant.Url` is **already the full AH tenant base** (`…/{org}/{tenant}/automationhub_`) — append only `/automation-profile/{process_slug}` (+ `/documentation`), never re-append org/tenant segments.

package/skills/uipath-automationhub/references/publish-process.md

@@ -139,6 +139,20 @@ base64 -i "<FILE_PATH>" | tr -d '\n'   # macOS/Linux; use `base64 -w0 "<FILE_PAT
 
 Record each returned id — it is nested: read **`data.document_id`** from the response envelope. On 400, surface the validation message and continue with the remaining documents.
 
+## Step 6b (optional): Link a Studio Web solution
+
+When the caller wants the process linked to a Studio Web solution (or supplies one), set the `OVR-OVERVIEW_STUDIO_WEB_LINK` question — at create time inside `user_inputs` (Step 4), or afterwards:
+
+```bash
+curl -s -w "\n%{http_code}" -X PATCH \
+  -H "Authorization: Bearer $ACCESS_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"user_inputs": { ...only this question, in its Step-4 shape... }}' \
+  "$BASE_URL/$ORG/$TENANT/automationhub_/api/v1/openapi/automations/$PROCESS_ID"
+```
+
+The answer's exact value format (JSON-string `value` with a required `url`, `hasProcessMap` semantics, empty string to unlink) is a domain fact — read it in [`api-endpoints.md`](api-endpoints.md) (**Studio Web link**). Resolve the solution from the caller — ask for the designer URL (no discovery API exists on this path either); **never invent, guess, or search for a solution id or URL**, and omit `hasProcessMap` if the caller doesn't know whether the solution has a `.bpmn`.
+
 ## Step 7: Verify, then report
 
 **Verify before claiming success** — read the process back and confirm the documents landed:

package/skills/uipath-ixp/SKILL.md

@@ -58,7 +58,7 @@ Do not answer these from this skill. Re-activate `uipath-maestro-flow` and follo
 18. **`Occurrence` is scoped to the read that produced it — re-read predictions after every per-occurrence write.** The server pairs annotations with predictions and returns **matched pairs first**, so confirming one row of a repeatable group moves that row to `Occurrence` 0 on the next read and renumbers the rest (the IXP UI shows it first too). Nothing is lost — the row keeps its own values and page location — but the indices you read *before* the write no longer identify the same rows. So: confirm/unconfirm every target in ONE `--updates` call (all its indices resolve against the same read), and when sequential per-occurrence calls are unavoidable, re-run `get-predictions` between them and re-locate each row by its field values, never by the index you saw earlier. Only fully-unannotated and fully-annotated documents read back in document order. Report rows to the user by value ("the freight-surcharge line"), not by index.
 19. **Confirm against the version you reviewed — pass `--model-version`.** Confirming triggers a retrain, so predictions can drift between your `get-predictions` read and your `confirm`. Pass the read's `ModelVersion` as `confirm -m <N>`; if a retrain changed the version since, the confirm is rejected (`PredictionVersionChangedError`) rather than stamping values you never reviewed as ground truth. On that error, re-read `get-predictions`, re-review, and confirm against the new version. Confirming on a user-supplied review (Rule 15) is no exemption: pin the `ModelVersion` the user names, or run one `get-predictions` to capture it — a read for the version alone is not a re-review.
 20. **`DeploymentName` ≠ `DeploymentTitle`, and `create` never repoints.** `deployments create --title` sets a free-form `DeploymentTitle`; the name the **runtime** resolves is `DeploymentName`, which the backend slugs and suffixes per deployment (`invoices` → `invoices-08963f00-ixp`) and which **cannot be predicted from the request** — read it off the create response or `deployments list`, never construct it. `create` only ever ADDS: repointing an existing deployment to another version is `deployments upgrade <project-name> <deployment-name>`, which takes `DeploymentName` (passing a title there is a `404`). Run `deployments list` before every `upgrade`. Upgrading changes which model version **every runtime caller of that folder and name** gets — confirm intent before touching a shared folder. See [CLI Reference § Deployments](references/cli-reference.md#deployments).
-21. **`get-metrics` defaults to LATEST, not LIVE — always name the version you report.** A project keeps accumulating trained versions long after its live one was pinned, and the latest can score *worse* than what's deployed — so a bare `get-metrics` pairs the latest version's numbers with the live version identity you read from `list-models`. Resolve the version FIRST (`list-models` → `Tags[]` Name=`live`, else highest `Models[]` `Pinned: true`, else latest), pass it as `get-metrics --model-version <N>`, and state which version the scores belong to.
+21. **`get-metrics` defaults to LATEST, not LIVE — always name the version you report.** A project keeps accumulating trained versions long after its live one was pinned, and the latest can score *worse* than what's deployed — so a bare `get-metrics` pairs the latest version's numbers with the live version identity you read from `list-models`. Resolve the version FIRST, from what the user is asking — **how is it performing / production**: the live version (`list-models` → `Tags[]` Name=`live`, else highest `Models[]` `Pinned: true`, else latest); **baseline for improving instructions**: the LATEST trained version, because that is the model your edits retrain ([Improve Prompts Guide § 1a](references/improve-prompts-guide.md#1a-get-baseline-metrics)) — then pass it as `get-metrics --model-version <N>`, and state which version the scores belong to.
 
 ## Quick Start
 

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

@@ -80,9 +80,11 @@ If documents were just labelled (or uploaded, or the taxonomy was edited), wait
 
 ```bash
 mkdir -p /tmp/ixp/<project-name>/{docs,text,taxonomies,prompts}
-uip ixp projects get-metrics <project-name> --output json
+uip ixp projects get-metrics <project-name> --model-version latest --output json
 ```
 
+`--model-version latest` is deliberate: the baseline is the latest trained version — the model your instruction edits retrain — not the `live` tag (Critical Rule 21: the version follows the question).
+
 Note the `ModelVersion` from this baseline read — later iterations check that it advances after each `fields update-prompts` / `groups update-prompts` (see step 2e). If the value here looks identical to a known pre-labelling version, the retrain may still be in flight; re-fetch under the bounded wait in [Waiting for retrain](#waiting-for-retrain), then proceed with whatever it returns.
 
 Save the full per-field `Fields` array as `baseline_metrics`. This is the starting point you compare against. (For a validated model, get-metrics Data is flat — `Fields`/`FieldGroups`/`ValidatedDocuments` are top-level. An unvalidated model returns `Data: { Metrics: null }` instead — re-fetch under the bounded wait above.)

package/version-manifest.json

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