cprima
March 26, 2026, 11:50am
1
I’ve been working with AI coding agents (Claude Code) on UiPath automation projects and ran into two recurring friction points that I think affect a wider audience. I’ve filed issues in the officialGitHub - UiPath/skills: This is a repository of skills for interfacing UiPath capabilities to external developers. · GitHub repository and would appreciate community feedback before they get triaged.
opened 11:38AM - 26 Mar 26 UTC
The current approach in this skills repo — and in the wider community — relies o… n manually creating `.xaml` files, then extracting "golden" activity references from them. However, tooling built by power users or the community currently has no supported path to obtain structured activity metadata without either:
- Manually creating Studio projects with handcrafted `.xaml` files as reference
- Disassembling `.nupkg` assemblies (legally and ethically problematic)
- Scraping HTML documentation
## What we're asking for
A vendor-published, versioned activity metadata file per activity package. The minimum required fields, per activity:
- Package name and version
- Full CLR type name (e.g. `UiPath.UIAutomation.Activities.NTypeInto`)
- Display name and description
- Properties/arguments: name, direction (`In`/`Out`/`InOut`), data type, required/optional
- Enum values for constrained properties
This could be distributed:
- As a companion artifact in the NuGet package itself (e.g., `metadata.json` alongside the DLLs)
- As a separate lightweight NuGet package (`UiPath.*.Activities.Metadata`)
- Via a public API endpoint
## Who benefits
- This skills repo — enables `find-activities` and activity discovery commands to work accurately without a Studio instance
- Opens the path for a deterministic generator inside the skill to feed into the LLM — similar to how Marcelo Cruz is approaching this
- **Custom Workflow Analyzer rule authors** — today they must use reflection against loaded assemblies to discover activity properties
- Third-party tooling authors — IDE plugins, linters, validators, generators
- Community members building typed config systems, activity registries, or migration tools
The `references/activity-docs/` directory in this repo already demonstrates the demand: it contains curated per-activity markdown files for 25+ packages. A machine-readable upstream source would make that engineering effort unnecessary and keep metadata in sync with each package release.
Anyone building tooling around UiPath activity packages — custom Workflow Analyzer rules, generators, linters, IDE
If you’ve hit this wall while building Workflow Analyzer rules or any other tooling, a +1 or comment there would help.
opened 11:38AM - 26 Mar 26 UTC
LLM coding agents currently depend on two primitive mechanisms to modify XAML fi… les:
- Line-based inserts with a synthetic diff
- Finding a matching string position and inserting there
Common coding agent tooling (Node.js, Python) has no robust Windows Workflow Foundation port. This means agents working on UiPath XAML files are limited to fragile text operations with no structural awareness of the activity tree.
To make coding agents robust when building or editing UiPath workflows, a .NET tool is needed that natively works with WF and exposes a surface for an LLM to make surgical changes to the activity tree — receiving back a valid `.xaml` file.
## What we're asking for
A standalone tool that can perform **WF-aware** operations on XAML files — loading them through the WF/XAML object model rather than treating them as text.
Minimum useful operations, with inserts being the primary challenge (edits and deletes are far less common in code-generation workflows):
- `insert-activity` — insert a generated activity snippet after a named anchor (e.g. by `DisplayName`)
- `add-argument` — add a typed `InArgument`/`OutArgument` to a workflow's `x:Members`
- `add-variable` — add a typed `Variable<T>` to a named `Sequence`
- `add-namespace-import` — add an entry to `TextExpression.NamespacesForImplementation`
- `validate-and-save` — load, validate via WF stack, save with correct namespace preservation
## Why text patching is insufficient
UiPath XAML has several structural constraints that text-patching cannot enforce:
- `TextExpression.NamespacesForImplementation` allows exactly one child `<sco:Collection>` — inserting outside it causes a `XamlException` at load time
- `mc:Ignorable` lists prefix names literally — XML serialisers that rename prefixes (`sap` → `ns3`) invalidate it silently
- `sap2010:WorkflowViewState.IdRef` values must be unique per file — collision causes incorrect designer state
- Assembly reference containers differ between file types (`scg:List` vs `sco:Collection`)
## Scope
This is not a request for a full workflow designer or code generator. The minimum useful scope is: given a valid XAML file and a structured operation description (JSON), produce a valid modified XAML file and confirm it reloads correctly. CoreWF (maintained by UiPath) provides the WF runtime for .NET 6+ and would be the natural foundation.
AI coding agents work by inserting text at line positions or string anchors. That’s too fragile for UiPath XAML — the
Happy to discuss either in this thread. The main ask is: if these resonate with your own experience, weigh in on the
1 Like