@uipath/skills 1.204.0 → 1.204.1

package/skills/uipath-maestro-flow/references/agent.md

@@ -1,175 +0,0 @@
-# Agent
-
-*Exact signatures, fields, and defaults: `agent()`.*
-
-Start a coded or low-code agent and wait for its output. The resource may be
-published in Orchestrator or registered as a sibling project in this solution.
-
-Signature: `agent({ key, name, folderPath?, location?, projectId?, inputs, returns?, flavour? })`
-
-```ts
-.step('count', 
-  agent({ 
-    key: 'BAADF00D-BAAD-F00D-BAAD-F00DBAADF00D',
-    name: 'CountLetters',
-    folderPath: 'Shared',
-    inputs: { inputString: input('inputString') },
-    returns: { count: 'integer' },
-    flavour: 'coded'
-  }))
-```
-
-See [Orchestrator Processes](or-processes.md) and use the `Agent` process type to locate an agent process and determine its contract.
-
-## General
-
-- *flavour* can be either "coded" or "lowcode". It does not affect the runtime contract, only presentation. There is no equivalent field returned from `uip or processes get`.
-
-`.onError(...)` is supported on agent steps.
-
-## Reuse a published agent, or create one in the solution
-
-Two shapes, and the request decides which.
-When the request names an agent that may already exist, look for it first.
-
-```bash
-uip maestro flow registry pull --force
-uip maestro flow registry search "uipath.core.agent" --output json
-uip maestro flow registry get "uipath.core.agent.<key>" --output json
-```
-
-`registry get` is also how you learn the agent's own argument names and its
-return shape — `inputDefinition.properties` and `outputDefinition`.
-
-When the request asks for a coded agent to be CREATED in this solution,
-scaffold it as a sibling project instead; do not substitute an inline low-code
-agent.
-Creating one the tenant already publishes is duplication, and binding a
-pre-existing one when the request said to build it is a different task — so
-read the request, do not guess from what the registry happens to hold.
-
-**Never invent `key` or `projectId`.**
-Both are minted by the tooling and read back from it.
-If no source below yields one, stop on that field rather than supply a
-plausible GUID: `check` and `validate` both accept a well-formed GUID that
-resolves to nothing on the tenant, so a fabricated key fails at run time, not
-at author time.
-
-## Task-created in-solution coded agent
-
-1. Scaffold the solution and Flow project.
-2. Scaffold and implement the coded agent as a sibling directory.
-3. Register the sibling with `uip solution projects add`.
-4. Read the two identifiers back, then author the Flow with `agent({
-   location: 'in-solution', ... })`.
-5. Compile into the nested Flow project, validate, refresh resources, and
-   debug the Flow.
-
-```bash
-uip solution init <SolutionName> --output json
-( cd <SolutionName> && uip maestro flow init <FlowName> --output json )
-
-mkdir -p <SolutionName>/<AgentProject>
-( cd <SolutionName>/<AgentProject> \
-  && uv venv --python 3.13 \
-  && uv pip install <framework-package> \
-  && uip codedagent setup --force --output json \
-  && uip codedagent new <AgentName> )
-```
-
-**Install the framework package BEFORE `new`.**
-`new` defaults to `--type auto`, which picks the template from whichever
-framework package is installed in the active venv — so with none installed it
-scaffolds a coded FUNCTION instead, and nothing says so at the time.
-
-Verify the scaffold before going further: a `<framework>.json` beside `main.py`
-(`langgraph.json` for `uipath-langchain`) means the agent template was used.
-A `uipath.json` carrying a `functions` map and no `<framework>.json` is the
-function fallback — install the package, delete the generated files, and re-run
-`new`.
-
-Scaffold from INSIDE the agent directory.
-Run `codedagent new` from the solution root and it writes `main.py`,
-`pyproject.toml` and `<framework>.json` into the solution root, which then has
-to be cleaned up by hand.
-
-Implement the project, then from that directory:
-
-```bash
-uv sync
-uip codedagent init
-uip codedagent review . --output json
-```
-
-`uv sync` comes before `init` because `uip codedagent init` imports the
-entry-point graph, so it fails on any declared dependency the venv does not
-have yet — and a failed `init` leaves `uipath.json` scaffolded but with its
-entry-point map never filled in.
-
-**`uip codedagent run` is not part of this path.**
-It executes the graph, which needs `UIPATH_ACCESS_TOKEN` and reach to the LLM
-gateway.
-Where either is absent it fails at the platform client, and the import and
-virtualenv errors it emits on the way there are environment, not defects in the
-project — do not chase them.
-`uip codedagent review` is the offline rung: it checks the project without
-running the model.
-
-Register the sibling, refresh, then read both identifiers back:
-
-```bash
-( cd <SolutionName> && \
-  uip solution projects add <AgentProject> <SolutionName>.uipx --output json )
-uip solution resources refresh --solution-folder <SolutionName> --output json
-uip maestro flow registry list --local --output json
-```
-
-`registry list --local`, run from the Flow project directory, is the
-authoritative source for the minted key.
-The generated resource file carries the same pair:
-
-- `resource.key` → `key`
-- `resource.projectKey` → `projectId`
-
-**Find that file; do not assume its path.**
-`uip solution projects add` reads the project type out of the manifest, and a
-`uipath.json` with no `ProjectType` falls back to `Function` whenever it
-carries a `functions` map — including an empty one, which a scaffolded project
-has. So the resource can land under `process/function/<AgentProject>.json`
-rather than `process/agent/`. Glob for it instead of hard-coding either:
-
-```bash
-ls <SolutionName>/resources/solution_folder/process/*/<AgentProject>.json
-```
-
-`uip solution projects list --output json` reports the type the manifest
-resolved to.
-`Type: Function` on a coded agent is that fallback, not a mistake in your
-wiring: re-adding the project or hand-editing `uipath.json` will not change it,
-so read the identifiers and wire the Flow rather than trying to correct it
-first.
-
-```ts
-.step('analyze', agent({
-  key: localResourceKey,
-  name: '<AgentProject>',
-  location: 'in-solution',
-  projectId: localProjectKey,
-  inputs: { sentence: input('sentence') },
-  returns: { result: 'integer' },
-  flavour: 'coded',
-}))
-```
-
-An in-solution agent intentionally has no `folderPath`. Its generated binding
-uses the bare local resource key, and its definition carries the sibling
-project id. The SDK checker rejects a missing project id or a published agent
-with a missing folder, so the two resource forms cannot silently collapse into
-one another.
-
-## Evidence boundary
-
-A green live run proves that a real job received inputs and returned the
-declared shape. It does not prove the model's answer is correct. Preserve the
-job identity, input/output witnesses, and a scenario-specific semantic
-assertion; offline seeds should also rule out a hard-coded answer.

