@uipath/skills 1.195.0

package/skills/uipath-rpa/references/xaml/csharp-activity-binding-guide.md

@@ -0,0 +1,120 @@
+# C# Activity Binding Guide
+
+**Scope:** XAML workflow files in projects whose `project.json` has `expressionLanguage: CSharp`. The canonical binding forms below describe how to write XAML expressions — they do **not** apply to VB XAML projects (use `[bracket]` shorthand there) and they do **not** apply to coded workflows (`.cs` files), which are plain C# and do not involve `CSharpValue` / `CSharpReference` elements at all.
+
+Use this as a quick lookup before writing or editing XAML in a C#-expression project.
+
+## Rule of thumb
+
+For any activity property typed `InArgument<T>` or `OutArgument<T>`:
+- **Literal value with a direct type converter** (string literal on `<String>`, enum, number, boolean, `TimeSpan`, `{x:Null}`) → attribute form is safe.
+- **Anything non-literal** (variable reference, concatenation, method call, property access) → use the child-element form with `<CSharpValue>` (read) or `<CSharpReference>` (write).
+
+The XAML attribute parser defaults to VB for expression-bearing attribute values, **regardless of the project's expression language**. At runtime, the VB JIT is disabled on non-Legacy projects — so attribute-form expressions fail with `JIT compilation is disabled for non-Legacy projects`. See [csharp-expression-pitfalls.md](csharp-expression-pitfalls.md).
+
+## Property-surface sourcing
+
+Which properties exist on a given activity, the `<Activity>.md` lookup order, and how to handle `Cannot set unknown member` errors caused by property-name drift between package versions: see [xaml-basics-and-rules.md § Activity Property Surface](xaml-basics-and-rules.md#activity-property-surface-and-starter-xaml). Check [../common-activity-card.md](../common-activity-card.md) first for card-listed activities; for those, the card is the property surface and the binding tables below describe how to convert its VB snippets to C#. For off-card activities, follow the full Rule 21 workflow before applying these binding forms.
+
+## Binding forms by property type
+
+| Property type | Attribute form (literal only) | Child-element form (expression) |
+|---|---|---|
+| `InArgument<String>` | Literal: `Foo="hello"` | `<InArgument x:TypeArguments="x:String"><CSharpValue x:TypeArguments="x:String">expr</CSharpValue></InArgument>` |
+| `InArgument<Object>` | Not safe — `Object` has no direct type converter | `<InArgument x:TypeArguments="x:Object"><CSharpValue x:TypeArguments="x:Object">expr</CSharpValue></InArgument>` |
+| `InArgument<Boolean>` | Literal: `Foo="True"` | `<InArgument x:TypeArguments="x:Boolean"><CSharpValue x:TypeArguments="x:Boolean">a &gt; b</CSharpValue></InArgument>` |
+| `InArgument<Int32>` / numeric | Literal: `Timeout="30"` | `<InArgument x:TypeArguments="x:Int32"><CSharpValue x:TypeArguments="x:Int32">expr</CSharpValue></InArgument>` |
+| `InArgument<TimeSpan>` | Literal: `Duration="00:00:02"` — never bracket form | Rare |
+| `InArgument<TEnum>` | Literal: `Level="Info"`, `MouseButton="Left"` | Rare |
+| `OutArgument<T>` | Often rejected — use child element | `<OutArgument x:TypeArguments="x:String"><CSharpReference x:TypeArguments="x:String">var</CSharpReference></OutArgument>` |
+| Plain `string` (not `InArgument<String>`) | Literal: `WorkflowFileName="path.xaml"` | — |
+| Complex objects (`TargetAnchorable`, `ActivityAction`, dictionaries) | — | Always child element |
+
+**Type-class mistakes:**
+
+- `InArgument<Object>` (e.g. `LogMessage.Message`) — writing `<InArgument x:TypeArguments="x:String">` instead of `x:Object` fails validation.
+- `OutArgument<T>` writeback — attribute form (`Result="[var]"`) fails with `Failed to create a '<Prop>' from the text '...'`. Use child element with `<CSharpReference>`.
+- `OutArgument` / `InOutArgument` on `InvokeWorkflowFile.Arguments` — must be a variable reference (lvalue), not a constructed expression. See [§ OutArgument Bindings Must Be Variable References](common-pitfalls.md#outargument-bindings-must-be-variable-references).
+- Empty `<InArgument x:TypeArguments="x:String"></InArgument>` — passes per-file `validate` but fails project `analyze` with `Value for a required activity argument 'Value' was not supplied`. Use `[String.Empty]`. See [§ Empty Argument Values](common-pitfalls.md#empty-argument-values).
+- Plain `string` (e.g. `InvokeWorkflowFile.WorkflowFileName`) — wrap in `[brackets]` or `&quot;...&quot;` and Studio silently breaks path resolution. Use the literal path. See [§ WorkflowFileName Must Be a Plain String Path](common-pitfalls.md#workflowfilename-must-be-a-plain-string-path).
+
+## Recipes
+
+### LogMessage with a C# expression
+
+```xml
+<ui:LogMessage DisplayName="Log status" Level="Info">
+  <ui:LogMessage.Message>
+    <InArgument x:TypeArguments="x:Object">
+      <CSharpValue x:TypeArguments="x:Object">"Todo count now: " + statusText</CSharpValue>
+    </InArgument>
+  </ui:LogMessage.Message>
+</ui:LogMessage>
+```
+
+**Common mistake:** `<InArgument x:TypeArguments="x:String">` — `Message` is `Object`, not `String`. `x:Object` is required.
+
+### Get Text → variable
+
+```xml
+<uix:NGetText DisplayName="Read status" HealingAgentBehavior="SameAsCard">
+  <uix:NGetText.Target>
+    <uix:TargetAnchorable .../>
+  </uix:NGetText.Target>
+  <uix:NGetText.TextString>
+    <OutArgument x:TypeArguments="x:String">
+      <CSharpReference x:TypeArguments="x:String">statusText</CSharpReference>
+    </OutArgument>
+  </uix:NGetText.TextString>
+</uix:NGetText>
+```
+
+**Scoping requirement:** when `NGetText` sits inside `<uix:NApplicationCard.Body><ActivityAction><Sequence>`, the `statusText` variable must be declared on that inner `Sequence.Variables`, not on an outer one crossing the `ActivityAction` boundary — otherwise runtime throws `ThrowIfNotInTree`. See [csharp-expression-pitfalls.md](csharp-expression-pitfalls.md#throwifnotintree--variable-declared-outside-the-activityaction-scope).
+
+### Assign with a C# expression
+
+```xml
+<Assign DisplayName="Compose message">
+  <Assign.To>
+    <OutArgument x:TypeArguments="x:String">
+      <CSharpReference x:TypeArguments="x:String">logMessage</CSharpReference>
+    </OutArgument>
+  </Assign.To>
+  <Assign.Value>
+    <InArgument x:TypeArguments="x:String">
+      <CSharpValue x:TypeArguments="x:String">"Added: " + todoText</CSharpValue>
+    </InArgument>
+  </Assign.Value>
+</Assign>
+```
+
+### StartProcess with a composed path
+
+```xml
+<ui:StartProcess DisplayName="Start server">
+  <ui:StartProcess.FileName>
+    <InArgument x:TypeArguments="x:String">
+      <CSharpValue x:TypeArguments="x:String">System.Environment.GetEnvironmentVariable("LOCALAPPDATA") + @"\MyApp\start.cmd"</CSharpValue>
+    </InArgument>
+  </ui:StartProcess.FileName>
+</ui:StartProcess>
+```
+
+### If with a boolean expression
+
+```xml
+<If DisplayName="Check count">
+  <If.Condition>
+    <InArgument x:TypeArguments="x:Boolean">
+      <CSharpValue x:TypeArguments="x:Boolean">count &gt; 0</CSharpValue>
+    </InArgument>
+  </If.Condition>
+  <If.Then>
+    <Sequence>
+      <!-- ... -->
+    </Sequence>
+  </If.Then>
+</If>
+```
+
+> **XAML escaping:** `<`, `>`, `&`, `"` must be escaped inside `<CSharpValue>` element content (`&lt;`, `&gt;`, `&amp;`, `&quot;`).

package/skills/uipath-rpa/references/xaml/csharp-expression-pitfalls.md

@@ -0,0 +1,38 @@
+# C# Expression Pitfalls
+
+**Scope:** XAML workflow files in projects whose `project.json` has `expressionLanguage: CSharp`. These rules govern how XAML expressions are authored — they do **not** apply to VB XAML projects, and they do **not** apply to coded workflows (`.cs` files with `[Workflow]` / `[TestCase]`). Coded workflows are plain C# — none of the `CSharpValue` / `CSharpReference` / attribute-form rules below are relevant there.
+
+Failure modes in scope: all pass static `validate` validation — they only surface at `CacheMetadata` time under `uip rpa build` or `uip rpa run`.
+
+For the canonical binding form per property, see [csharp-activity-binding-guide.md](csharp-activity-binding-guide.md).
+
+## Attribute-form expressions fail at runtime
+
+Any non-literal attribute value on an `InArgument<T>` / `OutArgument<T>` property (e.g. `Message="logMessage"`, `TextString="statusText"`) is deserialized as `VisualBasicValue<T>` by the XAML attribute parser — regardless of the project's `expressionLanguage`. On non-Legacy projects the VB JIT is disabled, so these fail at runtime:
+
+```
+System.InvalidOperationException: JIT compilation is disabled for non-Legacy projects.
+ExpressionToCompile { Code = "logMessage" ... } should have been compiled by the Studio Compiler.
+```
+
+**Fix:** use `<CSharpValue>` (read) or `<CSharpReference>` (write) child-element form for anything non-literal.
+
+**Attribute form is safe for:** literal strings on `InArgument<String>`, enums, numbers, booleans, `TimeSpan` literals, `{x:Null}` — values with a direct type converter that bypasses the expression parser.
+
+## `OutArgument<T>` attribute form fails at parse time
+
+`<uix:NGetText TextString="statusText"/>` raises `Failed to create a 'TextString' from the text 'statusText'` — `TextString` is `OutArgument<String>`, not a plain property, so the XAML parser has no converter for it. Always use the `<OutArgument>` + `<CSharpReference>` child form for output bindings.
+
+## `ThrowIfNotInTree` — variable declared outside the `ActivityAction` scope
+
+`OutArgument<T>` + `<CSharpReference>` bound to a variable declared on a `Sequence` **outside** the `ActivityAction` body passes validation but throws at runtime:
+
+```
+System.InvalidOperationException: The argument of type 'System.String' cannot be used.
+Make sure that it is declared on an activity.
+  at System.Activities.Argument.ThrowIfNotInTree()
+```
+
+**Typical case:** a UI activity inside `<uix:NApplicationCard.Body><ActivityAction><Sequence>` writes an output to a variable declared on the *outer* `Sequence` rather than the inner one.
+
+**Fix:** declare the variable on the `Sequence.Variables` immediately inside the `ActivityAction`, not on a parent `Sequence` outside it.

package/skills/uipath-rpa/references/xaml/jit-custom-types-schema.md

@@ -0,0 +1,90 @@
+# JIT Custom Types Schema Lookup
+
+Use this skill to discover properties and CLR types of custom JIT-compiled types in the current project.
+
+## When to Use
+
+- Populating an `Assign` activity that targets a custom type property
+- Creating a variable typed to a custom entity
+- Setting properties on an Integration Service entity (e.g., Salesforce, ServiceNow)
+- Any time you need to know what properties a custom type exposes and their .NET types
+
+## Steps
+
+### 1. Read the Schema File
+
+Use the `Read` tool to read the JIT custom types schema:
+
+```
+Read: file_path="{projectRoot}/.project/JitCustomTypesSchema.json"
+```
+
+### 2. Navigate the JSON Structure
+
+The file has the following structure:
+
+```json
+{
+  "jitAssemblyCompilerCommands": [
+    {
+      "bundleOptions": {
+        "entitiesBundle": {
+          "Types": {
+            "<TypeName>": {
+              "properties": [
+                {
+                  "name": "<PropertyName>",
+                  "type": {
+                    "ClrType": "<FullClrTypeString>"
+                  }
+                }
+              ]
+            }
+          }
+        }
+      }
+    }
+  ]
+}
+```
+
+Key path: `jitAssemblyCompilerCommands[*].bundleOptions.entitiesBundle.Types`
+
+Each entry under `Types` is keyed by the fully-qualified type name. Each type contains a `properties` array where each property has:
+- `name` - the property name (e.g., `AccountId`, `Name`, `Amount`)
+- `type.ClrType` - the full .NET CLR type string
+
+### 3. Map CLR Types to Short Forms
+
+Convert the verbose CLR type strings to usable short forms:
+
+| Full CLR Type | Short Form |
+|---------------|------------|
+| `System.String, System.Private.CoreLib` | `String` |
+| `System.Int32, System.Private.CoreLib` | `Int32` |
+| `System.Int64, System.Private.CoreLib` | `Int64` |
+| `System.Double, System.Private.CoreLib` | `Double` |
+| `System.Boolean, System.Private.CoreLib` | `Boolean` |
+| `System.DateTime, System.Private.CoreLib` | `DateTime` |
+| `System.DateTimeOffset, System.Private.CoreLib` | `DateTimeOffset` |
+| `System.Decimal, System.Private.CoreLib` | `Decimal` |
+| `System.Guid, System.Private.CoreLib` | `Guid` |
+| ``System.Nullable`1[[System.Double, ...]]`` | `Double?` |
+| ``System.Nullable`1[[System.Int32, ...]]`` | `Int32?` |
+| ``System.Nullable`1[[System.Boolean, ...]]`` | `Boolean?` |
+| ``System.Nullable`1[[System.DateTime, ...]]`` | `DateTime?` |
+| ``System.Nullable`1[[System.DateTimeOffset, ...]]`` | `DateTimeOffset?` |
+
+**General rules:**
+- For simple types: extract the type name before the first comma (e.g., `System.String` becomes `String`)
+- For `Nullable` types: extract the inner type name and append `?`
+- For collection types (e.g., `System.Collections.Generic.List`1[...]`): use **arrays** in XAML — short form `InnerType[]` (e.g., `Int32[]`). In XAML use `x:TypeArguments="s:Int32[]"`; in expressions use array literals (e.g., VB `New Integer() {1, 2, 3}`, C# `new int[] { 1, 2, 3 }`).
+
+### 4. Apply to Workflow
+
+Use the discovered property names and their simplified types when:
+- Writing XAML `Assign` activities: set the correct property path and value type
+- Declaring variables: use the correct CLR type annotation
+- Building `InvokeCode` or coded workflow expressions that reference custom type properties
+- Declaring arguments in the workflow: use the correct CLR type for In/Out/InOut arguments that hold custom types
+- Configuring an `InvokeWorkflow` activity: map arguments whose types are custom entities so types match the callee workflow

package/skills/uipath-rpa/references/xaml/workflow-guide.md

@@ -0,0 +1,258 @@
+# XAML Workflow Guide
+
+Discovery-first approach with iterative error-driven refinement for generating and editing XAML workflows. Always understand before acting, start simple, and validate continuously.
+
+## Core Principles
+
+1. **Activity Docs Are the Source of Truth** — Installed packages may ship structured documentation at `{projectRoot}/.local/docs/packages/{PackageId}/`. When present, these docs contain source-accurate properties, types, defaults, enum values, conditional property groups, and working XAML examples. Always check for them first.
+2. **Know Before You Write** — **NEVER** generate XAML blind. Understand the project structure, packages, expression language, and existing patterns.
+3. **Use What You Know, Skip What You Don't Need** — If you already know the package ID and activity class name, go directly to its doc file. Be efficient: the discovery steps are a priority ladder, not a mandatory checklist.
+4. **Start Minimal, Iterate to Correct** — Start one workflow at a time and break out logic into multiple files if needed. Build one activity at a time within each workflow. Write the smallest working XAML, validate with `uip rpa validate`, fix what breaks, repeat.
+5. **Validate After Every Change** — **MUST** validate with **both** `validate` and `uip rpa build` after every change. **NEVER** assume an edit succeeded. `validate` clean alone is not validated — it does not catch unknown member names or invalid enum values; `build` does.
+6. **Fix Errors by Category** — Triage in order: Package → Structure → Type → Activity Properties → Logic.
+
+---
+
+## Core Workflow: Classify Request
+
+| Request Type | Trigger Words | Action |
+|--------------|---------------|--------|
+| **CREATE** | "generate", "create", "make", "build", "new" | Discovery → Generate |
+| **EDIT** | "update", "change", "fix", "modify", "add to" | Discovery → Edit |
+
+If unclear which file to edit, **ask the user** rather than guessing.
+
+---
+
+## Phase 1: Discovery
+
+**Goal:** Understand project context, leverage installed activity documentation, study existing patterns, identify reusable components, and discover activities before writing any XAML.
+
+> **Batch discovery across activities.** When the workflow needs several activities, do NOT run the find → read-doc → `get-default-xaml` triple one activity at a time. Emit all `activities find` calls in parallel, then all `<Activity>.md` `Read`s in parallel, then all `get-default-xaml` calls in parallel (SKILL.md § Call Batching). Only the per-activity *authoring + validate* loop (Phase 2 / Phase 3) stays sequential — discovery fans out.
+
+### Step 1.1: Project Structure
+
+```
+Glob: pattern="**/*.xaml" path="{projectRoot}"       → list all XAML workflow files
+Read: file_path="{projectRoot}/project.json"          → read the project definition
+```
+
+Analyze:
+- Where should new workflows be placed? (folder conventions)
+- What naming pattern is used?
+- What similar workflows already exist?
+- VB or C# syntax? (check `expressionLanguage` in `project.json`)
+- What packages are already installed?
+- Are there existing connections, credentials, or objects to reuse?
+
+### Step 1.2: Discover Activity Documentation (Primary Source)
+
+**This is the most important discovery step. Read `<Activity>.md` BEFORE `activities get-default-xaml`, every time, even for activities that look simple.** Installed activity packages ship structured markdown at `{projectRoot}/.local/docs/packages/{PackageId}/activities/<Activity>.md`. The doc is the property surface; the CLI starter is not. `activities get-default-xaml` strips every property at its type default — for `NGetText` that means **all** output properties are absent from the starter, and authoring from the starter produces `NGetText.Value="..."` instead of `NGetText.Text="..."`. `validate` does not catch the wrong member name; only `build` does, after a wasted round-trip.
+
+**Availability:** Docs exist only for **installed packages** and typically only for **newer package versions**. When the package is not installed, install it first. When docs are missing, update to the latest version, or fall back to `skills/uipath-rpa/references/activity-docs/<PackageId>/<closest-version>/`.
+
+#### Filesystem Structure
+
+```
+{projectRoot}/.local/docs/packages/
++-- {PackageId}/
+    +-- overview.md
+    +-- activities/
+    |   +-- {ActivitySimpleClassName}.md
+    +-- coded/                             # Ignore for XAML workflows
+```
+
+#### Activity Doc Template
+
+Every `activities/{ActivityName}.md` follows: Header → Metadata → Properties (Input, Output, Conditional groups, Common) → Valid Configurations → Enum Reference → XAML Examples → Notes.
+
+#### Decision Table
+
+| Situation | Action |
+|-----------|--------|
+| **Know package + activity name** | `Read: file_path="{projectRoot}/.local/docs/packages/{PackageId}/activities/{ActivityName}.md"` |
+| **Know package, not activity** | `Read` the `overview.md`, then read the identified activity doc |
+| **Don't know package** | `Glob` with `**/*.md` in `{projectRoot}/.local/docs/packages/`. `.local/` is gitignored — use `Glob` + `Read`, not `Grep` |
+| **Docs exist but activity undocumented** | Use other docs as structural reference, fall back to `activities get-default-xaml` |
+| **No docs for package** | Update the package first — this often adds docs. **Caution:** major version jumps (e.g., 23.x → 26.x) may deprecate activities — prefer minor/patch updates. If still no docs, fall back to Steps 1.4-1.7 |
+| **Package not installed** | Install it first — both docs and `activities get-default-xaml` require it |
+| **No `.local/docs/` at all** | Use fallback flow starting at Step 1.3 |
+
+### Step 1.3: Search Current Project
+
+Search existing workflows for reusable patterns and conventions.
+
+```
+Glob: pattern="**/*pattern*.xaml" path="{projectRoot}"
+Grep: pattern="ActivityName|pattern" path="{projectRoot}"
+Read: file_path="{projectRoot}/ExistingWorkflow.xaml"
+```
+
+- **Mature project**: Prioritize local patterns.
+- **Greenfield project**: Skip this step.
+
+### Step 1.4: Discover Activities (When Needed)
+
+Use when you need to find which activity implements a user-described action:
+
+```bash
+uip rpa activities find --query "send mail" --limit 10 --output json```
+```
+
+- Results are **global** — not limited to installed packages
+- If a useful activity is in an uninstalled package, install it immediately
+- Tags can narrow results further
+
+### Step 1.5: Disambiguate Approach and Provider
+
+#### Approach-level (API vs UI Automation vs Connector)
+
+- **Auto-select** when the user stated the approach or only one is viable
+- **Prompt** when multiple approaches are viable and user hasn't indicated preference
+- **Do NOT install packages until approach is confirmed**
+
+#### Provider-level (within an approach)
+
+**Auto-select** when: user specified provider, only one package matches, project already has the package installed, project defines a matching connection, or workflow already uses activities from one package.
+
+**Prompt only as last resort** — present top 2-4 choices with recommendations.
+
+### Step 1.6: Resolve Activity Properties (Fallback)
+
+Use `uip rpa activities get-default-xaml` when activity docs are insufficient:
+
+```bash
+# Non-dynamic activity:
+uip rpa activities get-default-xaml --activity-class-name "<FULLY_QUALIFIED_CLASS>" --output json
+# Dynamic activity (connector-backed):
+uip rpa activities get-default-xaml --activity-type-id "<TYPE_ID>" --connection-id "<CONN_ID>" --output json```
+
+For JIT custom types: `Read: file_path="{projectRoot}/.project/JitCustomTypesSchema.json"`. See [jit-custom-types-schema.md](jit-custom-types-schema.md).
+
+### Step 1.7: Search Examples Repository
+
+Use when activity docs, `activities find`, and `activities get-default-xaml` don't provide enough context:
+
+```bash
+uip rpa workflow-examples list --tags web --limit 10 --output json
+uip rpa workflow-examples get --key "<BLOB_PATH>"
+```
+
+**Complete tag list:** `adobe-sign`, `asana`, `box`, `concur`, `confluence`, `database`, `document-understanding`, `docusign`, `dropbox`, `email-generic`, `excel`, `excel-online`, `freshbooks`, `freshdesk`, `github`, `gmail`, `google-calendar`, `google-docs`, `google-drive`, `google-sheets`, `gsuite`, `hubspot`, `intacct`, `jira`, `mailchimp`, `marketo`, `microsoft-365`, `onedrive`, `outlook`, `outlook-calendar`, `pdf`, `powerpoint`, `productivity`, `quickbooks`, `salesforce`, `servicenow`, `sharepoint`, `shopify`, `slack`, `smartsheet`, `stripe`, `teams`, `testing`, `trello`, `web`, `webex`, `word`, `workday`, `zendesk`, `zoom`
+```
+
+### Step 1.8: Get Current Context (As Needed)
+
+```
+Read: file_path="{projectRoot}/project.json"
+Glob: pattern="**/*" path="{projectRoot}/.objects/"
+Bash: uip is connections list --output json
+```
+
+### Step 1.9: Discover Connector Capabilities (For IS/Connector Workflows)
+
+For end-to-end authoring of `ConnectorActivity` XAML (connection + type ID + Configuration blob + FieldObjects), see **[../is-connector-xaml-guide.md](../is-connector-xaml-guide.md)** — worked example included. For the discovery commands only (list connectors, describe operation, manage connections), see [../connector-capabilities.md](../connector-capabilities.md).
+
+**Path selection for calling connectors from XAML:**
+
+| Option | When to use |
+|--------|-------------|
+| **IS generic `ConnectorActivity`** with a typed operation typeId (e.g. `37a305b2-...` for Slack "Send Message to Channel") | **Default choice** — schema-driven, hand-authorable with the CLI flow below. Works via `UiPath.IntegrationService.Activities`. |
+| **IS generic `ConnectorActivity`** with `ConnectorHttpActivity` typeId (e.g. `...httpRequest...`) | Fallback for endpoints the connector hasn't modeled as a first-class operation. Field names are still connector-defined — not `method`/`path`/`body`. Read the schema. |
+| **Per-product BAF activity package** (`UiPath.Slack.Activities`, `UiPath.Salesforce.Activities`, etc.) | Avoid for headless authoring. These wrap IS internally but use a more complex BAF XAML shape (`ScopeActivity` + dynamic child activity with `BusinessEntity`, `SelectedFields`, `PopulatedAPIParameters`). Same complexity, less mechanical. Skill users should default to the generic `ConnectorActivity` path unless the project already uses the BAF package. |
+
+---
+
+## Phase 2: Generate or Edit
+
+### UI Automation — Target Configuration Gate (MANDATORY)
+
+Before writing any XAML with UI activities: [ui-automation-guide.md](../ui-automation-guide.md) MUST be read IN FULL first. Every UI element target MUST be configured through the `uia-configure-target` skill flow — [uia-configure-target-workflows.md](../uia-configure-target-workflows.md) MUST be read IN FULL first.
+
+**NEVER** manually call low-level `uip rpa uia` CLI commands outside of the skill flow.
+
+### For CREATE Requests
+
+**Strategy:** Generate minimal working version, one activity at a time, validate frequently.
+
+Use the `Write` tool to create a new `.xaml` file. Refer to [xaml-basics-and-rules.md](xaml-basics-and-rules.md) for the complete XAML file anatomy template.
+
+```
+Write: file_path="{projectRoot}/Workflows/DescriptiveName.xaml"
+       content=<valid XAML content>
+```
+
+**File path inference:** Use folder conventions from project structure, create descriptive filenames, ensure `.xaml` extension.
+
+### For EDIT Requests
+
+**Strategy:** Always read current content before editing.
+
+```
+Read: file_path="{projectRoot}/WorkflowToEdit.xaml"
+Edit: file_path=... old_string=<exact text> new_string=<modified text>
+```
+
+**Critical:** `old_string` must match exactly and be unique. Include surrounding context if needed.
+
+---
+
+## Phase 3: Validate & Fix Loop
+
+**MUST** repeat until 0-error state from **both** `validate` and `build`, or max 5 fix attempts. After 5 attempts, stop and present remaining errors to the user.
+
+### Step 3.1: Check for Errors
+
+Run both validators per iteration. `validate` catches structural / reference / analyzer issues; `build` catches member-name and enum-value mistakes that `validate` misses (e.g. `NGetText.Value` when the property is `Text`, `Operator="StartsWith"` when the enum has no such member). See [../validation-guide.md § Validation Iteration Loop](../validation-guide.md#validation-iteration-loop) for the canonical loop.
+
+```bash
+uip rpa validate --file-path "Workflows/MyWorkflow.xaml" --output json
+uip rpa build "<PROJECT_DIR>" --log-level Warn --output json
+```
+
+`--file-path` must be **relative to the project directory**. Use `--skip-validation` only for quick cached-error checks. Treat `validate` clean as half-done — `build` clean is the signal to exit the loop.
+
+### Step 3.2: Categorize and Fix
+
+**Fix order:** Package → Structure → Type → Activity Properties → Logic.
+
+1. **Package Errors** — Install/update the package. After install, activity docs become available.
+2. **Structural Errors** — Fix XML structure. Cross-check against [xaml-basics-and-rules.md](xaml-basics-and-rules.md).
+3. **Type Errors** — Check activity doc for correct types and enum values. For JIT types: [jit-custom-types-schema.md](jit-custom-types-schema.md).
+4. **Activity Properties Errors** — Read activity doc for properties, conditional groups, valid configurations. Fallback: `activities get-default-xaml`. Watch for OverloadGroup conflicts.
+5. **Logic Errors** — Verify expression syntax matches project language. For UI automation: use `debug start`; [ui-automation-guide.md](../ui-automation-guide.md) MUST be read IN FULL first (see § Running UI Automation Workflows for the debug procedure).
+
+**When stuck:** Defer to user for minor config details. If failing to resolve an activity, consider InvokeCode as a last resort.
+
+For detailed procedures, see [../validation-guide.md](../validation-guide.md).
+
+---
+
+## Phase 4: Response
+
+1. **File path** of created/edited workflow
+2. **Brief description** of what the workflow does
+3. **Key activities** and logic implemented
+4. **Packages installed** (if any)
+5. **Limitations** or notes
+6. **Suggested next steps** (testing, parameterization)
+7. **Encourage user to review and customize** (fill placeholders, set up connections)
+
+---
+
+## Anti-Patterns
+
+- **NEVER** generate large, complex workflows in one go
+- **NEVER** manually craft UI selectors outside of `uia-configure-target` skill flow
+- **NEVER** assume a create/edit succeeded without validating with **both** `validate` and `build`
+- **NEVER** treat "no diagnostics found" from `validate` as final — run `build` next; member-name and enum-value errors hide behind a clean `validate`
+- **NEVER** stop the iteration loop before correctly rendering all activities
+- **NEVER** guess properties, types, or configurations without checking docs
+- **NEVER** use incorrect keys with `uip rpa workflow-examples get` (always from list results)
+- **NEVER** pass absolute paths to `--file-path` in `validate` (must be relative)
+- **NEVER** ask user to choose provider without checking project signals first
+- **NEVER** retry failing CLI commands in a loop without diagnosing root cause
+- **NEVER** skip Phase 0 (Studio readiness)
+- **NEVER** use connector activities without checking connection existence
+- **NEVER** ignore activity doc conditional property groups (OverloadGroup conflicts cause validation errors)
+- **NEVER** generate full XAML from scratch without using `activities get-default-xaml` as a starting point