/uipath-governance

name: uipath-governance
description: "UiPath governance via `uip gov` — author, deploy, and diagnose policies on three layers. AOps product policies (`uip gov aops-policy`): block/restrict/enforce features in Studio, StudioX, Assistant, Robot, AI Trust Layer, Agent Builder; deploy to user/group/tenant. Access ToolUsePolicy (`uip gov access-policy`): allow/deny when one workflow invokes another as a tool (Agent→Agent/Maestro/Flow/RPA/API/Case), gated by tag, caller, or actor (User/Group). Compliance Standards (ISO 42001, ISO 27001): check posture and configure recommended settings across products in one operation. Operate: deploy/undeploy, query effective deployed policy. Diagnose: policy not taking effect, deployment precedence (user>group>tenant), blocked tool invocations. For platform ops→uipath-platform."
allowed-tools: Bash, Read, Write, Edit, Grep, Glob

UiPath Governance

Uber skill for UiPath governance authoring. Two backing CLI surfaces:

| Surface | Governs | CLI | |---|---|---| | **AOps product policy** | Product feature behavior — what Studio / StudioX / Assistant / Robot / AI Trust Layer / Agent Builder can do at design-time / runtime | `uip gov aops-policy` | | **Access policy** (`ToolUsePolicy`) | Resource/tool-use boundary — when an Actor Process invokes a child Resource (Agent / Maestro / Flow / RPA / API / Case Management), is the call allowed? | `uip gov access-policy` |

Both surfaces share verbs (`block`, `restrict`, `deny`, `allow`, `require`, `enforce`). The same English sentence often maps to either layer, so this skill **classifies first** and only then routes to the matching mechanic.

When to Use This Skill

Activate on **any** governance / policy / rule intent — even when the user did not name the underlying CLI:

• `policy / rule / guardrail / govern / gate / control` requests
• `block / restrict / deny / disable / disallow` an action, model, app, URL, agent, flow, or process
• `require / enforce / mandate` a behavior or rule
• `allow only / permit only / limit to / restrict to` X
• `who can / which … can / on behalf of` — actor- or identity-shaped governance
• `compliance / posture / audit` framing on top of policies
• `.uipolicy` file path, `compliance standard`, `apply standard`
• Standard names: `ISO 42001`, `ISO 27001`, `GDPR`, `HIPAA`, `SOC 2`, `EU AI Act`. Route on the name alone — which of them are actually usable varies by environment and is read from `catalog list` at runtime, never assumed here.
• `check compliance`, `compliance posture`, `posture against`, `drift check`
• `is my tenant compliant`, `am I compliant with`
• `organization-wide`, `all tenants`, `entire org`, `across all tenants` — org-scope full apply

Troubleshoot

• Investigate why a governance policy isn't taking effect
• Debug deployment precedence (user > group > tenant override)
• Evaluate access-policy rules against test scenarios (`access-policy evaluate`)
• Troubleshoot blocked tool/workflow invocations
• Audit which policies are deployed and to whom
• Identify license-type / product mismatch causing silent no-ops

**Sibling redirects:**

• Platform ops (auth, Orchestrator resources, packaging, deploy) → `uipath-platform`
• Authoring agents / workflows / RPA themselves → `uipath-agents` / `uipath-rpa` / `uipath-maestro-flow`

Critical Rules

1. **Classify before authoring.** First action on any governance request is to classify intent into Branch A (AOps) or Branch B (Access). Use the priors in [`references/disambiguation-guide.md`](./references/disambiguation-guide.md). Never start `create` / `update` / `delete` until classification is settled — by user wording or by the [disambiguation question](#disambiguation-question). 2. **Classification lives at the top.** Mechanic libraries assume the branch is chosen. Do not let those flows ask "did you mean the other branch?" — that question belongs here. 3. **One branch per mutation.** A single user request produces a policy on one branch only. If the user wants both, run two sequential flows with two confirmation gates. 4. **Each mechanic owns its own Critical Rules.** Once routed, follow the branch's rules — do not relax them from this top level. 5. **Never apply, restore, or remove compliance settings without user confirmation.** For apply: run posture analysis first, show the plan (summary + detail). In every case: ask, then END YOUR REPLY — never run the mutating command in the same response as the confirmation question. Proceed only on an explicit `y` in the user's next message. The user's original request is intent, not consent. Sole exception: the user explicitly waived confirmation in advance (e.g., "don't ask for confirmation") — treat the waiver as `y`. 6. **Always show a receipt after any apply.** Present the post-apply report (settings configured, manual steps needed, Applied by / date) so the user has a record. No local file write is needed — the CLI and UiPath platform are the source of truth. 7. **Compliance Standards is a preview feature — gate every compliance-pack flow.** Append the preview disclaimer to user-facing compliance-standard responses, and on any `uip gov compliance-packs …` call returning **HTTP 403 / Forbidden**, stop immediately (do not retry, run no further compliance commands) and tell the user the feature requires enrolling in the preview program. Exact wording + placement in [`references/compliance-pack/preview-gate.md`](./references/compliance-pack/preview-gate.md). A **403** is preview-not-enabled; a **401** is a normal login failure — do NOT conflate them. 8. **Always `uip login` before any `uip gov …` command.** `evaluate` (Access) additionally requires tenant-scoped login — see [`access-policy-overview-guide.md` § Critical Rules](./references/access-policy/access-policy-overview-guide.md#critical-rules). 9. **Never run a pack-scoped command before the standard is settled.** `state coverage`, `state get`, `state enable`, `state disable`, `state restore` and `catalog get` al