package/skills/uipath-maestro-flow/references/agentic-process.md

@@ -1,41 +0,0 @@
-# Agentic Process
-
-*Exact signatures, fields, and defaults: `agenticProcess()`.*
-
-Invoke a deployed Maestro agentic process.
-
-Signature: `agenticProcess({ key, name, folderPath, inputs?, returns? })`
-
-```ts
-.step('intake',
-  agenticProcess({
-    key: 'BAADF00D-BAAD-F00D-BAAD-F00DBAADF00D',
-    name: 'ProcurementProcess',
-    folderPath: 'Shared',
-    inputs: { productId: 1 },
-    returns: { status: 'boolean' }
-  }))
-```
-
-See [Orchestrator Processes](or-processes.md) and use the `ProcessOrchestration`, `CaseManagement`, and/or `Flow` process types to locate an agentic process and determine its contract.
-
-## General
-
-- Declared outputs can be returned as `null`
-
-## Forms and fire-and-forget completion
-
-One `agenticProcess()` covers all three published forms; `form` selects the
-wire identity: `'bpmn'` (default — Maestro BPMN process orchestration),
-`'flow'` (published Maestro Flow), `'case'` (Case Management process).
-
-`completion: 'fire-and-forget'` dispatches the process and continues
-immediately: `returns` is forbidden, the step publishes no output (reading
-`$vars.<step>.output` is a check error), and only dispatch failures route
-through `.onError(...)`. Local replay treats it as dispatch-only.
-
-```ts
-.step('launchReview', agenticProcess({ key: reviewKey, name: 'ClaimsReview',
-  folderPath: 'Shared', form: 'flow', completion: 'fire-and-forget',
-  inputs: { claimId: input('claimId') } }))
-```

