/uipath-rules

name: uipath-rules
description: "UiPath Business Rules — `.dmn` decision tables (DMN 1.5, FEEL) in a BusinessRules project (`project.uiproj`), built with `uip rules` (`init`, `refresh`, `validate`, `debug`). Author, edit, review, validate, and debug a rule's decision table from a policy, spreadsheet, or description; list and describe deployed rules. For .bpmn business rule tasks->uipath-maestro-bpmn. For EvaluateBusinessRule in .xaml->uipath-rpa. For caseplan.case/caseplan.json business rule tasks->uipath-maestro-case. For solution pack/publish/deploy->uipath-solution."
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion

UiPath Business Rules

A Business Rules project holds one DMN decision table. DMN and FEEL follow the OMG standard; this skill covers only what UiPath accepts on top of it.

When to Use This Skill

• Create a business rule (decision table) from a policy, spreadsheet, or description
• Edit the rows, columns, or hit policy of a `.dmn` in a BusinessRules project
• Validate or debug a rule that returns the wrong output
• List deployed rules or read a deployed rule's inputs and outputs

Critical Rules

1. **Write DMN 1.5.** Use the MODEL and DMNDI namespaces `https://www.omg.org/spec/DMN/20230324/...` and DC/DI `http://www.omg.org/spec/DMN/20180521/...`. When editing a file on an older DMN version, rewrite it to these namespaces. 2. **One `.dmn` per project.** `rules debug` evaluates only the project's first `.dmn`. 3. **One decision per file, and its logic is a decision table.** When the user asks for chained decisions, a decision requirements diagram, business knowledge models, or a literal expression, say authoring them is not supported yet, then offer to flatten the logic into one table or to create one rules project per decision and let the calling process chain them. Never write the unsupported element. 4. **No DOCTYPE, XML comments, or processing instructions.** Put notes in the annotation column or a `<description>` element. 5. **Use the designer's types.** `string`, `number`, `boolean`, `Any`, `date`, `time`, `date and time`, `dayTimeDuration`, `yearMonthDuration`, for both columns and input arguments. <!--skill-flavor:lifecycle-rules:start--> 6. **Scaffold a new project with `init`; after every edit, `refresh` then `validate`.** An existing project needs no `init`: edit its `.dmn` and run `refresh`. Fix what `validate` reports. Never hand-write or delete `project.uiproj`, `entry-points.json`, or `bindings_v2.json`; keep the scaffolded `.dmn` file and its root element. 7. **A rule is done when `validate` passes and `debug` returns what the reviewed table expects.** On a wrong output, read the trace with `uip traces spans get <Data.traceId>`. Stop after 3 fix rounds and show the user the table and the failing inputs. <!--skill-flavor:lifecycle-rules:end--> 8. **Stop on a tenant without Business Rules, and publish through `uip solution`.** When `rules debug` fails with `Business Rules is not enabled on tenant '<TENANT>'.`, stop and relay the CLI's instruction. Pack, publish, and deploy belong to the uipath-solution skill. 9. **Name every rule.** Declare one `<annotation name="Annotation" />` after the table's last `<output>`, then give each `<rule>` one `<annotationEntry>` with a short name for the case it covers; the review table's Annotation column is what goes there. Never write an `<annotationEntry>` without that column.

Quick Start

1. Scaffold (new projects only)

<!--skill-flavor:scaffold:start-->

uip rules init <RULE_NAME> --output json

Run `init` from the solution folder when one exists; outside a solution it creates `<RULE_NAME>Solution/<RULE_NAME>/`. `Data.RuleStatus: "Preserved"` means the project already held a `.dmn` and `init` left it untouched. The rule is the one `.dmn` file in the project folder. Treat whatever table the scaffolded `.dmn` holds as a placeholder; step 3 replaces it. <!--skill-flavor:scaffold:end-->

2. Design and review

Show the table as Markdown before authoring and after each change. Ask only what the request leaves open, in one question; ask nothing when told not to pause.

**Hit policy:** FIRST

| # | creditScore (number) | income (number) | riskBand (string) | Annotation |
|---|---|---|---|---|
| 1 | < 580 | - | "High" | Subprime |
| 2 | [580..700) | >= 50000 | "Medium" | Near-prime, sufficient income |
| 3 | - | - | "Low" | Default |

3. Author the table

Replace the scaffolded table with the reviewed design.

4. Refresh and validate

uip rules refresh <PROJECT_DIR> --output json
uip rules validate <PROJECT_DIR> --output json

Fix every error in `Data.Diagnostics`, then run both again.

5. Verify

<!--skill-flavor:verify:start-->

uip rules debug <PROJECT_DIR> --inputs '<INPUTS_JSON>' --output json

`--inputs` takes one JSON object keyed by input-argument name, or `@<FILE>`. Compare `Data.result.decisions[].outputs` with the expected values. The run failed when `debug` exits 1 (`Result: Failure`); the decision and input errors are in `Data.result`, the summary code in `Data.error`. On a mismatch, read the trace:

uip traces spans get <TRACE_ID> --output json

`<TRACE_ID>` is `Data.traceId`. The trace shows which rules fired. `Data.traceId` is present only when tracing is on for the tenant (the default); without it, compare the inputs against each row by hand. `rules debug` needs the project directly inside its solution folder, as `init` creates it, and a logged-in user (`uip login`). `debug` uploads the whole solution folder and overwrites its Studio Web solution; pull Studio Web edits first. <!--skill-flavor:verify:end-->

Editing an Existing Rule

• Keep the decision's `id` and `name` and the `.dmn` file name. Consumers bind to the entry point `/<file>.dmn#<decisionId>`, and renaming either points them at an entry point that no longer exists.
• Change only what the request names; every other row keeps its