@uipath/skills 1.195.0

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

@@ -0,0 +1,36 @@
+# Business Rule Implementation
+
+This document defines the implementation boundary for business rule task recipes. Business rules are implemented as `bpmn:businessRuleTask`; see [task-recipes/business-rule.md](../../task-recipes/business-rule.md).
+
+Use the canonical shell from
+[shared/wrapper-shells.md](../../../../shared/wrapper-shells.md): a
+`bpmn:businessRuleTask` containing `uipath:activity version="v1"` and nested
+`uipath:type value="Orchestrator.BusinessRules" version="v1"`, with fact and
+result payloads as direct `uipath:activity` children.
+Do not author new business rule XML with legacy
+`<uipath:activity type="Orchestrator.BusinessRules">` shorthand.
+
+## Model-owned implementation
+
+The model may edit:
+
+- `bpmn:businessRuleTask` wrapper.
+- Documented `Orchestrator.BusinessRules` `uipath:activity` shell.
+- Input CDATA for facts in `uipath:activity` using `vars.<variableId>` references.
+- `uipath:activity` outputs for rule result, matched rule, diagnostics, and outcome.
+- Gateway conditions that route by declared rule outputs through `vars.<variableId>`.
+
+## CLI or operator-owned implementation
+
+The CLI or operator must resolve:
+
+- Real business rule resource identity, version, and binding metadata.
+- Dynamic input/output schemas.
+- Generated package metadata.
+
+## Validation expectations
+
+- Rule binding resolves before upload/run.
+- Facts match the resolved rule input contract.
+- Result variables exist and route expressions are assignment-free.
+- Fallback or manual review paths exist when rule failure is recoverable.

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

@@ -0,0 +1,29 @@
+# Business Rule Planning
+
+Use this reference when planning business rule execution from BPMN. Business rules are `bpmn:businessRuleTask`, not generic service tasks. See [task-recipes/business-rule.md](../../task-recipes/business-rule.md).
+
+## When to use
+
+- Evaluating rule tables or decision logic managed outside the BPMN diagram.
+- Routing based on a rule result.
+- Keeping business decisions separate from script code or gateway expressions.
+- Combining rule evaluation with HITL review, queueing, RPA, or API workflow calls.
+
+## Planning steps
+
+1. Identify rule resource, input facts, output shape, and decision routes.
+2. Decide whether rule failure should stop, retry, or route to manual review.
+3. Declare variables for facts, result, diagnostics, and selected outcome.
+4. Add a gateway after the rule task when result values drive routing.
+5. Use placeholder-safe bindings until the rule resource is resolved.
+
+## Model may draft
+
+- `bpmn:businessRuleTask` wrapper with documented `Orchestrator.BusinessRules` shell.
+- Input/output mappings and post-rule gateway conditions.
+- Retry and boundary error paths.
+- Public-safe binding placeholders.
+
+## Stop conditions
+
+Stop before Operate when rule identity, input schema, output schema, version, or binding is unresolved.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/call-activity-subprocess/impl.md

