uipath-governance

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

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. 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.
   • Branch A → references/aops-policy/aops-policy-overview-guide.md
   • Branch B → references/access-policy/access-policy-overview-guide.md

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

• Do NOT skip the disambiguation question when the phrasing fits both branches. Mechanic libraries assume the branch is chosen and will not catch wrong-branch routing.
• Do NOT hand off to a mechanic, then ask "did you mean the other branch?". That question must happen at this top level.
• Do NOT merge AOps and Access intent into one policy. Different artifacts, different CLIs, different schemas.
• Do NOT activate this skill for platform ops. Route to uipath-platform.
• Do NOT propose skill edits when intent doesn't map to either branch. Ask the user to clarify.