Uipath Code Reviewer

UiPath Code Reviewer

Analyze UiPath automation code (XAML workflows and C# coded automations) for quality issues, best practices violations, and potential bugs. Generates structured, actionable fix suggestions that can be automatically implemented.

Official Documentation Reference

This skill aligns with UiPath's official Workflow Analyzer rules:

• UiPath Studio User Guide
• Workflow Analyzer
• Naming Rules
• Design Best Practices
• Security Rules
• Coded Automations Best Practices

When to Use

• "Review my UiPath code"
• "Check this workflow for issues"
• "Audit automation quality"
• "Find bugs in XAML"
• "Code review this automation"
• "What's wrong with this workflow?"
• "Improve my UiPath project"
• Before deploying to production
• After generating UiPath code with other skills

Quick Reference

Review Scope

Severity Levels

Core Workflow

┌─────────────────────────────────────────────────────────────────┐
│  CODE REVIEW WORKFLOW                                           │
│                                                                 │
│  1. LOCATE FILES ──> 2. ANALYZE ──> 3. GENERATE REPORT         │
│     *.xaml, *.cs       Run checks     review-report.md          │
│     project.json       by category                              │
│                                                                 │
│  4. CREATE FIXES ──> 5. (OPTIONAL) APPLY                       │
│     fix-suggestions.json   Auto-implement                       │
└─────────────────────────────────────────────────────────────────┘

Step 1: Locate UiPath Project Files

Search for files to review:

# Project configuration
**/project.json

# XAML workflows
**/*.xaml

# Coded automations
**/*.cs

# Config files
**/Config.xlsx
**/appsettings.json

Step 2: Analyze Each File

For each file type, run the appropriate checks:

XAML Analysis Checklist

• Namespace declarations - All required namespaces present
• Variable naming - Follows convention (camelCase with type prefix)
• Argument naming - Follows convention (in_/out_/io_ prefix)
• DisplayName - All activities have meaningful DisplayNames
• Error handling - Try-Catch blocks around risky operations
• Logging - Appropriate LogMessage activities
• Selectors - Dynamic, not hardcoded; use wildcards appropriately
• Hardcoded values - No hardcoded credentials or paths
• Activity configuration - Timeouts, delays configured properly
• Workflow complexity - Not too many nested levels

C# Analysis Checklist

• Namespace organization - Proper using statements
• Argument attributes - Correct Direction attributes
• Exception handling - Try-catch with proper exception types
• Logging - Log() calls at appropriate points
• Resource cleanup - Using statements or proper disposal
• Code complexity - Methods not too long
• LINQ usage - Efficient queries, no N+1 patterns

Project Configuration Checklist

• Dependencies - Correct versions, no conflicts
• Entry points - Properly defined
• Runtime options - Appropriate for project type
• Target framework - Compatible with deployment environment

Step 3: Generate Review Report

Create a structured report with all findings.

Step 4: Create Fix Suggestions

Generate machine-readable fix suggestions for each issue.

Step 5: (Optional) Apply Fixes

Use the fix suggestions to automatically implement corrections.

UiPath Workflow Analyzer Rule Mapping

This skill checks rules that align with UiPath's built-in Workflow Analyzer. Here's the mapping:

Official UiPath Naming Rules (ST-NMG-*)

Official UiPath Design Best Practices (ST-DBP-*)

Official UiPath Maintainability Rules (ST-MRD-*)

Official UiPath Usage Rules (ST-USG-*)

Official UiPath Security Rules (ST-SEC-*)

Official UiPath Performance Rules (ST-PRR-*)

Additional Custom Rules (Beyond Workflow Analyzer)

This skill also includes rules not covered by the built-in Workflow Analyzer:

Review Rules Reference

Naming Convention Rules

RULE-001: Variable Naming Convention

Severity: Medium
Category: Naming

Variables should use camelCase with a type prefix.

Bad Examples:

<Variable x:TypeArguments="x:String" Name="filename" />
<Variable x:TypeArguments="x:Int32" Name="Counter" />
<Variable x:TypeArguments="sd:DataTable" Name="data" />

Good Examples:

<Variable x:TypeArguments="x:String" Name="strFileName" />
<Variable x:TypeArguments="x:Int32" Name="intCounter" />
<Variable x:TypeArguments="sd:DataTable" Name="dtData" />

RULE-002: Argument Naming Convention

Severity: Medium
Category: Naming

Arguments should use direction prefix followed by PascalCase.

Bad Examples:

<x:Property Name="FilePath" Type="InArgument(x:String)" />
<x:Property Name="result" Type="OutArgument(x:String)" />

Good Examples:

<x:Property Name="in_FilePath" Type="InArgument(x:String)" />
<x:Property Name="out_Result" Type="OutArgument(x:String)" />

RULE-003: Workflow File Naming

Severity: Low
Category: Naming

Workflow files should use PascalCase and describe their purpose.

Bad Examples:

• process_data.xaml
• workflow1.xaml
• test.xaml

Good Examples:

• ProcessTransaction.xaml
• InitAllSettings.xaml
• GetTransactionData.xaml

RULE-004: Activity DisplayName

Severity: Medium
Category: Naming

All activities should have descriptive DisplayNames.

Bad Examples:

<Assign DisplayName="Assign">
<ui:LogMessage DisplayName="Log Message">
<If DisplayName="If">

Good Examples:

<Assign DisplayName="Set Transaction Status">
<ui:LogMessage DisplayName="Log Process Start">
<If DisplayName="Check If File Exists">

Error Handling Rules

RULE-010: Missing Try-Catch

Severity: High
Category: Error Handling

Critical operations should be wrapped in Try-Catch blocks.

Critical operations include:

• HTTP requests
• Database operations
• File I/O
• Excel operations
• UI automation
• External API calls

Bad Example:

<Sequence DisplayName="Process Data">
  <ui:HttpClient Endpoint="[apiUrl]" Response="[response]" />
  <ui:ExcelWriteRange DataTable="[dtData]" />
</Sequence>

Good Example:

<TryCatch DisplayName="Process Data with Error Handling">
  <TryCatch.Try>
    <Sequence>
      <ui:HttpClient Endpoint="[apiUrl]" Response="[response]" />
      <ui:ExcelWriteRange DataTable="[dtData]" />
    </Sequence>
  </TryCatch.Try>
  <TryCatch.Catches>
    <Catch x:TypeArguments="s:Exception">
      <ActivityAction x:TypeArguments="s:Exception">
        <ActivityAction.Argument>
          <DelegateInArgument x:TypeArguments="s:Exception" Name="exception" />
        </ActivityAction.Argument>
        <ui:LogMessage Level="Error" Message="[exception.Message]" />
      </ActivityAction>
    </Catch>
  </TryCatch.Catches>
</TryCatch>

RULE-011: Empty Catch Block

Severity: Critical
Category: Error Handling

Catch blocks should not be empty - they must log or handle the exception.

Bad Example:

<TryCatch.Catches>
  <Catch x:TypeArguments="s:Exception">
    <ActivityAction x:TypeArguments="s:Exception">
      <ActivityAction.Argument>
        <DelegateInArgument x:TypeArguments="s:Exception" Name="exception" />
      </ActivityAction.Argument>
      <!-- Empty! -->
    </ActivityAction>
  </Catch>
</TryCatch.Catches>

Good Example:

<TryCatch.Catches>
  <Catch x:TypeArguments="s:Exception">
    <ActivityAction x:TypeArguments="s:Exception">
      <ActivityAction.Argument>
        <DelegateInArgument x:TypeArguments="s:Exception" Name="exception" />
      </ActivityAction.Argument>
      <Sequence>
        <ui:LogMessage Level="Error" Message="[&quot;Error: &quot; + exception.Message]" />
        <Rethrow />
      </Sequence>
    </ActivityAction>
  </Catch>
</TryCatch.Catches>

RULE-012: Generic Exception Only

Severity: Medium
Category: Error Handling

Catch specific exception types before generic Exception.

Bad Example:

<TryCatch.Catches>
  <Catch x:TypeArguments="s:Exception">
    <!-- Only catches generic Exception -->
  </Catch>
</TryCatch.Catches>

Good Example:

<TryCatch.Catches>
  <Catch x:TypeArguments="ui:BusinessRuleException">
    <!-- Handle business errors -->
  </Catch>
  <Catch x:TypeArguments="s:TimeoutException">
    <!-- Handle timeouts -->
  </Catch>
  <Catch x:TypeArguments="s:Exception">
    <!-- Handle everything else -->
  </Catch>
</TryCatch.Catches>

RULE-013: Missing Retry Logic

Severity: Medium
Category: Error Handling

Transient operations (HTTP, UI) should use RetryScope.

Bad Example:

<ui:Click Target="[selector]" />

Good Example:

<ui:RetryScope NumberOfRetries="3" RetryInterval="00:00:02">
  <ui:RetryScope.ActivityBody>
    <ActivityAction>
      <ui:Click Target="[selector]" />
    </ActivityAction>
  </ui:RetryScope.ActivityBody>
</ui:RetryScope>

Security Rules

RULE-020: Hardcoded Credentials

Severity: Critical
Category: Security

Never hardcode passwords, API keys, or secrets.

Bad Example:

<Assign DisplayName="Set Password">
  <Assign.To><OutArgument x:TypeArguments="x:String">[strPassword]</OutArgument></Assign.To>
  <Assign.Value><InArgument x:TypeArguments="x:String">["MySecretPassword123!"]</InArgument></Assign.Value>
</Assign>

Good Example:

<ui:GetRobotCredential CredentialAssetName="SystemCredential" 
  Username="[strUsername]" Password="[secPassword]" />

RULE-021: Hardcoded File Paths

Severity: High
Category: Security/Maintainability

Avoid hardcoded absolute paths - use config or relative paths.

Bad Example:

<ui:ReadTextFile FileName="C:\Users\John\Documents\input.txt" />

Good Example:

<ui:ReadTextFile FileName="[in_ConfigPath + &quot;\input.txt&quot;]" />

RULE-022: Sensitive Data in Logs

Severity: Critical
Category: Security

Never log passwords, tokens, or PII.

Bad Example:

<ui:LogMessage Level="Info" Message="[&quot;Password: &quot; + strPassword]" />

Good Example:

<ui:LogMessage Level="Info" Message="Authentication successful" />

RULE-023: Missing Secure String

Severity: High
Category: Security

Passwords should use SecureString, not String.

Bad Example:

<Variable x:TypeArguments="x:String" Name="strPassword" />

Good Example:

<Variable x:TypeArguments="s:Security.SecureString" Name="secPassword" />

Performance Rules

RULE-030: Excessive Delays

Severity: Medium
Category: Performance

Avoid hardcoded delays - use element waits instead.

Bad Example:

<Delay Duration="[TimeSpan.FromSeconds(10)]" DisplayName="Wait for page" />
<ui:Click Target="[selector]" />

Good Example:

<ui:WaitElementVanish Target="[loadingSelector]" Timeout="30000" />
<ui:Click Target="[selector]" />

RULE-031: Inefficient Loop

Severity: Medium
Category: Performance

Use LINQ instead of loops for DataTable filtering.

Bad Example:

<ForEach x:TypeArguments="sd:DataRow" Values="[dtData.Rows]">
  <If Condition="[row(&quot;Status&quot;).ToString = &quot;Active&quot;]">
    <!-- Process -->
  </If>
</ForEach>

Good Example:

<Assign DisplayName="Filter Active Rows">
  <Assign.To><OutArgument x:TypeArguments="sd:DataTable">[dtFiltered]</OutArgument></Assign.To>
  <Assign.Value><InArgument x:TypeArguments="sd:DataTable">[dtData.AsEnumerable().Where(Function(r) r(&quot;Status&quot;).ToString = &quot;Active&quot;).CopyToDataTable()]</InArgument></Assign.Value>
</Assign>

RULE-032: Missing Timeout

Severity: High
Category: Performance

UI activities should have explicit timeouts.

Bad Example:

<ui:Click Target="[selector]" />

Good Example:

<ui:Click Target="[selector]" Timeout="30000" />

RULE-033: Selector Too Specific

Severity: Medium
Category: Performance/Maintainability

Selectors should not include volatile attributes.

Bad Example:

<ui:Target Selector="&lt;html title='Page - Session 12345'/&gt;&lt;webctrl idx='3'/&gt;" />

Good Example:

<ui:Target Selector="&lt;html title='Page*'/&gt;&lt;webctrl tag='BUTTON' id='submit'/&gt;" />

Maintainability Rules

RULE-040: Workflow Too Complex

Severity: Medium
Category: Maintainability

Workflows should not exceed recommended complexity limits.

RULE-041: Missing Documentation

Severity: Low
Category: Maintainability

Workflows should have annotations explaining purpose.

Bad Example:

<Sequence DisplayName="Main">
  <!-- No annotation -->
</Sequence>

Good Example:

<Sequence DisplayName="Main">
  <sap2010:Annotation.AnnotationText>
    Main entry point for invoice processing.
    Input: in_InvoicePath - Path to invoice PDF
    Output: out_ProcessingResult - Success/Failure status
  </sap2010:Annotation.AnnotationText>
</Sequence>

RULE-042: Duplicate Code

Severity: Medium
Category: Maintainability

Similar code blocks should be extracted to reusable workflows.

RULE-043: Magic Numbers

Severity: Low
Category: Maintainability

Use named constants or config values instead of magic numbers.

Bad Example:

<If Condition="[intAmount > 10000]">

Good Example:

<If Condition="[intAmount > Config(&quot;ApprovalThreshold&quot;)]">

Best Practice Rules

RULE-050: Missing Logging

Severity: Medium
Category: Best Practices

Key workflow stages should have log messages.

Required logging points:

• Workflow start
• Workflow end
• Before/after external calls
• Exception handling
• Business decisions

RULE-051: Inconsistent Activity Naming

Severity: Low
Category: Best Practices

Activity DisplayNames should follow a consistent pattern.

Recommended patterns:

• Verb + Object: "Read Config File", "Process Transaction"
• Check + Condition: "Check If Valid", "Check File Exists"
• Set + Variable: "Set Status", "Set Counter"

RULE-052: Missing Input Validation

Severity: High
Category: Best Practices

Input arguments should be validated at workflow start.

Bad Example:

<Sequence DisplayName="Process File">
  <ui:ReadTextFile FileName="[in_FilePath]" />
</Sequence>

Good Example:

<Sequence DisplayName="Process File">
  <If Condition="[String.IsNullOrEmpty(in_FilePath)]">
    <If.Then>
      <Throw>
        <Throw.Exception>
          <InArgument x:TypeArguments="s:Exception">[New ArgumentException(&quot;in_FilePath is required&quot;)]</InArgument>
        </Throw.Exception>
      </Throw>
    </If.Then>
  </If>
  <ui:PathExists Path="[in_FilePath]" Exists="[boolExists]" />
  <If Condition="[Not boolExists]">
    <If.Then>
      <Throw>
        <Throw.Exception>
          <InArgument x:TypeArguments="s:Exception">[New FileNotFoundException(&quot;File not found: &quot; + in_FilePath)]</InArgument>
        </Throw.Exception>
      </Throw>
    </If.Then>
  </If>
  <ui:ReadTextFile FileName="[in_FilePath]" />
</Sequence>

RULE-053: HTTP Without Error Check

Severity: High
Category: Best Practices

HTTP responses should check status code before processing.

Bad Example:

<ui:HttpClient Endpoint="[apiUrl]" Response="[response]" />
<ui:DeserializeJson JsonString="[response]" JsonObject="[joResult]" />

Good Example:

<ui:HttpClient Endpoint="[apiUrl]" Response="[response]" StatusCode="[statusCode]" />
<If Condition="[statusCode &lt;&gt; 200]">
  <If.Then>
    <Throw>
      <Throw.Exception>
        <InArgument x:TypeArguments="s:Exception">[New Exception(&quot;API call failed: &quot; + statusCode.ToString)]</InArgument>
      </Throw.Exception>
    </Throw>
  </If.Then>
</If>
<ui:DeserializeJson JsonString="[response]" JsonObject="[joResult]" />

Output Formats

Review Report Format (review-report.md)

# UiPath Code Review Report

**Project**: {ProjectName}
**Date**: {ReviewDate}
**Reviewer**: AI Code Reviewer

## Summary

| Severity | Count |
|----------|-------|
| Critical | {count} |
| High | {count} |
| Medium | {count} |
| Low | {count} |
| Info | {count} |

## Findings

### Critical Issues

#### [RULE-020] Hardcoded Credentials in Main.xaml

**File**: Main.xaml
**Line**: 45
**Description**: Password is hardcoded in plain text
**Impact**: Security vulnerability - credentials exposed in source code
**Fix**: Use Orchestrator Credential Asset

**Current Code**:
```xml
<Assign DisplayName="Set Password">
  <Assign.Value><InArgument x:TypeArguments="x:String">["MyPassword123"]</InArgument></Assign.Value>
</Assign>

Suggested Fix:

<ui:GetRobotCredential CredentialAssetName="SystemCredential" 
  Username="[strUsername]" Password="[secPassword]" />

High Issues

...

Medium Issues

...

### Fix Suggestions Format (fix-suggestions.json)

```json
{
  "projectName": "InvoiceProcessor",
  "reviewDate": "2026-02-24",
  "totalIssues": 12,
  "fixes": [
    {
      "id": "FIX-001",
      "ruleId": "RULE-001",
      "severity": "medium",
      "file": "Main.xaml",
      "line": 23,
      "description": "Variable 'filename' should use naming convention",
      "currentCode": "<Variable x:TypeArguments=\"x:String\" Name=\"filename\" />",
      "suggestedCode": "<Variable x:TypeArguments=\"x:String\" Name=\"strFileName\" />",
      "autoFixable": true,
      "searchPattern": "Name=\"filename\"",
      "replacePattern": "Name=\"strFileName\""
    },
    {
      "id": "FIX-002",
      "ruleId": "RULE-010",
      "severity": "high",
      "file": "ProcessData.xaml",
      "line": 45,
      "description": "HTTP request missing Try-Catch",
      "currentCode": "<ui:HttpClient Endpoint=\"[apiUrl]\" />",
      "suggestedCode": "<!-- See full suggestion in review-report.md -->",
      "autoFixable": false,
      "manualSteps": [
        "Wrap the HTTP activity in a TryCatch",
        "Add appropriate Catch blocks",
        "Add logging in catch block"
      ]
    }
  ]
}

Usage Examples

Basic Review

User: Review my UiPath project at C:\Projects\InvoiceProcessor

AI: I'll analyze your UiPath project for code quality issues.

[Reads project.json, Main.xaml, and all workflow files]
[Applies all review rules]
[Generates review-report.md and fix-suggestions.json]

Found 12 issues:
- 2 Critical (hardcoded credentials, empty catch block)
- 3 High (missing try-catch, no input validation)
- 5 Medium (naming conventions, missing timeouts)
- 2 Low (missing annotations)

See review-report.md for details and fix suggestions.

Review with Auto-Fix

User: Review and fix the naming convention issues in my workflow

AI: I'll review and automatically fix naming convention violations.

[Analyzes code]
[Identifies 8 naming issues]
[Applies auto-fixes for variables and arguments]

Fixed 8 naming issues:
- filename → strFileName
- counter → intCounter
- FilePath → in_FilePath
- result → out_Result
...

Review Specific File

User: Check ProcessTransaction.xaml for error handling issues

AI: I'll focus on error handling in ProcessTransaction.xaml.

[Analyzes error handling patterns]
[Checks try-catch coverage]
[Validates exception handling]

Found 3 error handling issues:
1. Line 34: HTTP request without Try-Catch (High)
2. Line 67: Empty catch block (Critical)
3. Line 89: Missing retry logic for UI automation (Medium)

Integration with Other Skills

Post-Generation Review

After using uipath-automation or coded-workflow-builder skills:

1. Generate workflow with uipath-automation skill
2. Run uipath-code-reviewer on generated code
3. Apply fixes from fix-suggestions.json
4. Re-run review to confirm all issues resolved

Pre-Deployment Checklist

Before deploying to Orchestrator:

1. Run full code review
2. Ensure no Critical or High issues
3. Document any accepted Medium/Low issues
4. Generate review-report.md for audit trail

Quality Checklist

Before completing a code review:

• All XAML files analyzed
• All C# files analyzed (if coded automation)
• project.json validated
• All rule categories checked
• Review report generated
• Fix suggestions created
• Auto-fixable issues identified
• Manual fix steps documented

Reference Documentation

Shared References

• Error Handling - Error handling patterns
• Logging Standards - Logging best practices
• Project Configuration - project.json structure

Code Reviewer References

• Review Rules Catalog - Complete list of all rules
• XAML Patterns - Good vs bad XAML patterns
• C# Patterns - Good vs bad C# patterns
• Auto-Fix Guide - How to apply automatic fixes