@@ -0,0 +1,67 @@
+# Call Activity and Subprocess Implementation
+
+This document defines the implementation boundary for call activities and subprocesses. For agentic or case-management process calls, see [task-recipes/call-activity.md](../../task-recipes/call-activity.md).
+
+## Model-owned implementation
+
+The model may edit:
+
+- `bpmn:subProcess`, event subprocess, and `bpmn:callActivity`.
+- Nested events, tasks, gateways, flows, and diagram planes.
+- Scoped variables and `uipath:mapping` for boundary data.
+- Boundary events, retries, and error mappings.
+- Placeholder-safe called element references when documented.
+
+## Subprocess rules
+
+- Use inline `bpmn:subProcess` when the work stays in the local BPMN source and
+  needs local tasks, gateways, variables, or boundary handlers.
+- Keep sequence flows inside the subprocess scope. Do not connect a nested node
+  directly to a root-level node.
+- Put subprocess-local variables in the subprocess extension elements only when
+  they should not be root state.
+- Use root variables for data that must leave the subprocess.
+- Expanded subprocesses need visible child shapes and edges in the diagram.
+- Collapsed subprocesses may show only the wrapper shape, but nested content
+  still needs a product-supported diagram strategy before upload.
+
+## Event subprocess rules
+
+- Use event subprocesses for scoped error or message handling, not as generic
+  containers.
+- Set `triggeredByEvent="true"`.
+- Give the event subprocess exactly one start event.
+- For error event subprocesses, use a supported error start definition and the
+  shapes from [error-handling.md](../../../../shared/error-handling.md).
+- Prefer a boundary error event when one activity owns the failure branch.
+  Prefer an event subprocess when the scope needs a shared fallback handler.
+
+## Call activity rules
+
+- Use `bpmn:callActivity` when execution leaves the local BPMN scope for an
+  agentic, case-management, or other called process contract.
+- Keep called-resource identity placeholder-safe until the CLI or operator
+  resolves the actual resource.
+- Put call inputs and outputs in the same mapping pattern as other activities:
+  payload inputs read `=vars.<variableId>` and outputs target declared mutable
+  variable ids.
+- Add boundary events and retry/error mapping only when the called process
+  contract makes the error behavior explicit.
+- Do not inline a called process into a subprocess unless the user explicitly
+  wants a local copy of the child workflow.
+
+## CLI or operator-owned implementation
+
+The CLI or operator must resolve:
+
+- Real called process, package, API workflow, agent, or solution resource identity.
+- Generated bindings and package metadata.
+- Dynamic input/output schemas for called resources.
+
+## Validation expectations
+
+- Sequence flows stay within subprocess scope.
+- Event subprocess start rules are satisfied.
+- Call activity inputs and outputs match declared contracts.
+- Nested visible elements have diagrams.
+- Called-resource bindings are resolved before upload/run.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/call-activity-subprocess/planning.md

@@ -0,0 +1,29 @@
+# Call Activity and Subprocess Planning
+
+Use this reference when planning reusable or scoped process blocks. For agentic or case-management process calls, see [task-recipes/call-activity.md](../../task-recipes/call-activity.md).
+
+## When to use
+
+- Expanded subprocesses for local scoped work.
+- Event subprocesses for scoped exception handling.
+- Call activities for reusable processes or external workflows.
+- Isolating variables, retries, and boundaries.
+
+## Planning steps
+
+1. Decide whether the work is local subprocess content or a call to another reusable process.
+2. Define subprocess start/end behavior, variables, and mappings.
+3. Confirm whether nested content must render in Studio Web and needs its own diagram.
+4. Plan boundary events on the activity or subprocess.
+5. Keep sequence flows inside scope; use mappings for data crossing boundaries.
+6. Record unresolved called-resource bindings as placeholders.
+
+## Model may draft
+
+- `bpmn:subProcess`, event subprocess, and `bpmn:callActivity` structure.
+- Scoped variables, input/output mappings, loop metadata, and diagram geometry.
+- Boundary events and error paths.
+
+## Stop conditions
+
+Stop when a called process/resource is unknown, subprocess scope would be crossed by sequence flows, or input/output contracts are unclear.

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

@@ -0,0 +1,29 @@
+# Connector Implementation
+
+This document defines the implementation boundary for connector-backed BPMN elements.
+
+## Model-owned implementation
+
+The model may edit:
+
+- Standard BPMN wrapper elements around connector intent.
+- Variables and mappings that consume connector outputs.
+- Error, timeout, and fallback paths.
+- Diagram geometry.
+
+## CLI-owned implementation
+
+The CLI or registry-backed tool must generate:
+
+- `Intsvc.*` `uipath:activity` or `uipath:event` payloads.
+- Connector key, operation/event, object, and version context.
+- Connection binding expressions and `bindings_v2.json` resources.
+- Dynamic input/output schemas and generated output metadata.
+- Trigger property bindings for connector triggers.
+
+## Validation expectations
+
+- Every executable connector element has enriched context, inputs, outputs, and schemas.
+- Binding expressions resolve.
+- Required parameters and filters are present.
+- No tenant URLs, connection IDs, folder keys, or copied exported metadata are committed.

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

