Agent Skill · UiPath

uipath-governance

UiPath governance via `uip gov` — author and deploy policies on two 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). Skill classifies product-layer vs resource/tool-use intent before authoring. For platform ops→uipath-platform.

Provider: UiPath Path in repo: skills/uipath-governance/SKILL.md

Skill body

UiPath Governance

Preview — skill is under active development; surface and behavior may change.

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:

Sibling redirects:

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. Never start create / update / delete until classification is settled — by user wording or by the 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. Always uip login before any uip gov … command. evaluate (Access) additionally requires tenant-scoped login — see access-policy-overview-guide.md § Critical Rules.
  6. Never fabricate UUIDs. Resolve every named user / group / process / agent / flow / robot / tenant via the relevant branch’s lookups.

Workflow

  1. Classify the intent. Read references/disambiguation-guide.md — it lists the strong signals for each branch, the phrase patterns that need disambiguation, and the canonical worked example. If a strong signal matches, route silently. If the phrasing is ambiguous (matches both branches), ask the disambiguation question and wait for a digit reply. If the user replies with anything other than 1 or 2, treat it as a re-statement of intent and re-classify. Do not run any CLI command before classification is settled — the disambiguation question itself does not need uip, and an unrelated request (platform ops, agent authoring) must redirect to a sibling skill before any setup happens here.
  2. Verify uip and login (only after classification routes to a governance branch).
    which uip && uip --version
    uip login status --output json
    

    If not installed: npm install -g @uipath/uipcli. If not logged in: uip login (--authority <URL> for non-prod). For Access evaluate, login MUST be tenant-scoped.

  3. Route to the chosen mechanic and follow its flow end-to-end.

Disambiguation Question

When the user’s intent fits both branches, render exactly this numbered list (no AskUserQuestion, no table) and wait for a digit reply:

### Which layer should this rule govern?

1. **Govern the product** — control what Studio / StudioX / Assistant / Robot / AI Trust Layer / Agent Builder *can do* (e.g. block ChatGPT inside Studio, enforce Workflow Analyzer, disable a Marketplace widget). Backed by `uip gov aops-policy`.
2. **Govern resource/tool use** — control which Actor Processes / identities can *invoke* which child Resource as a tool (e.g. block agents tagged `Sandbox` from being called, only let the finance group trigger this Flow). Backed by `uip gov access-policy`.

Reply with the number.

The canonical ambiguous prompt is “Block ChatGPT for my finance team using Studio.” See references/disambiguation-guide.md for the worked-out reasoning of why both interpretations produce a working but different artifact.

Reference Navigation

I need to… Read
Decide which branch a request belongs to (priors, phrase tables, worked example) references/disambiguation-guide.md
Author an AOps product policy references/aops-policy/aops-policy-overview-guide.md
Deploy an AOps policy to user / group / tenant references/aops-policy/aops-policy-deploy-guide.md
Query the deployed AOps policy / effective rules references/aops-policy/aops-policy-deployed-guide.md
Author an Access ToolUsePolicy references/access-policy/access-policy-overview-guide.md
Look up CLI flags / output shapes (AOps) references/aops-policy/aops-policy-commands.md
Look up CLI flags / output shapes (Access) references/access-policy/access-policy-commands.md
Resolve a name to a UUID for Access references/access-policy/resource-lookup-guide.md

Anti-patterns

Skill frontmatter

allowed-tools: Bash, Read, Write, Edit, Grep, Glob