Generate structured markdown documentation for UiPath XAML activities from source code. Produces per-activity docs with full properties (inputs, outputs, configuration), types, defaults, project settings, valid property combinations, and copy-paste XAML examples. Use when asked to document activities, generate activity docs, create activity reference files, build activity mini-skills, or prepare package documentation for any activity domain in this repository. Also use when the user mentions "activity reference", "activity cheat sheet", "activity docs", or wants to understand what an activity does as a black box. If the user also wants coded workflow API docs, use the `coded-api-doc-generator` skill for that separately.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Generate structured markdown documentation for UiPath XAML activities from source code. Produces per-activity docs with full properties (inputs, outputs, configuration), types, defaults, project settings, valid property combinations, and copy-paste XAML examples. Use when asked to document activities, generate activity docs, create activity reference files, build activity mini-skills, or prepare package documentation for any activity domain in this repository. Also use when the user mentions "activity reference", "activity cheat sheet", "activity docs", or wants to understand what an activity does as a black box. If the user also wants coded workflow API docs, use the `coded-api-doc-generator` skill for that separately.
Activity Doc Generator (XAML)
Generate structured markdown documentation for UiPath XAML activities. One file per activity, documenting every configurable property, default, output, project setting, valid property combinations, and a XAML example.
What These Docs Are For
UiPath activities are Windows Workflow Foundation (WF) components serialized as XAML. When an AI coding assistant needs to generate or modify a XAML workflow, it needs to know:
What properties each activity has (names, types, whether they're InArgument<T> expressions or plain XML attributes)
Which properties are required vs optional, and their defaults
Which property combinations are valid (some are mutually exclusive, some are conditionally visible)
What the activity outputs (OutArgument<T>) so downstream activities can consume them
The correct XML namespace prefix and attribute syntax
These docs serve as the contract specification that enables an AI agent to produce valid XAML. They are extracted into each UiPath Studio project for AI assistants to reference during workflow generation.
Core Principles
ViewModel is the source of truth — The ViewModel class defines what appears in the designer and what goes into the XAML. Properties, their visibility, ordering, categories, and display names all come from the ViewModel (following its inheritance chain). The activity class defines runtime behavior but the ViewModel controls the public contract.
Copy-paste ready — XAML snippets must be valid XML fragments that can be dropped into a workflow.
Valid configurations — Document which property combinations are valid. Not all properties can coexist; rules and dependencies in the ViewModel control visibility and mutual exclusion.
Source-of-truth extraction — All information comes from source code via the extraction script. Do not invent or guess behavior.
Outputs matter — Always document OutArgument/InOutArgument properties. These are how users get data back from activities.
Behavioral context when useful — While the focus is on the public contract, briefly noting how an activity works under the hood (e.g., "uses the Excel Interop library", "calls the Orchestrator REST API") helps AI agents understand when and why to use it.
Workflow: Script-First, Then Document
The process has two phases: automated extraction (deterministic script) followed by intelligent documentation (you). This avoids expensive manual grep/read cycles.
ActivitiesMetadata JSON — Discovers the activity catalog. Each entry provides fullName, viewModelType, mandatoryParent, browsable flag, and category. This is the authoritative list of activities in the package. Note: many packages split metadata into ActivitiesMetadata.json (cross-platform) and ActivitiesMetadataWindows.json (Windows-only). The script reads both — document platform availability when activities appear only in the Windows metadata.
Resource files (.resx) — Resolves all localized string keys to display strings (display names, descriptions, tooltips, categories).
ViewModel classes — The primary source for property extraction. ViewModels define DesignInArgument<T>, DesignOutArgument<T>, DesignProperty<T> with OrderIndex, IsVisible, Category, DisplayName, Tooltip, and Widget. Properties are extracted following the ViewModel's inheritance chain (base ViewModels may define shared properties like ContinueOnError, Timeout).
Activity classes — Supplements the ViewModel data with [RequiredArgument], [DefaultValue], [ArgumentSettingAttribute] (project settings), and [OverloadGroup] decorators. Also used to discover InArgument<T>/OutArgument<T> type information when the ViewModel doesn't expose it.
The script merges these sources and outputs structured JSON with all properties, types, defaults, display names, and descriptions.
Phase 2: Generate Documentation (You)
For each activity in the JSON output, generate a markdown doc using the template at assets/xaml-activity-template.md. The script gives you the raw data; your job is to add judgment:
Descriptions — If the script resolved a description, use it. If empty/missing, write a concise one based on the activity name and properties.
Valid property configurations — Read the ViewModel's InitializeRules() and ManualRegisterDependencies() to identify which properties are conditionally visible or mutually exclusive (see Rules and Dependencies below). Document valid configurations explicitly.
XAML examples — Craft valid XML fragments showing one or more valid property configurations. Not all properties can coexist — the example must reflect a valid combination.
Enum values — For enum-typed properties, find and list all values with descriptions.
Project settings — If isProjectSetting: true on any property, document in a dedicated section.
Outputs — Ensure every OutArgument/InOutArgument is documented with its type and what it returns.
Behavioral context — When the activity wraps a well-known library or API (e.g., Excel Interop, Orchestrator REST API, SMTP), briefly note this so the AI agent understands the activity's capabilities and limitations.
References (optional) — If an activity has supplementary reference files (detailed examples, extended guidance, complex scenarios) that would bloat the main doc, place them in a {ActivityClassName}/ subdirectory alongside the .md file and add a References section linking to them. Only include when such files exist.
Phase 3: Validate Generated Docs (Mandatory)
Before presenting docs as complete, run the validator script and fail the generation pass if any errors are reported.
Input — InArgument<T> and input-category plain properties. Required properties first.
Options/Configuration — Plain properties (bool, enum, string, int) in "Options" or other categories
Output — OutArgument<T> and InOutArgument<T> — the activity's results
Common — ContinueOnError, Timeout, DisplayName (when present)
Output Properties
Output properties are critical — they're how users get data back from activities:
Always include the property name and inner type (the T in OutArgument<T>)
Describe what the output contains
Note if the output is conditional (only populated in certain scenarios)
Project Settings
If any property has isProjectSetting: true in the script output, add:
## Project Settings
This activity reads default values from project-level settings (configurable in UiPath Studio under Project Settings):
| Property | Setting Key | Default | Description |
|----------|-----------|---------|-------------|
| `Endpoint` | `UiPath.Sdk.Activities.{Section}.{Property}` | `https://...` | The API endpoint URL |
These settings apply to all instances of the activity in a project, acting as configurable defaults.
Rules and Dependencies
The ViewModel defines rules that react to property value changes and dependencies that trigger those rules. These control which property combinations are valid. To extract them:
Find the ViewModel — The script output includes viewModelFile for each activity. Read that file.
Look for InitializeRules() — Rules define handlers (sync or async) that execute when properties change. Common patterns:
Conditional visibility: MyProperty.IsVisible = someCondition; — a property only appears when another property has a specific value
Mutual exclusion: Setting one property hides or disables another
Dynamic defaults: One property's default changes based on another
Look for ManualRegisterDependencies() — Maps which property changes trigger which rules via RegisterDependency(SourceProp, nameof(SourceProp.Value), "RuleName")
Look for [OverloadGroup] on the activity class — These define mutually exclusive property groups at the WF level (independent of ViewModel rules)
Document these as valid configurations in the activity doc:
## Valid Configurations
This activity supports two modes:
**Mode A — By Range**: Set `Range` to a cell reference. `SheetName` is optional (defaults to active sheet).
**Mode B — By Table**: Set `TableName` instead. `Range` and `SheetName` are ignored.
Properties `Range` and `TableName` are mutually exclusive.
When generating XAML examples, show at least one valid configuration. If there are multiple modes, show examples for each.
Step 4: Generate Overview
Create overview.md at the package level listing all documented activities by category, with links and one-line descriptions. See the overview template section in assets/xaml-activity-template.md.
Note if the package has activities in both cross-platform and Windows-only metadata files — group them accordingly in the overview.
Step 5: Place Output Files
Place docs inside the project that produces the published .nupkg — the one with a <PackageId> that is packable. This is NOT always the *.Package.csproj — some domains split into design-time and runtime packaging projects. Check <PackageId> and <IsPackable> to identify the correct project (see shared/output-structure.md for details and examples).
{PublishedPackageProject}/
docs/
overview.md # Package overview with activity index
activities/ # Per-activity docs
ActivityOne.md
ActivityOne/ # Optional reference files for ActivityOne
some-reference.md
ActivityTwo.md
...
Inform the user about the nuspec/csproj packaging change needed — do NOT modify packaging files unless asked.
Portable vs Windows Metadata
Many packages split their ActivitiesMetadata*.json into two files:
ActivitiesMetadata.json — Cross-platform (Portable) activities that work on both Windows and Linux
ActivitiesMetadataWindows.json — Windows-only activities (e.g., activities using Win32 APIs, COM interop, or desktop UI automation)
When documenting:
Note platform availability on Windows-only activities: "Platform: Windows only"
In the overview, group cross-platform and Windows-only activities separately if the package has both
The extraction script reads both files automatically
What NOT to Document
Abstract base classes — Not user-facing
Internal/private classes — Not part of public API
Designer/ViewModel classes — Use as metadata sources only
[NotMappedProperty] — UI-only, not part of activity contract
[Browsable(false)] — Unless functional (e.g., Body on scope activities)
Telemetry properties — Internal plumbing
Non-browsable metadata entries — "browsable": false in metadata JSON
Deprecated activities — Unless they are the only option (note as deprecated)
Quality Checklist
Every activity has a clear one-sentence description
ALL configurable properties are listed (InArgument, OutArgument, AND plain properties)
Output properties are always included with clear type and description
Properties come primarily from the ViewModel (following inheritance chain)
Properties are grouped by category (Input > Options > Output > Common)
[RequiredArgument] properties are marked as required
Types are accurate (from script extraction)
Enum types list their values
Default values are included
Valid property configurations are documented (rules, dependencies, OverloadGroups)
XAML example shows a valid property combination
Scope requirements are noted (mandatoryParentActivity)
Platform noted when Windows-only (from Windows metadata)
Project settings are documented when present ([ArgumentSettingAttribute])
References section included when supplementary files exist in {ActivityClassName}/ subdirectory
overview.md lists all activities with correct relative links
Validator passes with zero errors (validate-activity-docs.py --strict)