@@ -0,0 +1,33 @@
+# Connector Planning
+
+Use this reference for connector-backed activities and triggers. Connector execution is Integration Service-owned.
+
+## When to use
+
+- Connector activities.
+- Connector triggers.
+- Connector-backed waits.
+- Unified HTTP or authenticated HTTP through Integration Service.
+- Dynamic connector schemas.
+
+## Planning steps
+
+1. Identify connector, operation or event, object, filters, inputs, outputs, and failure behavior.
+2. Decide if the connector is a start trigger, intermediate wait, service task, or boundary behavior.
+3. Plan surrounding BPMN structure and variables.
+4. Record required operator choices: connection, folder scope, operation, filters, and output variable names.
+5. Leave enrichment to the CLI before validation for upload/run.
+
+## Model may draft
+
+- Placeholder BPMN wrappers with stable IDs and public-safe labels.
+- Surrounding flows, gateways, variables, and error paths.
+- Draft notes that describe connector intent.
+
+## CLI must provide
+
+- Connector metadata, operation/event metadata, connection binding, trigger properties, schemas, and generated binding resources.
+
+## Stop conditions
+
+Stop before Operate if the connector element is not CLI-enriched or if copied private connection metadata appears in the source.

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

@@ -0,0 +1,32 @@
+# Gateway Implementation
+
+This document defines the implementation boundary for BPMN gateways.
+
+## Model-owned implementation
+
+The model may edit:
+
+- `bpmn:exclusiveGateway`, `bpmn:inclusiveGateway`, `bpmn:parallelGateway`, and `bpmn:eventBasedGateway`.
+- Incoming and outgoing `bpmn:sequenceFlow` references.
+- `default` attributes for exclusive and inclusive split gateways.
+- `bpmn:conditionExpression` on outgoing flows.
+- Gateway shapes and sequence flow edges.
+
+## Implementation rules
+
+- Store branch logic on outgoing sequence flows, not on the gateway element.
+- Use a leading `=` for runtime expressions where Maestro expects expressions;
+  follow [expression-authoring.md](../../../../shared/expression-authoring.md).
+- Do not use assignment expressions in gateway conditions.
+- Prefer explicit default flows for fallthrough paths.
+- Use parallel gateways only when every branch should run or rejoin.
+- Use event-based gateways only when the next route is determined by the first event that occurs.
+- Do not generate `bpmn:complexGateway`; preserve imported complex gateways only.
+
+## Validation expectations
+
+- Split gateways have the right number of outgoing flows.
+- Join gateways have the right number of incoming flows.
+- Defaults reference an outgoing flow from the same gateway.
+- Conditional branches reference declared variables with `vars.<variableId>`.
+- Event-based gateway outgoing flows lead to valid catch events or receive tasks.

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

@@ -0,0 +1,34 @@
+# Gateway Planning
+
+Use this reference when planning BPMN routing, branching, and joining.
+
+## When to use
+
+- Exclusive, inclusive, parallel, or event-based decisions.
+- Merging alternative paths.
+- Joining parallel or inclusive work.
+- Waiting for one of several events.
+
+## Planning steps
+
+1. Identify whether the gateway splits, joins, or does both.
+2. Choose the simplest gateway type that matches the business semantics.
+3. Put human-readable branch intent on outgoing sequence flows.
+4. Decide the default route for exclusive and inclusive splits.
+5. Decide join semantics for parallel and inclusive branches.
+6. Ensure no sequence flow crosses subprocess or participant scope.
+7. Plan diagram placement so conditions and routes are reviewable.
+
+## Model may draft
+
+- Standard gateway elements.
+- Outgoing sequence flow conditions and default flow references.
+- Public-safe IDs, names, and diagram geometry.
+- Text annotations that explain unresolved business decisions.
+
+## Stop conditions
+
+Stop for user input when branch conditions are ambiguous, defaults are unknown, or a join can deadlock because the triggering split semantics are unclear.
+
+Do not plan new `bpmn:complexGateway` paths. Preserve imported complex gateways
+and report them as unsupported for regeneration.

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

