@uipath/skills 1.204.0-preview.1174 → 1.204.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uipath/skills",
-  "version": "1.204.0-preview.1174",
+  "version": "1.204.0",
   "description": "UiPath agent skills for Claude Code, Codex, Cursor, Copilot, Gemini and OpenCode — RPA, UI automation, UI testing, coded agents/apps/workflows, and troubleshooting. Distributed as the UiPath Claude Code plugin.",
   "author": {
     "name": "UiPath"

package/skills/uipath-planner/SKILL.md

@@ -167,6 +167,7 @@ High-level view of what each specialist owns. **Do not describe internal flows o
 | [Case Design Lane Guide](references/case/case-design-lane-guide.md) | The case design conversation — entry, tenant grounding, authoring policy, the one Case Review, and the write |
 | [Case Design Layers Guide](references/case/case-design-layers-guide.md) | The case model and every design **Default** — skeleton (triggers, stages, the ten task types), gates (lifecycle rules, exits, sequencing, secondary lanes), data (variables, outputs, expressions), time (SLAs, escalations, responses), naming rules, and the closure checklist |
 | [PDD Analysis Guide](references/pdd-analysis-guide.md) | How to extract structured data from PDDs in any format |
+| [Business Rules Guide](references/business-rules-guide.md) | Validation vs decision vs reasoning rules; DMN-style decision tables; reasoning list. Load when filling RPA §4 or BPMN §5. |
 | [Product Selection Guide](references/product-selection-guide.md) | **Constraint Gate** (delivery model + exclusions filter), **Level 1** (primary scope), **Level 1.75** (Solution composition), **Level 2.5 Part B** (cross-product project list merge), **Level 3** (capability add-ons), template mapping |
 | [Platform Availability Guide](references/platform-availability-guide.md) | Product × delivery-model availability matrix (Cloud / Automation Suite / standalone), alternatives for blocked products, verification rule for uncertain cells. Load whenever the Constraint Gate runs — every delivery model: "Cloud is not uniform", variants (GovCloud / Dedicated / Test Cloud) and per-tenant entitlements can block products inside the Cloud column. |
 | [RPA Product Guide](references/rpa-product-guide.md) | RPA **Level 1.5** (sub-type), **Level 2** (authoring mode), **Level 2.5 Part A** (RPA decomposition), R-07 naming, REFramework. Load when Level 1 = RPA or a Solution includes RPA. |

package/skills/uipath-planner/assets/templates/bpmn-sdd-template.md

@@ -191,6 +191,28 @@ flowchart LR
 |---|---|---|---|---|
 | `<FLOW_KEY>` | `<SOURCE_NODE>` | `<TARGET_NODE>` | <EXPRESSION_OR_—> | <NOTES> |
 
+### Decision Tables
+
+<!-- references/business-rules-guide.md → Decision tables. Each decision runs in a businessRuleTask (§4); gateways route on its output. Validation rules go in §7. Empty: `None. No rule decides an outcome.` -->
+
+#### D1 — <DECISION_NAME>
+**Hit policy:** <UNIQUE / FIRST / COLLECT>
+**Inputs:** `<INPUT_NAME>` (<string / number / boolean / date>), …
+**Output:** `<OUTPUT_NAME>` (<TYPE_AND_ALLOWED_VALUES>)
+**Runs in:** `<BUSINESS_RULE_TASK_NODE_KEY>`
+
+| # | <INPUT_NAME> | <INPUT_NAME> | → <OUTPUT_NAME> | Rule |
+|---|---|---|---|---|
+| 1 | <ENTRY> | <ENTRY> | <OUTPUT> | <BR_ID> |
+
+### Rules That Need Reasoning
+
+<!-- references/business-rules-guide.md → Rules that need reasoning. Agent: a serviceTask hosting the agent. Person: a userTask, also in §9 HITL Touchpoints. Empty: `None. Every rule is deterministic.` -->
+
+| ID | Rule | Applied by | Inputs → Output | Where it runs |
+|---|---|---|---|---|
+| <BR_ID> | <RULE> | <Agent / Person> | <INPUTS> → <OUTPUT> | `<NODE_KEY>` |
+
 ---
 
 ## 6. Events
@@ -207,7 +229,7 @@ flowchart LR
 
 ## 7. Data Objects & Variables
 
-<!-- Process variables and data objects passed between nodes. -->
+<!-- Process variables and data objects passed between nodes. A validation business rule (regex / range / type / allowed values) goes in Description, prefixed with its BR ID. -->
 
 | Name | Direction | Type | Scope | Default | Description |
 |---|---|---|---|---|---|

package/skills/uipath-planner/assets/templates/rpa-sdd-template.md

@@ -200,10 +200,33 @@ flowchart TD
 >    - **Allowed values** (enum-shaped) when the PDD lists a closed set (e.g., `{ "Approved", "Rejected", "Pending" }`)
 > 4. **Tie BR rows to test oracles.** Every validation BR with a concrete example in §17 Canonical Test Case becomes a test assertion. Use the canonical input/output values from Phase 1 extraction — do NOT invent.
 > 5. **Embedded rules count.** A PDD that says "the hash must be 40 lowercase hex chars" is a BR even though the PDD has no dedicated Business Rules section.
+> 6. **Classify every rule before tabling it.** This table holds validation rules only; decision rules and reasoning rules fill the two subsections below. Classification, homes and the coverage check: [Business Rules Guide](../../references/business-rules-guide.md).
 
 | ID | Rule Name | Description | Trigger Condition | Validation (regex / range / type / allowed values) | Affected Steps |
 |---|---|---|---|---|---|
-| BR-01 | <RULE_NAME> | <DESCRIPTION> | <WHEN_DOES_IT_APPLY> | <REGEX_OR_RANGE_OR_TYPE_OR_ENUM_— `n/a` ONLY if the rule is purely behavioural> | <STEP_NUMBERS> |
+| BR-01 | <RULE_NAME> | <DESCRIPTION> | <WHEN_DOES_IT_APPLY> | <REGEX_OR_RANGE_OR_TYPE_OR_ENUM> | <STEP_NUMBERS> |
+
+### Decision Tables
+
+<!-- references/business-rules-guide.md → Decision tables. Runs in: the step and its coded logic or lookup. Empty: `None. No rule decides an outcome.` -->
+
+#### D1 — <DECISION_NAME>
+**Hit policy:** <UNIQUE / FIRST / COLLECT>
+**Inputs:** `<INPUT_NAME>` (<string / number / boolean / date>), …
+**Output:** `<OUTPUT_NAME>` (<TYPE_AND_ALLOWED_VALUES>)
+**Runs in:** <STEP_NUMBER_AND_LOGIC>
+
+| # | <INPUT_NAME> | <INPUT_NAME> | → <OUTPUT_NAME> | Rule |
+|---|---|---|---|---|
+| 1 | <ENTRY> | <ENTRY> | <OUTPUT> | <BR_ID> |
+
+### Rules That Need Reasoning
+
+<!-- references/business-rules-guide.md → Rules that need reasoning. A person applies it through Action Center. Empty: `None. Every rule is deterministic.` -->
+
+| ID | Rule | Applied by | Inputs → Output | Where it runs |
+|---|---|---|---|---|
+| <BR_ID> | <RULE> | <Agent / Person> | <INPUTS> → <OUTPUT> | <WHERE_IT_RUNS> |
 
 ---
 

package/skills/uipath-planner/references/business-rules-guide.md

@@ -0,0 +1,84 @@
+# Business Rules Guide
+
+Business rules in an SDD: validation rules, DMN-style decision tables, and rules that need reasoning.
+
+## 1. Classify every rule
+
+| Type | Test | Lands in |
+|---|---|---|
+| **Deterministic: validation** | Checks a value's form: regex, range, type, allowed values. | RPA §4 validation table; BPMN §7 Data Objects & Variables |
+| **Deterministic: decision** | Explicit logic over structured data decides an outcome: thresholds, lists, lookups, dates, calculations. The same inputs always give the same output. | A decision table ([Decision tables](#2-decision-tables)) |
+| **Reasoning: agent** | It takes interpretation or unstructured input (free text, a document, a judgment call), and an agent can apply it from its inputs. | The reasoning list ([Rules that need reasoning](#3-rules-that-need-reasoning)), applied by an agent |
+| **Reasoning: person** | It needs a person's authority or accountability, or knowledge the inputs don't carry. | The reasoning list, applied by a person (HITL) |
+
+- **Take the type from the PDD.** A PDD may type each rule in its Business Rules table (`Deterministic`, `Reasoning: agent`, `Reasoning: person`, possibly in the document's language) and give its inputs and output as `inputs → output`. Keep that type. Never move a `Reasoning: person` rule to an agent on your own: that is an `[SME REVIEW]` item.
+- **Classify untyped rules with the test above.** When agent or person is unclear, choose person and raise an `[SME REVIEW]` item.
+- **Extraction is a separate step.** A rule on an amount read from an email is still deterministic once the amount is extracted. The extraction (IXP, agent) is a step of its own; the rule is a decision table over its output.
+- **One rule, one outcome.** Split a PDD rule that decides two things before tabling it. Tiers ("under 1,000 … up to 10,000 … above") are rows of one decision table.
+
+## 2. Decision tables
+
+One decision per output decided from the same inputs: one table, one row per rule or tier, numbered `D1`, `D2`, … Example:
+
+```markdown
+#### D1 — Approval route
+**Hit policy:** UNIQUE
+**Inputs:** `invoiceAmount` (number), `vendorStatus` (string: "new", "active", "blocked")
+**Output:** `approvalRoute` (string: "auto", "manager", "director", "reject")
+**Runs in:** <RUNS_IN>
+
+| # | invoiceAmount | vendorStatus | → approvalRoute | Rule |
+|---|---|---|---|---|
+| 1 | - | "blocked" | "reject" | BR-02 |
+| 2 | < 1000 | "active" | "auto" | BR-03 |
+| 3 | [1000..10000) | not("blocked") | "manager" | BR-04 |
+| 4 | >= 10000 | not("blocked") | "director" | BR-05 |
+| 5 | < 1000 | "new" | "manager" | BR-06 |
+```
+
+Cells (FEEL unary-test subset):
+
+| Cell | Meaning |
+|---|---|
+| `-` | Any value |
+| `"active"`, `42`, `true` | Equals |
+| `< 1000`, `>= 10000` | Comparison |
+| `[1000..10000)` | Range; `[` `]` include the bound, `(` `)` exclude it |
+| `"Gold", "Silver"` | Any of these |
+| `not("blocked")` | Anything except these |
+| `date("<CUTOFF_DATE>")`, `< date("<CUTOFF_DATE>")` | Dates, written ISO 8601 `YYYY-MM-DD` |
+
+- **Types** are `string`, `number`, `boolean` or `date`. Name inputs and outputs in camelCase, as the solution's variables or arguments name them. A string input or output lists its allowed values.
+- **Outputs** are literals, or a simple expression over the inputs (`invoiceAmount * 0.02`).
+- **Hit policy.** `UNIQUE` (default): exactly one row matches any input, so rows must not overlap. `FIRST`: rows are checked in order and the first match wins; use it only when the order is the rule. `COLLECT`: every matching row applies, for example a list of checks.
+- **Complete.** Aim for every combination of inputs to match a row. Under `UNIQUE`, cover the remaining combinations with rows of their own (`not(...)`, open ranges), because an all-`-` row would overlap every other row. A last all-`-` default row is valid only under `FIRST`, where order makes it the fallback.
+- **Design intent, not proof.** Hit policy and completeness describe what the table must do. Do not certify a table overlap-free or complete by reading it: the build proves it (see Proof).
+- **Traceable.** Every row cites its BR in `Rule`; a row that only completes the table cites `[DEFAULT]` or `[SME REVIEW]` instead. Every decision BR appears in at least one row.
+- **Independent test cases.** Write one test case per row in the Testing Strategy (RPA §17; BPMN §13 Gateway / Branch Coverage). Take its inputs and expected output from a PDD example or an SME-confirmed value, never from the row itself: a case derived from the row passes even when the row is wrong. When neither source gives one, write the case with `[SME REVIEW]` in place of the expected output.
+- **Proof.** The implementation task that hosts the decision (the BPMN or RPA task) lists its test cases in its `Validate` sub-step ([Plan and Tasks Format](plan-and-tasks-format.md)) and proves the table with tools. For a `.dmn` business rule: `uip rules validate <PROJECT_DIR> --output json`, then `uip rules debug <PROJECT_DIR> --inputs '<INPUTS_JSON>' --output json` once per test case. For coded logic in an RPA process: one unit test per test case. A failing case is a defect in the row or in the test case's source; resolve it with the SME, never by editing the expected output to match.
+- **Runs in.** BPMN: the `businessRuleTask` node key; gateways route on its output. RPA: the step, and the coded logic or lookup that evaluates it. Placement: [Product Selection Guide → Per-task component placement](product-selection-guide.md#per-task-component-placement-the-to-be-per-step).
+- **No decision rules:** write `None. No rule decides an outcome.`
+
+## 3. Rules that need reasoning
+
+List every `Reasoning` rule. Example:
+
+```markdown
+| ID | Rule | Applied by | Inputs → Output | Where it runs |
+|---|---|---|---|---|
+| BR-07 | A refund request citing a defect qualifies when the description matches a known defect. | Agent | Request text, defect catalogue → qualifies (yes/no), reason | Agent `RefundTriage`, step 4; undecided → Action Center review |
+| BR-08 | A write-off above the controller's limit needs the controller's approval. | Person | Write-off request, ledger extract → approved / rejected | Action Center task, Controller role, step 6 |
+```
+
+- **Applied by an agent:** give its output as a typed value. In `Where it runs`, name the path to a person when the agent can't decide.
+- **Applied by a person:** in `Where it runs`, name the task and the role. In BPMN the task is a `userTask`, also listed in §9 HITL Touchpoints.
+- **No reasoning rules:** write `None. Every rule is deterministic.` Don't leave the section out.
+
+## 4. Coverage
+
+Number BRs `BR-01`, `BR-02`, … across every home. A decision-table row or reasoning row is the rule's definition; no separate register repeats it. In BPMN, a validation rule goes in the variable's `Description` in §7, prefixed with its BR ID.
+
+Before closing the section, run this mechanical check:
+1. List the BR IDs extracted from the PDD.
+2. List the BR IDs cited in each home from the [§1 table](#1-classify-every-rule). All decision-table rows together count as one home.
+3. Every extracted ID appears in exactly one home list, and no home cites an ID the extraction lacks.

package/skills/uipath-planner/references/pdd-analysis-guide.md

@@ -176,6 +176,7 @@ This is the most important section. For each step, extract:
 
 Watch for:
 - **Embedded business rules** — rules are often buried in the "Remarks" column or in step descriptions rather than in a dedicated section. Extract and number them (BR-01, BR-02, etc.).
+- **Typed business rules** — a PDD Business Rules table may give each rule a type (`Deterministic`, `Reasoning: agent`, `Reasoning: person`, possibly in the document's language) and its `inputs → output`. Carry both into the SDD: they decide whether the rule becomes a decision table or a reasoning-list row ([Business Rules Guide](business-rules-guide.md)).
 - **Data field references** — step descriptions mention specific field names, variable names, or data values. Collect these for the data model definitions.
 - **Value mappings** — when a step says "map X to Y" or shows a conversion table, capture the full mapping.
 - **Implicit ordering constraints** — some steps must happen before others but the PDD doesn't explicitly say so. Note these for the workflow decomposition.

package/skills/uipath-planner/references/sdd-generation-guide.md

@@ -291,7 +291,7 @@ The architectural core sections differ per template. For each product, generate
 **Maestro BPMN:**
 - §3 Pools & Lanes (participants / roles)
 - §4 Activities Inventory (BPMN element type per activity)
-- §5 Gateways & Sequence Flows (gateway type, branch conditions)
+- §5 Gateways & Sequence Flows (gateway type, branch conditions, decision tables, reasoning list: [Business Rules Guide](business-rules-guide.md))
 - §6 Events (start / intermediate / boundary / end; message / timer / error definitions)
 - §7 Data Objects & Variables (direction, type, scope)
 - §8 Subprocesses & Call Activities
@@ -405,7 +405,7 @@ Fill in all sections of the chosen template not covered in Phase 1 or Phase 2. S
 **Phase 2 produces:** See Phase 2 Step 2 above (template-specific architectural core)
 
 **Phase 3 produces:** All remaining sections — typically:
-- Business Rules (RPA, Case)
+- Business Rules (RPA, Case). RPA §4: [Business Rules Guide](business-rules-guide.md)
 - Value Mappings (RPA)
 - Exception / Error Handling (all)
 - Credentials & Assets (RPA)

package/version-manifest.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 2,
-  "skillsVersion": "1.204.0-preview.1174",
+  "skillsVersion": "1.204.0",
   "targetCli": "^1.204.0"
 }