@uipath/skills 1.196.0 → 1.197.0

package/skills/uipath-maestro-bpmn/references/author/references/plugins/integration-service/impl.md

@@ -1,134 +0,0 @@
-# Integration Service Implementation
-
-This document defines the implementation boundary for Integration Service BPMN elements.
-
-This boundary covers connector-backed and dynamically schematized Integration
-Service work. For confirmed pass-2 plain connectionless HTTP where the workflow
-owns the URL, method, payload, and parsing, use
-[task-recipes/http-request.md](../../task-recipes/http-request.md).
-
-## Model-owned implementation
-
-The model may edit:
-
-- Standard BPMN wrapper element: service task, start event, intermediate event, boundary event, or receive/wait pattern.
-- Stable element ID and public-safe display name.
-- Sequence flows and diagram geometry.
-- Variables and mappings that consume the eventual output.
-- Error handling and retry intent, when specified by the user.
-
-The model must keep any connector-backed Integration Service service payload as
-draft intent unless CLI enrichment has supplied the concrete metadata. A draft
-shell may identify the wrapper family with `uipath:type value="Intsvc.<Variant>"`
-and placeholder strings, but it must not include real connector metadata,
-connection bindings, generated schemas, or generated resource references.
-
-Sanitized fixtures may be used to understand where enriched XML and generated package files appear, but their connector keys, resource keys, operation names, schemas, and bindings must not be copied into a live project.
-
-## CLI-owned implementation
-
-The CLI or registry-backed tool must generate or enrich from current tenant/registry data:
-
-- `uipath:activity` or `uipath:event` contents for connector-backed or dynamically schematized `Intsvc.*` service types.
-- `uipath:type` service type and version from supported metadata.
-- `uipath:context` fields for connector key, operation, object, connection binding, event name, folder fields, and trigger properties.
-- `uipath:input` bodies for request parameters and filter expressions.
-- `uipath:output` mappings and dynamic output schemas.
-- `uipath:inputSchema` payloads.
-- Root `uipath:bindings` entries that point to generated binding resources.
-- `bindings_v2.json` resource entries.
-
-## Safe placeholder shape
-
-When enrichment is unavailable, keep the BPMN element structurally visible and
-mark it as draft in planning notes rather than inventing executable connector
-metadata. The project should remain in Author state until enrichment completes.
-
-The draft shell uses the same canonical wrapper shape as other BPMN wrappers:
-`bpmn:extensionElements`, `uipath:activity` or `uipath:event`, and a nested
-`uipath:type`. Any placeholder payload mapping belongs in sibling
-`uipath:mapping`, but executable connector metadata remains CLI-owned. See
-[shared/wrapper-shells.md](../../../../shared/wrapper-shells.md) for copyable
-generic examples.
-
-Minimal draft `Intsvc.ActivityExecution` shell on a `bpmn:sendTask`:
-
-```xml
-<bpmn:sendTask id="Task_ConnectorActivity" name="Connector Activity">
-  <bpmn:extensionElements>
-    <uipath:activity version="v1">
-      <uipath:type value="Intsvc.ActivityExecution" version="v1" />
-      <uipath:context>
-        <uipath:input name="connectorKey" type="string" value="placeholder-connector" />
-        <uipath:input name="activity" type="string" value="placeholder-operation" />
-      </uipath:context>
-      <uipath:input name="Body" type="json" target="bodyField"><![CDATA[{"value":"=vars.Var_RequestId"}]]></uipath:input>
-    </uipath:activity>
-  </bpmn:extensionElements>
-  <bpmn:incoming>Flow_To_ConnectorActivity</bpmn:incoming>
-  <bpmn:outgoing>Flow_ConnectorActivity_Out</bpmn:outgoing>
-</bpmn:sendTask>
-```
-
-Minimal draft `Intsvc.WaitForEvent` shell on a `bpmn:receiveTask`:
-
-```xml
-<bpmn:receiveTask id="Task_WaitForExternalEvent" name="Wait For External Event">
-  <bpmn:extensionElements>
-    <uipath:event version="v1">
-      <uipath:type value="Intsvc.WaitForEvent" version="v1" />
-      <uipath:context>
-        <uipath:input name="connectorKey" type="string" value="placeholder-connector" />
-        <uipath:input name="eventName" type="string" value="placeholder-event" />
-      </uipath:context>
-    </uipath:event>
-  </bpmn:extensionElements>
-  <bpmn:incoming>Flow_To_WaitEvent</bpmn:incoming>
-  <bpmn:outgoing>Flow_WaitEvent_Out</bpmn:outgoing>
-  <bpmn:messageEventDefinition id="MessageDef_ExternalSignal" messageRef="Message_ExternalSignal" />
-</bpmn:receiveTask>
-```
-
-These shells are not executable. The CLI still owns the real connector key,
-operation/event name, connection binding, trigger properties, input and output
-schemas, generated outputs, and `bindings_v2.json` resources.
-
-Use synthetic names only, for example `Task_CreateTicket` or
-`Start_WhenRecordCreated`. Do not use real connection IDs, tenant URLs, folder
-keys, account-specific resource IDs, or copied metadata from another project.
-Do not hand-author `connection`, `trigger`, or `object` `type="resource"`
-inputs that point at `=bindings.<id>`; those expressions require generated
-`bindings_v2.json` resources and are CLI-owned.
-
-## Draft handoff notes
-
-Until CLI enrichment runs, record an explicit handoff in the project so the
-operator and the CLI know which fields are still placeholders. Prefer the
-handoff summary or an existing project-owned documentation location. Do not
-create a new `README.md`, `notes.md`, or other project file solely for draft
-blockers unless the user asks for that artifact.
-
-The handoff should make each unresolved CLI-owned blocker explicit:
-
-1. **`connector metadata`** - the CLI fills in operation/event metadata, version, and connector key.
-2. **`connection binding`** - the CLI generates the root `uipath:bindings` connection entry and the `=bindings.<id>` references on the node.
-3. **`dynamic schemas`** - the CLI generates the `uipath:inputSchema` payloads and generated output schemas.
-4. **`bindings_v2.json`** - the CLI generates binding resources, deduplicated by resource key.
-5. **`entry-points.json`** - the CLI generates trigger entry-point wiring and root variable schema.
-6. **`operate.json`** - the CLI generates project ID, main file, target framework, and runtime options.
-7. **`package-descriptor.json`** - the CLI generates manifest entries for the BPMN file and generated JSON.
-8. **`package metadata`** - the CLI produces final package identifiers, paths, and generated outputs.
-
-## Validation expectations
-
-Before Operate, confirm that:
-
-- Every executable connector-backed Integration Service element has CLI-enriched context, inputs, outputs, and schemas.
-- Root binding references resolve.
-- Generated package resources exist and are deduped.
-- Required filters and parameters are present.
-- Trigger property bindings are generated for trigger elements.
-- No private IDs are present in files intended for commit.
-- Enrichment evidence comes from the current target tenant/registry, not from copied exports or synthetic fixtures.
-
-Use [shared/local-metadata-regeneration-guide.md](../../../../shared/local-metadata-regeneration-guide.md) to verify the generated `bindings_v2.json`, `entry-points.json`, and `Intsvc.*` payloads agree before upload, debug, publish, or deploy.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/integration-service/planning.md