@@ -0,0 +1,42 @@
+# HITL Implementation
+
+This document defines the implementation boundary for HITL task recipes. HITL is implemented as `bpmn:userTask`; see [task-recipes/hitl.md](../../task-recipes/hitl.md).
+
+Use the canonical shell from
+[shared/wrapper-shells.md](../../../../shared/wrapper-shells.md): a
+`bpmn:userTask` containing `uipath:activity version="v1"` and nested
+`uipath:type value="Actions.HITL" version="v1"`, with task data and result
+payloads as direct `uipath:activity` children.
+
+## Model-owned implementation
+
+The model may edit:
+
+- `bpmn:userTask` wrapper for human work.
+- Documented `Actions.HITL` `uipath:activity` shell.
+- Input body CDATA in `uipath:activity` using synthetic payload fields.
+- `uipath:activity` outputs for action result, completed fields, comments, and decision values.
+- Boundary timeout/error events and post-task gateways.
+
+## Operator or CLI-owned implementation
+
+The operator or tooling must resolve:
+
+- Real Action Center app, form, folder, queue, group, or assignee references.
+- Dynamic form schemas and generated resources.
+- Tenant-specific routing and notification metadata.
+
+For a new draft HITL node, do not add an orphan root `uipath:bindings` entry
+just to represent an unresolved Action Center form or app. Keep unresolved
+Action Center resources in the project notes until the operator or CLI supplies
+a concrete binding contract. If a binding is authored, it must be referenced by
+the task and backed by generated package metadata before Operate.
+
+## Validation expectations
+
+- Task inputs use `vars.<variableId>` and outputs target declared writable variable ids.
+- Outcome gateway conditions match possible result values.
+- Timeout paths do not discard required process state.
+- Binding references are placeholders or resolved generated resources, and no
+  unreferenced HITL binding is left in root metadata.
+- No personal names, emails, tenant URLs, or exported form payloads are committed.

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

@@ -0,0 +1,30 @@
+# HITL Planning
+
+Use this reference when planning human-in-the-loop Action Center tasks in BPMN. HITL is `bpmn:userTask`, not a generic service task. See [task-recipes/hitl.md](../../task-recipes/hitl.md).
+
+## When to use
+
+- Human approval, validation, enrichment, or exception handling.
+- A task must pause the process until a person completes work.
+- Outcomes route the process through gateways.
+- Escalation or timeout paths are required.
+
+## Planning steps
+
+1. Define the human decision or data entry outcome.
+2. Decide required inputs, task payload, outputs, assignee/routing intent, due date, and escalation behavior.
+3. Plan result variables and gateway routes after completion.
+4. Add timeout or cancellation paths when the process cannot wait indefinitely.
+5. Use public-safe placeholders for queues, groups, folders, apps, and task titles.
+6. Confirm whether any Action Center resource must be resolved by tooling or the operator.
+
+## Model may draft
+
+- `bpmn:userTask` wrapper and `Actions.HITL` shell when the contract is documented.
+- Input/output mappings and outcome routes.
+- Boundary timeout/error paths.
+- Public-safe labels and diagram geometry.
+
+## Stop conditions
+
+Stop before Operate when real assignee, folder, app, task form, schema, or resource binding is unresolved.

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

@@ -0,0 +1,134 @@
+# 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

@@ -0,0 +1,67 @@
+# 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

@@ -0,0 +1,50 @@
+# 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

@@ -0,0 +1,29 @@
+# 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.