package/skills/uipath-maestro-flow/references/api-workflow.md

@@ -1,29 +0,0 @@
-# API Workflow
-
-*Exact signatures, fields, and defaults: `apiWorkflow()`.*
-
-Run a deployed coded API workflow as a serverless Orchestrator job.
-
-Signature: `apiWorkflow({ key, name, folderPath, inputs?, returns? })`.
-
-```ts
-.step('age', apiWorkflow({ key: workflowKey,
-  name: 'NameToAge', folderPath: 'Shared',
-  inputs: { name: input('name') }, returns: { age: 'integer' } }))
-```
-
-## Tenant contract
-
-The workflow key, name, and folder must describe one deployed resource. Confirm
-its actual input/output names and casing from the tenant. See
-[Orchestrator Processes](or-processes.md) and use the `Api` process type for the
-shared, pagination-safe resource-discovery procedure.
-
-`.onError(...)` is supported on API workflow steps. Choose a handler only when
-the scenario wants recovery; otherwise a faulted job may need to fault the Flow.
-
-## Evidence boundary
-
-Replay uses the authored contract. Live evidence should identify the real job,
-its input arguments, completion status, and returned output. Job completion does
-not by itself prove the coded workflow's business result is correct.

package/skills/uipath-maestro-flow/references/author.md

