@uipath/skills 1.195.0

package/skills/uipath-maestro-case/references/plugins/stages/impl-json.md

@@ -0,0 +1,164 @@
+---
+direct-json: supported
+---
+
+# stages — JSON Implementation
+
+Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../case-editing-operations.md).
+
+## Input spec (from `tasks.md`)
+
+| Field | Required | Notes |
+|---|---|---|
+| `displayName` (from T-entry title) | yes | Stage label |
+| `description` | yes | Always emit, sourced from the T-entry's description field in `sdd.md`. |
+| `isRequired` | yes | From `sdd.md`; fall back to `false` when the T-entry does not specify. Consumed by later case-exit rule `required-stages-completed`. |
+| Stage kind | yes | `regular` or `exception` — determined by the T-entry plugin (`Create stage …` vs `Create exception stage …`) |
+
+## ID generation
+
+- Prefix: `Stage_` (same for regular and exception stages)
+- Suffix length: 6
+- Algorithm: per [`case-editing-operations.md § ID Generation`](../../case-editing-operations.md#id-generation)
+
+Record `T<n> → Stage_xxxxxx` in `id-map.json` for downstream cross-reference.
+
+## Position (stateful, v19 only)
+
+**v19 mode only.** v20 mode skips position math entirely (Rule 19) — see § Recipe (v20) below.
+
+**Before writing (v19)**, count existing stages:
+
+```text
+existingStageCount = schema.nodes.filter(n =>
+  n.type === "case-management:Stage" ||
+  n.type === "case-management:ExceptionStage"
+).length
+```
+
+Then compute:
+
+```text
+position.x = 100 + existingStageCount * 500
+position.y = 200
+```
+
+Trigger nodes are NOT counted.
+
+## Recipe — Regular Stage (v19)
+
+Append (or prepend) this object to `nodes` — both orderings are valid for the frontend:
+
+```json
+{
+  "id": "<Stage_xxxxxx>",
+  "type": "case-management:Stage",
+  "position": { "x": <computed>, "y": 200 },
+  "style": { "width": 304, "opacity": 0.8 },
+  "measured": { "width": 304, "height": 128 },
+  "width": 304,
+  "zIndex": 1001,
+  "data": {
+    "label": "<displayName>",
+    "description": "<description from sdd.md>",
+    "isRequired": <true|false from sdd.md; false if unspecified>,
+    "parentElement": { "id": "root", "type": "case-management:root" },
+    "isInvalidDropTarget": false,
+    "isPendingParent": false,
+    "tasks": []
+  }
+}
+```
+
+**Do not initialize `entryConditions` or `exitConditions` on a regular Stage at creation time.** Regular stages acquire those keys later when the condition plugins (stage-entry-conditions / stage-exit-conditions) write them — do not create the keys here.
+
+## Recipe — Regular Stage (v20)
+
+**Strip all node-level layout fields per Rule 19.** No `position`, `style`, `measured`, `width`, `height`, `zIndex`. No position math. FE auto-layouts on canvas load.
+
+```json
+{
+  "id": "<Stage_xxxxxx>",
+  "type": "case-management:Stage",
+  "data": {
+    "label": "<displayName>",
+    "description": "<description from sdd.md>",
+    "isRequired": <true|false from sdd.md; false if unspecified>,
+    "parentElement": { "id": "root", "type": "case-management:root" },
+    "isInvalidDropTarget": false,
+    "isPendingParent": false,
+    "tasks": []
+  }
+}
+```
+
+> **`parentElement.id` stays `"root"`** even though there is no `"root"` node in v20 disk JSON. The literal `"root"` is canvas-side — `transformCaseInMemoryJsonToDiskJson` keeps the reference intact.
+
+## Recipe — Exception Stage (v19)
+
+Same as regular v19, with `type: "case-management:ExceptionStage"` and two additional `data` fields initialized empty:
+
+```json
+{
+  "id": "<Stage_xxxxxx>",
+  "type": "case-management:ExceptionStage",
+  "position": { "x": <computed>, "y": 200 },
+  "style": { "width": 304, "opacity": 0.8 },
+  "measured": { "width": 304, "height": 128 },
+  "width": 304,
+  "zIndex": 1001,
+  "data": {
+    "label": "<displayName>",
+    "description": "<description from sdd.md>",
+    "isRequired": <true|false from sdd.md; false if unspecified>,
+    "parentElement": { "id": "root", "type": "case-management:root" },
+    "isInvalidDropTarget": false,
+    "isPendingParent": false,
+    "tasks": [],
+    "entryConditions": [],
+    "exitConditions": []
+  }
+}
+```
+
+## Recipe — Exception Stage (v20)
+
+Same as regular v20 (no layout fields), with `type: "case-management:ExceptionStage"` and two additional `data` fields initialized empty:
+
+```json
+{
+  "id": "<Stage_xxxxxx>",
+  "type": "case-management:ExceptionStage",
+  "data": {
+    "label": "<displayName>",
+    "description": "<description from sdd.md>",
+    "isRequired": <true|false from sdd.md; false if unspecified>,
+    "parentElement": { "id": "root", "type": "case-management:root" },
+    "isInvalidDropTarget": false,
+    "isPendingParent": false,
+    "tasks": [],
+    "entryConditions": [],
+    "exitConditions": []
+  }
+}
+```
+
+## Semantic position
+
+The new node is added to the top-level `nodes` array. Append or prepend — both are valid for the frontend. Append is preferred for simpler diffing.
+
+## Post-write validation
+
+After writing, confirm:
+
+- `nodes` contains the new node with the generated ID
+- `nodes[].type` is `case-management:Stage` or `case-management:ExceptionStage` per the intended kind
+- `nodes[].data.label` matches the T-entry's displayName
+- `nodes[].data.isRequired` is present and boolean
+- **v19 only:** all render fields (`position`, `style`, `measured`, `width`, `zIndex`, `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`) are present
+- **v20 only:** NO `position`, `style`, `measured`, `width`, `height`, `zIndex` at the node level (Rule 19). Only `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent` remain
+- For ExceptionStage: `data.entryConditions: []` and `data.exitConditions: []` are present (initialized as empty arrays at creation time)
+- For regular Stage at creation time: `data.entryConditions` / `data.exitConditions` are absent — the conditions plugins will create and populate them later if the sdd.md calls for it
+
+Run `uip maestro case validate <file> --output json` after all stages for this plugin's batch are added.
+

package/skills/uipath-maestro-case/references/plugins/stages/planning.md

@@ -0,0 +1,100 @@
+# stages — Planning
+
+A stage node inside the case. Stages contain tasks and connect via edges. Two variants (`stage` and `exception`) share the same plugin.
+
+## Terminology
+
+| Term | Same as |
+|------|---------|
+| Regular stage | `case-management:Stage` (default) |
+| Exception stage | `case-management:ExceptionStage` |
+| Secondary stage | Alias for exception stage. Sometimes used in sdd.md. |
+
+The only difference between `stage` and `exception` is the JSON `type` value (`case-management:Stage` vs `case-management:ExceptionStage`). All other fields (label, description, entry/exit conditions, tasks, SLA) behave identically. `ExceptionStage` can carry `slaRules` (expression-driven SLA) the same as a regular Stage; conditional SLA rules themselves are root-only.
+
+## When to Pick `exception` vs `stage`
+
+Use exception (also "secondary stage") when the sdd.md describes any of:
+
+- A handler for errors, escalations, or rejected items
+- A rework / retry loop
+- An on-error fallback
+- A stage only reached via **interrupting** entry conditions
+- Anything labeled "exception", "fallback", "on-error", or "secondary"
+
+Otherwise default to a regular stage.
+
+When ambiguous, use **AskUserQuestion** with both options + "Something else".
+
+### Wiring constraints for exception / secondary stages
+
+Exception stages **have no edges** — neither inbound nor outbound. They are fully detached from the edge graph:
+
+- ❌ No edge into an exception stage (not from Triggers, not from regular stages, not from other exception stages).
+- ❌ No edge out of an exception stage to any stage.
+- ✅ **Reached via an interrupting entry condition** on the exception stage itself (fires based on case state, not by traversing an edge). See [stage-entry-conditions plugin](../conditions/stage-entry-conditions/planning.md).
+- ✅ **Exits via a `return-to-origin` exit condition** — routes the case back to the stage it came from, through the exit condition rule, not a new edge. See [stage-exit-conditions plugin](../conditions/stage-exit-conditions/planning.md).
+
+If the sdd.md describes an exception stage that is connected to other stages via edges, or that flows onward to another stage, flag this to the user. Options:
+
+- Re-model the node as a regular stage (so edges are allowed).
+- Use a `return-to-origin` exit and let the origin stage's existing edges handle the onward flow.
+
+This constraint is also documented in the [edges plugin](../edges/planning.md).
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `label` | sdd.md stage name | Shown in the UI. |
+| `type` | sdd.md intent | `stage` (default) or `exception` — see above |
+| `description` | sdd.md stage description | Optional. |
+| `isRequired` | sdd.md (default `true` for regular, `false` for exception) | **Planning-only metadata.** See note below. |
+
+### Note on `isRequired`
+
+`isRequired` is written into the stage node's `data.isRequired` and is consumed downstream by case exit conditions with `rule-type: required-stages-completed` — the case completes when all stages flagged `isRequired: true` have completed.
+
+Record `isRequired` in `tasks.md` for each stage. Use:
+- `true` — **Default for regular stages.** Stage is on the main flow path and must complete for case completion.
+- `false` — **Default for exception stages.** Exception / optional / fallback / rework stages only reached via conditional/interrupting entry conditions.
+
+Implementation phase consumes this value when adding case-exit-conditions; the stage itself is created without it.
+
+## Registry Resolution
+
+**None.** Stages have no registry representation — no `taskTypeId`, no enrichment.
+
+## Auto-Positioning
+
+Stage position is auto-computed by the impl-json recipe: `x = 100 + (existingStageCount * 500), y = 200`. The planning entry does not carry coordinates unless the sdd.md specifies explicit ones.
+
+## Ordering
+
+Stages are created **after** the root case (T01) and **before** any edges, tasks, or conditions reference them. Each stage write produces a `StageId` — capture it in the planning/execution capture map. Downstream T-entries (edges, tasks, conditions, SLA) use the stage **name** in `tasks.md`; the implementation phase resolves the name to the captured `StageId`.
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Create stage "<label>"
+- type: stage
+- description: "<description from sdd.md>"
+- isRequired: <true|false from sdd.md; false if unspecified>
+- order: after T<m>
+- verify: Confirm Result: Success, capture StageId
+```
+
+Exception variant:
+
+```markdown
+## T<n>: Create exception stage "<label>"
+- type: exception
+- description: "<description from sdd.md>"
+- isRequired: <true|false from sdd.md; false if unspecified>
+- order: after T<m>
+- verify: Confirm Result: Success, capture StageId
+```
+
+## Unresolved Fallback
+
+Stages have no registry lookup, so there is no "unresolved" path. If the sdd.md is missing stage names or descriptions, ask the user with **AskUserQuestion** rather than proceeding with placeholders.

package/skills/uipath-maestro-case/references/plugins/tasks/action/impl-json.md

@@ -0,0 +1,90 @@
+# action task — Implementation (Direct JSON Write)
+
+> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md).
+
+## Task JSON Shape
+
+```json
+{
+  "id": "ty5UcykfU",
+  "type": "action",
+  "displayName": "Review Purchase Order",
+  "elementId": "Stage_aB3kL9-ty5UcykfU",
+  "isRequired": true,
+  "shouldRunOnlyOnce": false,
+  "data": {
+    "taskTitle": "Please review this PO and approve or reject",
+    "priority": "High",
+    "recipient": { "Type": 2, "Value": "approver@corp.com" },
+    "labels": "<labels string>",
+    "name": "=bindings.bG0SraLpg",
+    "folderPath": "=bindings.bH1iJK2lm",
+    "inputs": [],
+    "outputs": []
+  }
+}
+```
+
+- `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
+
+## Action-Specific Fields
+
+> **Unresolved → `"data": {}`.** When `action-app-id` is `<UNRESOLVED>` (or `action-apps-index.json` returned 0 nodes), the entire shape collapses to `"data": {}`. **No exception** for `taskTitle`, `priority`, `recipient`, `labels`, `name`, `folderPath`, `inputs`, `outputs`, or optional `actionCatalogName` — omit every `data.*` key. See [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+| Field | Notes |
+|---|---|
+| `data.taskTitle` | Required on **resolved** action tasks — validator rejects empty. Placeholders omit it (along with every other `data.*` action-specific key); see [placeholder-tasks.md](../../../placeholder-tasks.md). |
+| `data.priority` | `"Low"` \| `"Medium"` (default) \| `"High"` \| `"Critical"` |
+| `data.recipient` | `ActionTaskAssignee` object: `{ "Type": <int>, "Value": "<id-or-email>" }`. See fallback below for unresolved-UUID handling. |
+| `data.actionCatalogName` | **Optional.** Must bind to an existing action catalog resource. Omit unless tasks.md references a known catalog. |
+| `data.labels` | Label set from tasks.md |
+
+`recipient.Type` values: `0` = user ID (sdd `User:`), `1` = group ID (sdd `UserGroup:` / `Role:`), `2` = email address, `3` = `"=vars.<varId>"` (sdd `Expression:`). **Fallback when sdd.md value is not a resolved UUID:** write `{ "Type": <picked>, "Value": "<sdd-string-as-is>" }` — schema-conformant placeholder, user resolves Value later. Drop `data.recipient` only when no Type maps. **Never invent a non-conforming shape** (`{ kind, id }`, `{ scope, target, value }`, etc.) — Studio Web canvas crashes silently; CLI validate misses it.
+
+## Procedure
+
+**Step 0 — Get inputs/outputs schema:**
+
+```bash
+uip maestro case tasks describe --type action --id "<action-app-id>" --output json
+```
+
+Fallback: planning-captured schema from tasks.md. If unavailable, placeholder per [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+**Step 1 — Root-level bindings:**
+
+Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../../variables/bindings/impl-json.md) for the canonical 7-field shape (all required — omitting any causes Studio Web render failure). Per-task overrides:
+
+- `resource`: `"app"`
+- `resourceSubType`: omit (no resourceSubType for action tasks)
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+
+Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
+
+**Step 2 — Write task:**
+
+1. Generate `id` (`t` + 8 chars) and `elementId` (`<stageId>-<taskId>`)
+2. Set `data.taskTitle`, `data.priority`, `data.labels` from tasks.md now (plain strings, not Phase-3 bindings); set `data.actionCatalogName` only when tasks.md references an existing catalog. **`data.recipient` is an object, NEVER a bare string.** The tasks.md `recipient:` line carries a bare value (the SDD typed prefix is stripped in planning) — wrap it as `{ "Type": <int>, "Value": <value> }`, inferring Type from the value shape (`=vars.X` → `3`, email → `2`, UUID → `0`/`1`). E.g. `recipient: =vars.assignedLoanOfficer` → `{ "Type": 3, "Value": "=vars.assignedLoanOfficer" }`. Do not copy the bare value through as `data.recipient`.
+3. Set `data.name` = `=bindings.<nameBindingId>`, `data.folderPath` = `=bindings.<folderPathBindingId>`
+4. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
+
+   **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
+5. Append to target stage's `tasks[laneIndex][]`
+
+> Entry conditions added in Step 10. Only `data.inputs[].value` is deferred to Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md); the scalar `data.*` fields above are final at Step 2.
+
+## Post-Write Verification
+
+- `type: "action"`
+- `data.taskTitle` non-empty
+- `data.name` and `data.folderPath` start with `=bindings.`
+- the bindings array has 2 entries: `resource: "app"`, no `resourceSubType`, `propertyAttribute` = `name` / `folderPath`
+- `data.inputs` and `data.outputs` populated (unless placeholder)
+- `data.recipient` is an **object** `{ Type, Value }`, never a bare string — present whenever tasks.md recorded a `recipient:` line (omitted only for group/role, Skip, or no-Type-maps)
+- `id` captured in `id-map.json`
+
+## Anti-patterns
+
+- **Do NOT emit `data.recipient` as a bare string, drop it, or "resolve" it.** It is always the object `{ Type, Value }` written at Step 2 (not an io-binding target). The tasks.md value (`=vars.X`, email, UUID) is the `Value` — wrap it, don't pass it through. `Type 3` `=vars.X` is the finished runtime reference; copying it through as a string, deferring to Phase 3, or rewriting it to the var's email each break the task. Symptoms: `data.recipient` is a string, or missing while `tasks.md` has `recipient: =vars.X`.
+- **CLI `validate` does NOT check `data.recipient`** — verify presence/shape explicitly (Post-Write Verification).

package/skills/uipath-maestro-case/references/plugins/tasks/action/planning.md

@@ -0,0 +1,81 @@
+# action task — Planning
+
+A human-in-the-loop (HITL) action task. Assigns a task to a user or group for manual review, approval, or data entry via the Actions app.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes a `HITL` task, or any task requiring manual user interaction: approval, review, sign-off, correction, classification by a person.
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `display-name` | sdd.md task name |  |
+| `task-type-id` | Registry resolution (below) | Action-app ID |
+| `task-title` | sdd.md task title or description (see fallback below) | Required for `action` type. |
+| `priority` | sdd.md (default `Medium`) | `Low` / `Medium` / `High` / `Critical`.  |
+| `recipient` | sdd.md assignee email; **prompt the user if silent** | See Recipient Handling below. |
+| `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
+| `outputs` | Discovered via `tasks describe` | Decision, comments, structured form fields |
+| `isRequired` | sdd.md (default `true`) |  |
+
+## Task Title Fallback
+
+`task-title` is what the user sees in the Actions app. Required on resolved action tasks (placeholders skip — see § Unresolved Fallback). Derive in this order:
+
+1. SDD has an explicit title or question field → use it
+2. SDD has a Description → summarize into a short, concise title
+3. Neither → use the `display-name`
+
+## Registry Resolution
+
+1. **Primary cache file:** `action-apps-index.json`.
+2. **Identifier field:** `id` (NOT `entityKey` — action-apps use a different field).
+3. **Name field:** `deploymentTitle` (not `name`).
+4. **Folder field:** `deploymentFolder.fullyQualifiedName`.
+5. **CLI search known to fail** for action-apps — always use direct cache-file inspection.
+6. Discover form fields / inputs / outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
+
+See [registry-discovery.md](../../../registry-discovery.md#cli-search-gaps) for the fallback rationale.
+
+## Unresolved Fallback
+
+Mark `<UNRESOLVED: action-app "<deploymentTitle>" in folder "<folder>" not found in action-apps-index.json>`. Emit only structural fields — drop every action-specific line (`task-title`, `priority`, `recipient`, `inputs`, `outputs`). See [placeholder-tasks.md](../../../placeholder-tasks.md) for the full placeholder entry shape and wiring-block convention.
+
+## Recipient Handling
+
+> Resolved action tasks only — placeholders skip this entire section (see § Unresolved Fallback).
+
+- If sdd.md **names a specific user email**, record it in `tasks.md`. Sets `assignmentCriteria: "user"` at execution time.
+- If sdd.md **names a group or role**, do **not** record a recipient — group assignment is configured separately via Actions app rules. Record a note in `tasks.md` so the user remembers to configure group assignment externally.
+- If sdd.md is **silent on assignee**, **prompt the user** using **AskUserQuestion** with a direct open-ended prompt:
+  > "The action task '<display-name>' has no assignee specified in sdd.md. Who should receive it? Enter an email, a group/role name, or 'Skip' to leave it unassigned for now."
+
+  Parse the user's response:
+  - Looks like an email → record as `recipient: <email>`.
+  - Group / role name → omit recipient; record a note in `tasks.md` reminding the user to configure group assignment externally.
+  - `Skip` or empty → omit recipient.
+
+For open-ended inputs like an email address, use a direct prompt rather than AskUserQuestion with a finite option list.
+
+## tasks.md Entry Format
+
+Resolved action task. For the unresolved placeholder shape, see [placeholder-tasks.md § `tasks.md` Planning-Entry Shape](../../../placeholder-tasks.md#tasksmd-planning-entry-shape).
+
+```markdown
+## T<n>: Add action task "<display-name>" to "<stage>"
+- taskTypeId: <action-app-id>
+- task-title: "<title-shown-to-user>"
+- priority: Medium
+- recipient: user@company.com   # omit when group-assigned or when user chose Skip
+- assignment-note: "<free-form note if group-assigned>"   # optional
+- runOnlyOnce: false   # from sdd.md "Run Only Once" column
+- inputs:
+  - <input_name> <- "<Stage>"."<Task>".<output>
+  - <input_name> = "<literal-or-expression>"
+- outputs: decision, comments
+- isRequired: true
+- order: after T<m>
+- lane: <n>  # FE layout; increment per task. Within `runs-sequentially` group, parallel members share a lane (semantic).
+- verify: Confirm Result: Success, capture TaskId
+```

package/skills/uipath-maestro-case/references/plugins/tasks/agent/impl-json.md

@@ -0,0 +1,66 @@
+# agent task — Implementation (Direct JSON Write)
+
+> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md).
+
+## Task JSON Shape
+
+```json
+{
+  "id": "tH3kLmNp9",
+  "type": "agent",
+  "displayName": "Classify Purchase Order",
+  "elementId": "Stage_aB3kL9-tH3kLmNp9",
+  "isRequired": true,
+  "shouldRunOnlyOnce": true,
+  "data": {
+    "name": "=bindings.bG0SraLpg",
+    "folderPath": "=bindings.bH1iJK2lm",
+    "inputs": [],
+    "outputs": []
+  }
+}
+```
+
+- `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
+
+## Procedure
+
+**Step 0 — Get inputs/outputs schema:**
+
+```bash
+uip maestro case tasks describe --type agent --id "<entityKey>" --output json
+# multi-element agents:
+uip maestro case tasks describe --type agent --id "<entityKey>" --element-id "<elementId>" --output json
+```
+
+Fallback: planning-captured schema from tasks.md. If unavailable, placeholder per [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+**Step 1 — Root-level bindings:**
+
+Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../../variables/bindings/impl-json.md) for the canonical 7-field shape (all required — omitting any causes Studio Web render failure). Per-task overrides:
+
+- `resource`: `"process"`
+- `resourceSubType`: `"Agent"`
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+
+Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
+
+**Step 2 — Write task:**
+
+1. Generate `id` (`t` + 8 chars) and `elementId` (`<stageId>-<taskId>`)
+2. Set `data.name` = `=bindings.<nameBindingId>`, `data.folderPath` = `=bindings.<folderPathBindingId>`
+3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
+
+   **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
+4. Append to target stage's `tasks[laneIndex][]`
+
+> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
+
+## Post-Write Verification
+
+- `type: "agent"`
+- `data.name` and `data.folderPath` start with `=bindings.`
+- the bindings array has 2 entries: `resource: "process"`, `resourceSubType: "Agent"`, `propertyAttribute` = `name` / `folderPath`
+- `data.inputs` and `data.outputs` populated (unless placeholder)
+- `id` captured in `id-map.json`

package/skills/uipath-maestro-case/references/plugins/tasks/agent/planning.md

@@ -0,0 +1,49 @@
+# agent task — Planning
+
+An AI agent task. Invokes a UiPath Agent by entityKey for reasoning, classification, extraction, or generative work.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes a task as `AGENT` — an AI agent that processes inputs and returns structured outputs. Use when the task requires reasoning or judgment rather than deterministic automation.
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `display-name` | Agent Reference "Name" | Shown in the UI |
+| `name` | Agent Reference "Name" |  |
+| `folder-path` | Agent Reference "Folder" |  |
+| `task-type-id` | Registry resolution (below) | Enables auto-enrichment via `tasks describe` |
+| `element-id` | (optional) | Required only when the agent has multiple element bindings |
+| `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
+| `outputs` | Discovered via `tasks describe` | For downstream cross-task references |
+| `runOnlyOnce` | sdd.md (default `true`) |  |
+| `isRequired` | sdd.md (default `true`) |  |
+
+## Registry Resolution
+
+1. **Primary cache file:** `agent-index.json`.
+2. **Identifier field:** `entityKey`.
+3. **Cross-type fallback.** Agents are occasionally registered in `processOrchestration-index.json` when wrapped in an agentic process — search both if the primary yields no match.
+4. **Match priority:** exact name + exact folder > exact name only.
+5. **Discover inputs/outputs** via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). For agents with multiple elements, also pass `--element-id` when invoking describe (see [case-commands.md § uip maestro case tasks](../../../case-commands.md)).
+
+## Unresolved Fallback
+
+Mark `<UNRESOLVED: agent "<name>" in folder "<folder>" not found in registry>`. Omit `inputs:` and `outputs:`; capture intended wiring in a fenced ```` ```text ```` code block (not `#` prefixed — it renders as markdown H1). Execution creates a placeholder task — see [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add agent task "<display-name>" to "<stage>"
+- taskTypeId: <entityKey>
+- folder-path: "<folder>"
+- inputs:
+  - <input_name> <- "<Stage>"."<Task>".<output>
+- outputs: <out1>, <out2>
+- runOnlyOnce: true
+- isRequired: true
+- order: after T<m>
+- lane: <n>  # FE layout; increment per task. Within `runs-sequentially` group, parallel members share a lane (semantic).
+- verify: Confirm Result: Success, capture TaskId
+```

package/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/impl-json.md

@@ -0,0 +1,64 @@
+# api-workflow task — Implementation (Direct JSON Write)
+
+> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md).
+
+## Task JSON Shape
+
+```json
+{
+  "id": "tK7nRs3Wp",
+  "type": "api-workflow",
+  "displayName": "Monitor Order Inbox",
+  "elementId": "Stage_aB3kL9-tK7nRs3Wp",
+  "isRequired": true,
+  "shouldRunOnlyOnce": true,
+  "data": {
+    "name": "=bindings.bG0SraLpg",
+    "folderPath": "=bindings.bH1iJK2lm",
+    "inputs": [],
+    "outputs": []
+  }
+}
+```
+
+- `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
+
+## Procedure
+
+**Step 0 — Get inputs/outputs schema:**
+
+```bash
+uip maestro case tasks describe --type api-workflow --id "<entityKey>" --output json
+```
+
+Fallback: planning-captured schema from tasks.md. If unavailable, placeholder per [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+**Step 1 — Root-level bindings:**
+
+Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../../variables/bindings/impl-json.md) for the canonical 7-field shape (all required — omitting any causes Studio Web render failure). Per-task overrides:
+
+- `resource`: `"process"`
+- `resourceSubType`: `"Api"`
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+
+Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
+
+**Step 2 — Write task:**
+
+1. Generate `id` (`t` + 8 chars) and `elementId` (`<stageId>-<taskId>`)
+2. Set `data.name` = `=bindings.<nameBindingId>`, `data.folderPath` = `=bindings.<folderPathBindingId>`
+3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
+
+   **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
+4. Append to target stage's `tasks[laneIndex][]`
+
+> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
+
+## Post-Write Verification
+
+- `type: "api-workflow"`
+- `data.name` and `data.folderPath` start with `=bindings.`
+- the bindings array has 2 entries: `resource: "process"`, `resourceSubType: "Api"`, `propertyAttribute` = `name` / `folderPath`
+- `data.inputs` and `data.outputs` populated (unless placeholder)
+- `id` captured in `id-map.json`

package/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/planning.md

@@ -0,0 +1,47 @@
+# api-workflow task — Planning
+
+An API Workflow (formerly "Coded Workflow") task. Invokes a UiPath API workflow by entityKey.
+
+## When to Use
+
+Pick this plugin when the sdd.md labels a task as `API_WORKFLOW` — typically a TypeScript / C# coded workflow that exposes an API-style interface.
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `display-name` | API Workflow Reference "Name" | |
+| `name` | API Workflow Reference "Name" |  |
+| `folder-path` | API Workflow Reference "Folder" |  |
+| `task-type-id` | Registry resolution (below) | `entityKey` in `api-index.json` |
+| `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
+| `outputs` | Discovered via `tasks describe` | |
+| `runOnlyOnce` | sdd.md (default `true`) | |
+| `isRequired` | sdd.md (default `true`) | |
+
+## Registry Resolution
+
+1. **Primary cache file:** `api-index.json`.
+2. **Identifier field:** `entityKey`.
+3. Match by exact name + folder.
+4. Discover inputs/outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
+
+## Unresolved Fallback
+
+Mark `<UNRESOLVED: api-workflow "<name>" in folder "<folder>" not found in api-index.json>`. Omit `inputs:` and `outputs:`; capture intended wiring in a fenced ```` ```text ```` code block (not `#` prefixed — it renders as markdown H1). Execution creates a placeholder task — see [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add api-workflow task "<display-name>" to "<stage>"
+- taskTypeId: <entityKey>
+- folder-path: "<folder>"
+- inputs:
+  - <input_name> = "<value>"
+- outputs: <out1>, <out2>
+- runOnlyOnce: true
+- isRequired: true
+- order: after T<m>
+- lane: <n>  # FE layout; increment per task. Within `runs-sequentially` group, parallel members share a lane (semantic).
+- verify: Confirm Result: Success, capture TaskId
+```