@@ -1,67 +0,0 @@
-# Integration Service Planning
-
-Integration Service activities and triggers are CLI-owned or CLI-enriched. The model may plan the node and surrounding BPMN structure, but it must not invent connector metadata, connection identifiers, dynamic schemas, or binding resources.
-
-## When to use
-
-Use this plugin reference when a BPMN process needs:
-
-- A connector activity.
-- A connector trigger.
-- A wait-for-event shape backed by Integration Service.
-- Unified HTTP or connector-authenticated HTTP behavior.
-- Dynamic input/output schemas from connector metadata.
-
-For plain connectionless HTTP calls where the workflow owns the URL, method,
-payload, and parsing, record the intent during pass 1 and read
-[task-recipes/http-request.md](../../task-recipes/http-request.md) after the
-skeleton is chosen, before deciding whether the node is executable or only
-draft intent.
-
-## Planning steps
-
-1. Identify the connector, operation/event, object, and user-visible intent.
-2. Determine whether the element is a trigger, wait event, connector activity, connector-authenticated HTTP call, or plain connectionless HTTP call.
-3. Check whether the process can proceed with a draft placeholder or must stop until enrichment is available.
-4. Record required user decisions: connector, connection, folder/resource scope, operation, filters, required parameters, and output variables.
-5. Keep the surrounding BPMN structure model-authored: start/event/task placement, sequence flows, gateways, error handling, and diagrams.
-6. Hand the Integration Service element to CLI enrichment before validation for upload/debug/publish.
-
-## Live enrichment expectation
-
-Executable Integration Service nodes require live registry-backed enrichment for the target tenant. Static examples and sanitized fixtures demonstrate shape only; they are not reusable connector metadata.
-
-- Use current CLI/registry data for connector keys, operation/event names, object metadata, connection availability, trigger properties, filters, parameter schemas, and generated output schemas.
-- Treat stale exported metadata, copied tenant identifiers, or fixture values as non-authoritative.
-- If live enrichment is unavailable, keep the node as draft intent and stop before Operate. A draft may include a canonical `uipath:type value="Intsvc.<Variant>"` shell with placeholder strings, but not real connector metadata, connection bindings, dynamic schemas, or generated resource references.
-
-## Model may draft
-
-- A placeholder service task, start event, or intermediate event with a stable element ID.
-- A draft `uipath:activity` or `uipath:event` shell carrying `uipath:type value="Intsvc.<Variant>"` and placeholder string `uipath:input` values. See [impl.md](impl.md#safe-placeholder-shape) and [../../../../shared/wrapper-shells.md](../../../../shared/wrapper-shells.md).
-- Public-safe display naming.
-- Surrounding sequence flows, gateways, boundary errors, and variable mappings.
-- A `README.md` (or `notes.md`) inside the project that lists the
-  CLI-owned blockers verbatim. The list must contain at minimum these
-  exact phrases: `connection binding`, `dynamic schemas`,
-  `bindings_v2.json`, and `package metadata`. See
-  [impl.md](impl.md#draft-handoff-notes) for the full template.
-
-## CLI must provide
-
-- Connector key and operation/event metadata.
-- Connection binding and resource metadata.
-- Context fields such as object name, activity, operation, filter expression, and trigger properties.
-- Dynamic schemas and generated output metadata.
-- `bindings_v2.json` entries and resource metadata.
-- Validation that the selected connection and operation are available.
-
-## Stop conditions
-
-Stop before real run/upload if:
-
-- No selected connection exists.
-- The connector operation is unknown.
-- Required parameters are not resolved.
-- Generated schemas are missing for an executable element.
-- The element contains pasted private connection or tenant identifiers.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/multi-instance/impl.md

@@ -1,50 +0,0 @@
-# Multi-Instance Implementation
-
-This document defines the implementation boundary for multi-instance activities.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:multiInstanceLoopCharacteristics`.
-- Sequential or parallel marker attributes.
-- `uipath:loopCharacteristics` extension metadata.
-- Input collection, item variable, and output mappings.
-- Boundary error paths and completion-condition expressions.
-
-## Implementation rules
-
-- Declare the collection variable before referencing it. Do not invent a bare
-  item variable for subprocess bodies; use the iterator shape documented below.
-- Use sequential execution when item order or resource limits matter.
-- Keep per-item outputs distinct from aggregate outputs.
-- Do not hide service-call retries inside loop metadata; model retry or boundary behavior explicitly.
-- Choose the item binding pattern from the BPMN shape:
-  - For a task with its own multi-instance marker, pass `iterator` into the task mapping and read the current item from `iterator.item`.
-  - For a multi-instance subprocess, bind the subprocess loop element as `inputElement="iterator[0]"` and pass the current item to body activities with `=iterator[0].item`.
-- Do not assume a bare item alias such as `=currentItem` is in scope inside a marker subprocess body unless the file already uses that alias successfully or a current runtime fixture confirms it.
-
-## Generic marker subprocess pattern
-
-Use this pattern when a subprocess body runs once per item and inner activities need the current item:
-
-```xml
-<bpmn:multiInstanceLoopCharacteristics id="Loop_ProcessItems" isSequential="true">
-  <bpmn:extensionElements>
-    <uipath:loopCharacteristics inputCollection="=vars.Var_Items" inputElement="iterator[0]" version="v1" />
-  </bpmn:extensionElements>
-</bpmn:multiInstanceLoopCharacteristics>
-
-<!-- Inside the subprocess body -->
-<uipath:input name="args" type="json" target="bodyField"><![CDATA[
-{"item":"=iterator[0].item","vars":"=vars"}
-]]></uipath:input>
-```
-
-## Validation expectations
-
-- Input collection exists and is iterable.
-- Item variable is scoped and referenced consistently.
-- Completion conditions use readable variables and no assignments.
-- Output aggregation target exists.
-- Parallel execution does not conflict with known resource constraints.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/multi-instance/planning.md

@@ -1,29 +0,0 @@
-# Multi-Instance Planning
-
-Use this reference when planning repeated execution over a collection.
-
-## When to use
-
-- Running an activity once per item.
-- Parallel or sequential collection processing.
-- Aggregating per-item outputs.
-- Combining multi-instance with subprocess, service task, HITL, RPA, agent, or API workflow calls.
-
-## Planning steps
-
-1. Identify input collection, item variable, output collection, and completion condition.
-2. Choose sequential or parallel execution based on side effects and ordering.
-3. Decide how errors should affect the batch.
-4. Plan aggregation and downstream gateway behavior.
-5. Add UiPath loop metadata only after variables are declared.
-6. Avoid parallel fan-out when called resources have rate limits or side effects that require ordering.
-
-## Model may draft
-
-- Standard BPMN loop characteristics.
-- `uipath:loopCharacteristics` with input collection and input element metadata.
-- Variables, mappings, boundary errors, and diagrams.
-
-## Stop conditions
-
-Stop when collection shape, item variable, ordering, aggregation, or failure behavior is not defined.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/queues/impl.md

@@ -1,29 +0,0 @@
-# Queue Implementation
-
-This document defines the implementation boundary for queue task recipes. See [task-recipes/queue.md](../../task-recipes/queue.md).
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:sendTask` wrapper for `Orchestrator.CreateQueueItem`.
-- `bpmn:serviceTask` wrapper for `Orchestrator.CreateAndWaitForQueueItem`.
-- Documented queue `uipath:activity` shell.
-- Input CDATA for item payload, reference, priority, deadline, and transaction data.
-- Output mappings for queue item ID, status, or correlation fields.
-- Boundary error handling.
-
-## CLI or operator-owned implementation
-
-The CLI or operator must resolve:
-
-- Real queue binding, folder scope, and generated package resources.
-- Tenant-specific queue names, IDs, or folder keys.
-- Queue schema or downstream callback contracts when required.
-
-## Validation expectations
-
-- Queue binding expression resolves.
-- Payload fields come from declared variables through `vars.<variableId>` or literals.
-- Outputs map to declared writable variables.
-- Duplicate reference and unavailable-resource paths are modeled when required.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/queues/planning.md

@@ -1,29 +0,0 @@
-# Queue Planning
-
-Use this reference when planning Orchestrator queue interactions from BPMN. Queue create is `bpmn:sendTask`; create-and-wait queue work is `bpmn:serviceTask`. See [task-recipes/queue.md](../../task-recipes/queue.md).
-
-## When to use
-
-- Creating queue items.
-- Routing based on queue submission results.
-- Adding transaction metadata or references.
-- Using queue work as a handoff to another automation.
-
-## Planning steps
-
-1. Identify queue operation and whether BPMN only creates an item or also waits for downstream completion.
-2. Define item payload, reference, priority, deadline, and result variables.
-3. Plan queue resource binding with placeholders unless a public-safe binding is provided.
-4. Add error handling for duplicate references, validation failures, and unavailable queues.
-5. Keep downstream processing outside BPMN unless explicitly modeled as a wait or callback.
-
-## Model may draft
-
-- `bpmn:sendTask` with documented `Orchestrator.CreateQueueItem` shell, or `bpmn:serviceTask` with `Orchestrator.CreateAndWaitForQueueItem`.
-- Queue payload CDATA with synthetic fields.
-- Output mappings and error paths.
-- Placeholder-safe binding references.
-
-## Stop conditions
-
-Stop before Operate when the queue resource, folder scope, payload schema, or retry/error behavior is unresolved.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/rpa-jobs/impl.md

@@ -1,35 +0,0 @@
-# RPA Job Implementation
-
-This document defines the implementation boundary for RPA job task recipes. RPA jobs are implemented as `bpmn:serviceTask`; see [task-recipes/rpa-job.md](../../task-recipes/rpa-job.md).
-
-Use the canonical shell from
-[shared/wrapper-shells.md](../../../../shared/wrapper-shells.md): a
-`bpmn:serviceTask` containing `uipath:activity version="v1"` and nested
-`uipath:type value="Orchestrator.StartJob" version="v1"`, with job arguments
-and outputs as direct `uipath:activity` children.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:serviceTask` wrapper for RPA job execution.
-- Documented `Orchestrator.StartJob` `uipath:activity` shell.
-- Input CDATA for job arguments in `uipath:activity` using `vars.<variableId>` references.
-- `uipath:activity` outputs for job result, status, outputs, and exception fields.
-- Retry, timeout, and boundary error paths.
-
-## CLI or operator-owned implementation
-
-The CLI or operator must resolve:
-
-- Real process, release, folder, robot, and binding metadata.
-- Generated package resources and argument schemas.
-- Creation or update of the RPA automation itself.
-
-## Validation expectations
-
-- Process binding expression resolves.
-- Argument names match the resolved process contract.
-- Wait and timeout behavior is explicit.
-- Outputs map to declared writable variable ids.
-- No release keys, folder IDs, robot names, or exported private metadata are committed.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/rpa-jobs/planning.md

@@ -1,29 +0,0 @@
-# RPA Job Planning
-
-Use this reference when planning Orchestrator RPA process execution from BPMN. RPA jobs are resource recipes for `bpmn:serviceTask`, not peer BPMN element types. See [task-recipes/rpa-job.md](../../task-recipes/rpa-job.md).
-
-## When to use
-
-- Starting an unattended or attended process job.
-- Passing BPMN variables into an RPA process.
-- Waiting for job result or routing by status.
-- Handling job faults, timeouts, and business exceptions.
-
-## Planning steps
-
-1. Identify process, folder/resource scope, input arguments, output arguments, and wait behavior.
-2. Decide if the BPMN path should continue after starting the job or wait for completion.
-3. Plan job ID, status, output, and error variables.
-4. Add boundary timeout/error behavior and retry intent.
-5. Use placeholder-safe bindings unless the operator provides public-safe resource references.
-6. Hand missing RPA project creation or editing to the RPA skill; do not create it here.
-
-## Model may draft
-
-- `bpmn:serviceTask` wrapper with documented `Orchestrator.StartJob` shell.
-- Input/output mappings and error paths.
-- Public-safe binding placeholders and diagram geometry.
-
-## Stop conditions
-
-Stop before Operate when process identity, folder binding, argument schema, or wait semantics are unresolved.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/script/impl.md

@@ -1,118 +0,0 @@
-# Script Implementation
-
-This document defines the implementation boundary for script tasks.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:scriptTask` with `scriptFormat="JavaScript"`.
-- `bpmn:script` content in CDATA.
-- `uipath:scriptVersion`.
-- `uipath:mapping` for `args` input and outputs.
-- Declared variables and JSON schemas used by the script.
-- Boundary error paths.
-
-## Implementation rules
-
-- Script tasks execute through Jint, not Node.js or a browser runtime.
-- Keep script source deterministic and side-effect-light.
-- Keep the XML mapping input named `args`, but read mapped fields as top-level
-  script identifiers. For example, a mapped `caseId` field is available as
-  `caseId`, not `args.caseId`.
-- When mapping BPMN variables into script inputs, use runtime variable-id
-  expressions such as `=vars.Var_CaseId`, not bare names such as `=caseId`.
-- Return or map explicit outputs instead of mutating undeclared globals.
-- Script output mappings must target variables through the `var` attribute.
-  Do not put the target variable id in `name`. Use `name` for the output
-  field/display name and `var` for the declared BPMN variable id:
-
-  ```xml
-  <bpmn:process id="Process_RiskScore" isExecutable="true">
-    <bpmn:extensionElements>
-      <uipath:variables version="v1">
-        <uipath:input id="Var_Amount" name="amount" type="number" elementId="Start_Manual" />
-        <uipath:input id="Var_DaysOverdue" name="daysOverdue" type="number" elementId="Start_Manual" />
-        <uipath:output id="Var_RiskScore" name="riskScore" type="number" />
-      </uipath:variables>
-    </bpmn:extensionElements>
-    ...
-  </bpmn:process>
-  ```
-
-  ```xml
-  <uipath:mapping version="v1">
-    <uipath:type value="BPMN.ScriptTask" version="v1" />
-    <uipath:input name="args"><![CDATA[
-      {"amount":"=vars.Var_Amount","daysOverdue":"=vars.Var_DaysOverdue"}
-    ]]></uipath:input>
-    <uipath:output name="riskScore" type="number" var="Var_RiskScore" source="=result.response" />
-  </uipath:mapping>
-  ```
-- Prefer `uipath:scriptVersion value="v3"` unless preserving an imported version.
-- Available helpers are limited to `uipath.aggregate`, `uipath._aggregate`, `uipath._pipe`, and no-op `console` methods.
-- Do not use npm packages, filesystem, network, browser globals, or long-running async behavior.
-- Keep execution within the 64 MB memory and 30 second timeout envelope.
-- Do not embed secrets, account data, URLs, or local paths.
-- Do not use scripts as a substitute for connector enrichment or RPA work.
-
-## Minimal Jint script task shell
-
-Copy this shape when authoring a new BPMN script task. It is the exact
-mapping shape Maestro expects: `uipath:input name="args"`
-wraps the mapped fields, the script body reads top-level identifiers,
-and the output maps back through `=result.response` for scalar returns or
-`=result.response.<field>` for object fields.
-
-```xml
-<bpmn:scriptTask id="Task_RiskScore" name="Risk Score" scriptFormat="JavaScript">
-  <bpmn:extensionElements>
-    <uipath:scriptVersion value="v3" />
-    <uipath:mapping version="v1">
-      <uipath:type value="BPMN.ScriptTask" version="v1" />
-      <uipath:context>
-        <uipath:inputSchema><![CDATA[{"type":"object","properties":{"amount":{"type":"number"},"daysOverdue":{"type":"number"}}}]]></uipath:inputSchema>
-      </uipath:context>
-      <uipath:input name="args" type="json" target="bodyField"><![CDATA[{"amount":"=vars.Var_Amount","daysOverdue":"=vars.Var_DaysOverdue"}]]></uipath:input>
-      <uipath:output name="riskScore" type="number" var="Var_RiskScore" source="=result.response" />
-    </uipath:mapping>
-  </bpmn:extensionElements>
-  <bpmn:incoming>Flow_Start_To_RiskScore</bpmn:incoming>
-  <bpmn:outgoing>Flow_RiskScore_To_End</bpmn:outgoing>
-  <bpmn:script><![CDATA[
-var score = amount * 0.01 + daysOverdue * 2;
-return { response: score };
-]]></bpmn:script>
-</bpmn:scriptTask>
-```
-
-Required pieces:
-
-| Position | Required token | Why |
-| --- | --- | --- |
-| `bpmn:scriptTask` attribute | `scriptFormat="JavaScript"` | Selects the Jint executor |
-| `uipath:scriptVersion` | `value="v3"` for new scripts; preserve `value="v2"` only on imports | Selects the script contract |
-| `uipath:input` | `name="args"` | The canvas merges `args` JSON into top-level script identifiers |
-| `uipath:input` body | `=vars.<variableId>` for each mapped field | Reads root variables by id, not by name |
-| `bpmn:script` CDATA | top-level identifiers (`amount`, `daysOverdue`); not `args.amount` | Jint sees the merged JSON as top-level vars |
-| `uipath:output` | `source="=result.response"` for scalar returns, or `source="=result.response.<field>"` for object fields; `var` points at a declared variable id | Maps the script return back to a declared variable |
-
-Anti-patterns the checker rejects:
-
-- `uipath:input` with `name` other than `args`.
-- Bare `=amount` style expressions instead of `=vars.Var_Amount`.
-- `args.amount` style reads inside the script body.
-- Missing `uipath:scriptVersion` when the canvas requires it.
-- Returning a bare value instead of `{ response: ... }` for `v2+` mappings.
-- Mapping object returns with `source="=result.summary"` after returning
-  `{ summary: "..." }`; use `source="=result.response.summary"` instead.
-
-## Validation expectations
-
-- Input variables exist and are readable.
-- Output variables exist and are writable.
-- Script CDATA is syntactically coherent.
-- `uipath:scriptVersion` is present when required by the local contract.
-- For `v2` and later, returned JSON maps through `=result.response` or a field
-  below it, such as `=result.response.status`; older script versions must
-  return a JSON object.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/script/planning.md

@@ -1,30 +0,0 @@
-# Script Planning
-
-Use this reference when planning BPMN script tasks.
-
-## When to use
-
-- Deterministic in-process data transformation.
-- Small validation or routing helper logic.
-- Preparing request bodies for downstream tasks.
-- Normalizing outputs before gateways or end events.
-
-## Planning steps
-
-1. Confirm the logic belongs inside BPMN instead of an RPA job, API workflow, agent, or connector.
-2. Define input variables, output variables, and error behavior.
-3. Keep scripts small, deterministic, and public-safe.
-4. Plan `args` input shape and output mappings.
-5. Add boundary error handling when script failure should be recoverable.
-6. Avoid secrets, tenant data, network calls, and private examples.
-
-## Model may draft
-
-- `bpmn:scriptTask` with JavaScript script CDATA.
-- `uipath:scriptVersion`.
-- Input and output mappings using declared variables. See [impl.md](impl.md#minimal-jint-script-task-shell) for the exact required shape.
-- Diagram geometry and surrounding error paths.
-
-## Stop conditions
-
-Stop when the script needs secrets, network access, long-running work, external packages, or customer-specific logic that should be implemented outside BPMN.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/sequence-flows/impl.md

@@ -1,30 +0,0 @@
-# Sequence Flow Implementation
-
-This document defines the implementation boundary for BPMN sequence flows.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:sequenceFlow` with `id`, `sourceRef`, `targetRef`, and optional `name`.
-- `bpmn:conditionExpression` bodies.
-- `incoming` and `outgoing` child references on flow nodes.
-- Gateway `default` attributes that reference sequence flows.
-- `bpmndi:BPMNEdge` waypoints.
-
-## Implementation rules
-
-- Keep sequence flows inside one process or subprocess scope.
-- Use `xsi:type="bpmn:tFormalExpression"` for condition expressions when the file uses that convention.
-- Use a leading `=` for UiPath runtime expressions and follow
-  [expression-authoring.md](../../../../shared/expression-authoring.md).
-- Do not attach conditions to outgoing flows from parallel gateways.
-- Update both XML references and diagram edges together.
-
-## Validation expectations
-
-- Every sequence flow source and target exists.
-- Connected elements reference the sequence flow consistently.
-- Conditional expressions parse and use `vars.<variableId>` for declared variables.
-- Default flows are not also treated as mandatory conditional branches.
-- Every visible sequence flow has a BPMN DI edge.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/sequence-flows/planning.md

@@ -1,30 +0,0 @@
-# Sequence Flow Planning
-
-Use this reference when planning control-flow edges between BPMN nodes in the same scope.
-
-## When to use
-
-- Connecting tasks, events, gateways, and subprocesses.
-- Adding branch conditions or default routes.
-- Re-routing existing process paths.
-- Adding diagram waypoints for Studio Web rendering.
-
-## Planning steps
-
-1. Identify source and target elements and confirm they are in the same BPMN scope.
-2. Decide whether the flow is unconditional, conditional, or a gateway default.
-3. Name flows only when the label helps reviewers understand a branch.
-4. Plan expressions from declared variables and mappings.
-5. Update diagram waypoints with readable routing.
-6. Check downstream joins and end states after every route change.
-
-## Model may draft
-
-- `bpmn:sequenceFlow` elements.
-- Conditional expressions and default-route labels.
-- Incoming and outgoing references on connected nodes.
-- BPMN DI edges and waypoints.
-
-## Stop conditions
-
-Stop when a requested route crosses subprocess, event subprocess, or participant boundaries; use message flow, call activity, or subprocess modeling instead.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/service-tasks/impl.md

@@ -1,33 +0,0 @@
-# Service Task Implementation
-
-This document defines the implementation boundary for `bpmn:serviceTask`. Resource-backed task choices live in [task-recipes/](../../task-recipes/).
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:serviceTask` elements, flow references, and diagram shapes.
-- `uipath:mapping` for declared variables.
-- `uipath:retry`, `uipath:errorMapping`, and tags when explicitly requested;
-  use [error-handling.md](../../../../shared/error-handling.md) for current shapes.
-- Documented non-Integration-Service `uipath:activity` shells with public-safe context.
-- Boundary error or timeout events attached to the task.
-
-Use service tasks for `Orchestrator.StartJob`, `Orchestrator.StartAgentJob`, `A2A.AgentExecution`, `Orchestrator.ExecuteApiWorkflowAsync`, `Orchestrator.CreateAndWaitForQueueItem`, and supported `Intsvc.*` service executions. Do not use a service task for new queue-create, HITL, business-rule, script, or call-activity XML.
-
-## CLI-owned implementation
-
-The CLI must enrich or validate:
-
-- Integration Service payloads.
-- Dynamic schemas and generated outputs.
-- Binding resources in generated package files.
-- Real resource identifiers for cloud-side execution.
-
-## Validation expectations
-
-- Required service context fields exist for the selected type.
-- Inputs reference declared variables with `vars.<variableId>` or use literals.
-- Outputs map to declared writable variables.
-- Binding expressions resolve to root `uipath:bindings` or generated bindings.
-- Boundary events use valid event definitions and stay in scope.