@@ -1,178 +0,0 @@
-# Author — build and edit a flow with the builder SDK
-
-Everything that happens on disk before a flow touches the cloud: scaffold the
-project, choose each node, write `<Name>.flow.ts`, and run the loop in
-[`CLI-LOOP.md`](CLI-LOOP.md) until the emitted `.flow` validates. Authoring ends
-at a valid artifact; publishing, running and debugging are
-[`operate.md`](operate.md), and a failed run is [`diagnose.md`](diagnose.md).
-
-The builder owns the `.flow` JSON. `compile` emits every node definition, the
-`variables.nodes[]` entries that make `$vars.<step>.output` resolve, the
-resource bindings, the connector `inputs.detail`, and the error flags, so none
-of that is hand-authored here. What stays with you is judgment the compiler
-cannot make: which node, which topology, what an output means, and what to ask.
-
-## Critical rules
-
-1. **Choose the node before writing it, from a search, never from a brand
-   name.** For an external service run `uip maestro registry search
-   '<service>'` and prefer, in order: a curated connector, managed HTTP in
-   connector mode, manual HTTP for an API with no connector, and an RPA
-   workflow only when there is no API at all (a desktop app, a terminal). For a
-   tenant resource (agent, process, API workflow, IxP model) run the family's
-   `uip maestro flow registry search`; it only returns published resources, so
-   `uip maestro flow registry pull --force` first, and check the solution's own
-   projects with `uip maestro flow registry list --local` before concluding a
-   resource is missing. `mock()` marks a capability both searches proved
-   absent; it is never a stand-in for one they found.
-2. **Read the node's reference before writing the step.** The router table in
-   [SKILL.md](../SKILL.md#supported-node-types) names one reference and one
-   example per node. Copy identity fields (keys, model names, folder keys)
-   from the tenant; never construct them.
-3. **Read the Integration Service contract before any `uip is` call.** Both
-   live in [/uipath:uipath-platform](/uipath:uipath-platform), under
-   `references/integration-service/`. `connections.md` covers selection,
-   folder scoping, BYOA filtering and empty-result recovery; if no healthy
-   connection exists after its recovery flow, stop and report it as an open
-   question. `resources.md` covers reference-field lookups; finish its
-   pagination loop before reporting "not found".
-4. **Edit the source, not the artifact.** Change `<Name>.flow.ts` and re-emit
-   with `compile -o`. Never hand-edit the emitted `.flow`, `content/*.bpmn`,
-   `bindings_v2.json`, `entry-points.json`, `operate.json` or
-   `package-descriptor.json` — the CLI regenerates them, and the next compile
-   silently undoes a hand edit. Brownfield JSON goes through `decompile`
-   ([`brownfield.md`](brownfield.md)).
-5. **Run the loop once the source is complete.** `check --source` is cheap, so
-   use it freely while writing; `compile` and `validate` run on the finished
-   source, and again after the last edit. Treat every `validate` warning as a
-   failure unless the loop reference names it as reviewed.
-6. **Bind every declared output on every path.** Each `.return({...})` must
-   name every key in `.output({...})`. `check` does not catch a missing one:
-   `compile` binds it to `$vars.<name>`, `validate` only warns
-   (`EXPRESSION_DIAGNOSTIC`), and the run returns `undefined` for it.
-7. **Handle an error only when the request says what should happen.** Add
-   `.onError(...)` only for a stated failure ("if the call fails…", "return X
-   for invalid input", "handle timeouts"); an unhandled failure must fault the
-   run. A handler either genuinely recovers or reaches a terminal the caller
-   can tell apart from success — a distinct `.return`, or `.terminate`.
-8. **Never invent the business meaning of a named output — ask.** When a
-   request names an output (`caseKey`, `severity`, `ticketId`) without saying
-   how to derive it, whether it passes through or is reformatted is the
-   user's rule. Ask, or state the assumption and confirm it. A guessed format
-   compiles and validates and returns the wrong value.
-9. **Present a finite decision as a list of options, with "Something else"
-   last.** Which solution, which connector, which trigger, which resource to
-   bind: ask with the enumerated choices, never as an open question. Without a
-   structured-question tool, ask in chat as a numbered list. With nobody to ask
-   (CI, headless), take the recommended option and record it prominently in
-   the final report; if none is recommended, stop and report the open
-   decision. Consent gates — destructive operations, tenant writes — are never
-   auto-answered.
-10. **Look for an existing solution before `uip solution init`.** Run
-    `find . -maxdepth 2 -name '*.uipx'`. If one exists, ask which to use (one
-    option per solution, "Create a new solution", then "Something else"); do
-    not silently adopt, re-initialize, or repair it. The scaffold itself is in
-    [SKILL.md](../SKILL.md#project-layout).
-11. **Never invoke another skill on your own.** When the flow needs an RPA
-    process, an agent, or an app that does not exist, name the gap and hand
-    the user what they need to switch skills.
-12. **Batch independent calls; chain dependent ones.** Scaffold, install and
-    the registry search go in one turn; `check`, each `prepare` it names, the
-    re-`check`, `compile` and `validate` chain in the next. Split only where a
-    later step needs an earlier step's output.
-
-## Journeys
-
-| Journey | Read |
-| --- | --- |
-| Create a new flow | [SKILL.md — Project layout](../SKILL.md#project-layout), then [`CLI-LOOP.md`](CLI-LOOP.md) |
-| Edit an existing flow (`.flow.ts` or raw `.flow`) | [`brownfield.md`](brownfield.md) |
-| Add or change one node | the node's row in [SKILL.md — Supported node types](../SKILL.md#supported-node-types) |
-| Connector with tenant-specific fields | [`connector-params.md`](connector-params.md) + [`bindings.md`](bindings.md) |
-
-### Count what the request names before building
-
-Count the steps the request names: services, systems, documents, decisions,
-approvals, schedules, computations. A domain or an outcome ("shipment
-tracking", "our onboarding") is not a step, and neither is the project name.
-
-- **Zero steps: scaffold only.** Scaffold the project, compile the stub, and
-  validate. Do not invent a pipeline from the domain word. Report what the flow
-  should do as open questions; that is the finished deliverable.
-- **One or more steps: build all of them.** An outcome next to a step does not
-  cancel the step. "Check the weather for the Bellevue office and tell me if
-  it's a nice day" names a lookup and a threshold decision; build both.
-
-### Plan first only when the flow is complex
-
-Plan before building when the flow has five or more nodes with branching or
-parallel paths, needs connector or resource discovery, or the requirements are
-ambiguous. Build directly for a single-node edit, a linear pipeline, or a
-topology the user already spelled out.
-
-Skipping the plan never skips the node choice. Two outcomes ("if … otherwise
-…") are a `.branch`, never a script ternary; three or more are a `.switch`; a
-named external service goes through rule 1.
-
-A plan states: a one-line summary, the node table (step name, node, why), the
-wiring, the inputs and outputs, every connector and its connection, and open
-questions. Get it approved before building (rule 9, with "proceed"
-recommended).
-
-**Is Maestro the right home?** A flow earns its place with several waits,
-branching or parallel paths, SLAs, cross-product composition, or per-case
-visibility. A single-wait, mostly linear process may be simpler as a queue plus
-Action Center; say so before designing topology.
-
-## Anti-patterns
-
-- **Never replace a registered connector with `mock()` or a script because it
-  cannot be configured yet.** Write the `connector(...)` step, run the
-  `prepare` that `check` names, and if there is no live connection, report
-  "prepare pending" as an open question. Reviewers and Studio Web need the real
-  connector in the artifact.
-- **Never reuse a reference id from another flow or session** — a mailbox
-  folder, a Slack channel, a Jira project. Ids are scoped to the account behind
-  the connection: a reused one compiles, validates, and faults at run time.
-  Resolve it again with a `lookup()` token and the `prepare` that `check`
-  names.
-- **Never write a reference field you could not resolve.** If the lookup fails
-  (401/403 on an expired grant, 5xx), you have no id: do not substitute the
-  display name, an alias, or a remembered value. Stop and report the failed
-  resolve.
-- **Never reference a parent's values inside a subflow.** A child flow has its
-  own scope; pass values through the `subflow(child, {...})` inputs and read
-  them with `input(...)`. `check` does not flag a child script that reads
-  `$vars.start.output.*` from the parent — it compiles and resolves to nothing.
-- **Never use `console.log` in a script.** The script runtime has no
-  `console`, and `check` does not flag it. Return the value to inspect:
-  `return { debug: value }`.
-- **Never treat a green `validate` as proof of business correctness.** It
-  checks structure. Named outputs, reference ids and connector field values
-  are only proven by the evidence in [`CLI-LOOP.md`](CLI-LOOP.md#bounded-completion).
-
-## Completion output
-
-When authoring is done, report:
-
-1. **File paths** — the `.flow.ts` source and the emitted `.flow`.
-2. **What was built** — steps, branches and outputs, in a sentence or two.
-3. **Loop status** — the last `check`, `compile` and `validate` results,
-   including any warning you judged acceptable and why.
-4. **Placeholders** — each `mock()` and the capability it stands for.
-5. **Missing connections or pending prepares** — per connector.
-6. **Open questions** — every decision the request left open, each marked
-   **[REQUIRED]** or **[OPTIONAL]**.
-7. **What's next** — when the request did not already say, ask with rule 9:
-   upload to Studio Web, debug the flow, deploy to Orchestrator, or "Something
-   else". Each hands off to [`operate.md`](operate.md). A request that already
-   named the next step ("publish it", "debug it") is the selection; act on it.
-
-## Narration and progress
-
-Silent by default: surface decisions, failures, consent gates and the final
-result. Narrate each logical step in one plain-English line, and keep a
-step-level progress list, only when the user asks for it (verbose, show steps,
-track progress) or has a standing preference for it. A logical step is the
-smallest outcome the user cares about — "added the Slack step", not the three
-commands behind it.

package/skills/uipath-maestro-flow/references/batch-transform.md

@@ -1,23 +0,0 @@
-# Batch Transform
-
-*Exact signatures, fields, and defaults: `batchTransform()`.*
-
-Adds AI-generated columns to a CSV and returns a new file attachment.
-
-Signature: `batchTransform({ attachment, prompt, outputColumns, enableWebSearchGrounding? })`
-
-```ts
- .step('categorizeRows',
-   batchTransform({
-     attachment: out('start', 'csvFile'),
-     prompt: 'Classify each row by category and write a one-line summary.',
-     outputColumns: [
-       { name: 'Category', description: 'One of: Utility, Software, Travel, Other' },
-       { name: 'Summary',  description: 'Plain-English one-line summary of the row' },
-     ],
-   }))
-```
-
-## General
-
-- Error **460005** can be transient; retry it once before classifying the failure

package/skills/uipath-maestro-flow/references/bindings.md

@@ -1,178 +0,0 @@
-# Symbolic connector bindings
-
-`bindings.json` maps the short connection and folder names in authored
-TypeScript to tenant resource keys. It lives in the SDK's work directory,
-`.flow-sdk/`, beside the `<Name>.flow.ts` file.
-
-## Project layout
-
-```text
-.flow-sdk/
-  <Name>.flow.ts
-  bindings.json
-  connectors/
-    <connector-key>.ts
-  connectors-local/
-    <connector-key>.ts
-    descriptors/
-      <connector-key>/
-        index.json
-        ...generated descriptor data...
-```
-
-`uip maestro registry prepare` writes `.flow-sdk/bindings.json` and prints the
-import for `./connectors-local/<connector-key>.ts`, relative to the source.
-The generated descriptor data lives below `connectors-local/descriptors/`; do
-not import it directly. `bindings.json` is independent of that descriptor
-overlay. Studio Web reads none of these files, and `uip solution pack`/`upload`
-leave `.flow-sdk/` out.
-
-## Schema
-
-Use `schemaVersion: "1"` and a `bindings` array. Version `1` is the current
-authored-file format marker. The current loader does not branch on this value,
-but including it keeps the file explicit and compatible with shipped examples.
-
-Each connector entry should carry the complete shape below. Resolution needs a
-matching `name` or `id` and a `resourceKey` or `default`; the other fields keep
-the resource kind and emitted binding purpose explicit.
-
-| Field | Required for resolution | Meaning |
-|---|:---:|---|
-| `id` | one of `id` / `name` | Stable binding identifier; may be used as the symbolic source name. |
-| `name` | one of `id` / `name` | Symbolic name normally passed to `connection` or `folder`. |
-| `resource` | no | `"Connection"` for Integration Service connection and folder entries. |
-| `resourceKey` | one of `resourceKey` / `default` | Tenant connection id or folder key. This value wins when both value fields exist. |
-| `default` | one of `resourceKey` / `default` | Fallback when `resourceKey` is absent. Shipped examples repeat the resource key here. |
-| `propertyAttribute` | no | `"ConnectionId"` for a connection or `"FolderKey"` for a folder. |
-
-## Where both values come from
-
-**Usually you do not fill these in at all.**
-`uip maestro registry prepare <connector-key> <action>` discovers the connection and writes both entries into `bindings.json` for you — see [connector-params.md](connector-params.md#resolving-connection-scoped-reference-values).
-Reach for the manual route below only when you are authoring bindings without
-running `prepare`.
-
-If you are doing it by hand: `uip is connections list --all-folders` returns the
-connection id **and its folder key** on the same record, so one call answers both.
-Always pass `--all-folders`: the default listing is your own folder only, and a
-connection shared from another folder (the usual case on a team tenant) is
-invisible without it — an empty or unrelated default listing is not evidence
-that the connection does not exist.
-
-```bash
-uip is connections list --all-folders --output json
-```
-
-```text
-{
-  "Name": "dustin.metzgar",
-  "Id": "c03a1967-f702-47d2-9ede-917aed159805",
-  "Folder": "dustin.metzgar@uipath.com's workspace",
-  "FolderKey": "b53217ce-25b2-46cd-a6b0-b73c6ba5894c",
-  "ConnectorKey": "uipath-salesforce-slack",
-  "State": "Enabled"
-}
-```
-
-`Id` is the connection binding's `resourceKey`; **`FolderKey` is the folder
-binding's**. Never fill either with a made-up GUID or with the binding's own
-name. `compile` refuses two shapes, and `check` reports both first: a binding
-whose `resourceKey` is its own name (`BINDING_SELF_NAME`), and a `connection:` /
-`folder:` label that a `bindings.json` with entries does not declare
-(`BINDING_UNDECLARED` — for example the source says `is-sandboxes` while the file
-declares `slack` and `shared`). It warns `CONNECTION_STUB` on an all-zero GUID,
-an `<angle-bracket>` placeholder or any other non-GUID value, and on a label when
-no `bindings.json` is loaded or it declares no entries (the run would fault at
-dispatch — `'Connection' has an invalid GUID value` or a `401 Invalid
-Organization or User secret`). A plausible-looking but wrong GUID still compiles
-and faults at run time. Only an id read from the tenant is right.
-
-Several connections often share one name (a team tenant can hold three Slack
-connections all named `is-sandboxes`, in different folders). A name then cannot
-pick one: `prepare … --connection <name>` lists each candidate with its
-`--connection-id <id>` and folder — pass the id of the one in the folder you mean,
-and `prepare` still writes both entries into `bindings.json`.
-
-**Do not go looking in Orchestrator for the folder.** `uip or folders list` is a
-different resource with different keys, and a folder binding wants the one the
-CONNECTION lives in — which you already have. Measured on the eval corpus: an
-agent that had already listed the connection went on to spend three to four
-further calls on `uip or --help`, `uip or folders --help` and `folders list`,
-searching for a folder matching the symbolic name in its prompt. The symbolic
-name (`slack`, `shared`) is just the label you pass to `connector()`; it is never
-something to search the tenant for.
-
-Copy this two-connector, one-folder example and replace all three placeholders
-with values from the connection listing above:
-
-```json
-{
-  "schemaVersion": "1",
-  "bindings": [
-    {
-      "id": "slack",
-      "name": "slack",
-      "resource": "Connection",
-      "resourceKey": "<slack-connection-id>",
-      "default": "<slack-connection-id>",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "jira",
-      "name": "jira",
-      "resource": "Connection",
-      "resourceKey": "<jira-connection-id>",
-      "default": "<jira-connection-id>",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "shared",
-      "name": "shared",
-      "resource": "Connection",
-      "resourceKey": "<folder-key>",
-      "default": "<folder-key>",
-      "propertyAttribute": "FolderKey"
-    }
-  ]
-}
-```
-
-Use unique `id` and `name` values. The resolver takes the first entry whose
-`name` or `id` matches the authored symbol.
-
-## Resolution and precedence
-
-The compile commands load `--bindings <file>` when supplied. Otherwise they
-load `.flow-sdk/bindings.json` under the current directory when it exists. A
-workspace laid out before `.flow-sdk/` existed, with only a root-level
-`./bindings.json`, keeps using that file; when both exist the `.flow-sdk/` one
-wins and stderr names the ignored root file. `emitFlow()` uses the same
-default unless `bindingsFile` or a `Bindings` instance is supplied.
-
-```ts
-.step('notify', connector(SendMessage, {
-  channel: 'C123',
-  text: 'Ready',
-}, { connection: 'slack', folder: 'shared' }))
-```
-
-During emission, `connection: 'slack'` matches the entry whose `name` or `id`
-is `slack`; `folder: 'shared'` is resolved the same way. For each match,
-`resourceKey` wins over `default`. An unmatched symbol is emitted unchanged, so
-do not treat a successful compile as proof that an invented id exists.
-
-Only compile/emission reads the authored file. `uip maestro flow validate`,
-solution resource refresh, and product debug read the emitted `.flow`, not
-`.flow-sdk/bindings.json`. A compile regenerates the artifact from the authored
-mapping. A later direct edit to the artifact remains in effect only until the
-next compile.
-
-## Emitted-artifact bindings
-
-`uip maestro flow binding add` edits bindings inside an already emitted `.flow`;
-it does not create or update `.flow-sdk/bindings.json`. SDK-authored Integration
-Service actions and managed HTTP nodes should instead keep symbolic names in
-source plus `bindings.json`, so recompilation deterministically restores the
-same node detail and product bindings. Use direct artifact edits only for a
-brownfield `.flow` with no source representation.

package/skills/uipath-maestro-flow/references/branch.md

@@ -1,18 +0,0 @@
-# Branch
-
-Branch makes a two-way runtime decision.
-
-Signature: `.branch(name, condition, thenFn, elseFn?)`. Each callback receives a
-sub-builder and may use `.label(text)` for its edge label.
-
-```ts
-.branch('large', js`${input('amount')} > 1000`,
-  (yes) => yes.step('review', script({ code: 'return "review";' })),
-  (no) => no.step('approve', script({ code: 'return "approved";' })))
-```
-
-Use Branch when the scenario has two paths. Whether each arm should end locally
-or fall through to shared work is a business-flow choice.
-
-The two sequence ports are `true` and `false`. Arm `.label(text)` values become
-`trueLabel` and `falseLabel`, defaulting to `True` and `False`.