npx claudepluginhub uipath/skills --plugin uipathThis skill is limited to using the following tools:
> **Preview** — skill is under active development; surface and behavior may change.
Authors UiPath ToolUsePolicy access policies via `uip gov access-policy` CLI to govern tool/resource use when actor processes invoke child resources.
Govern Power Automate flows and Power Apps at scale using FlowStudio MCP: classify by business impact, detect orphaned resources, audit connectors, enforce compliance, manage notifications, compute governance scores.
Encodes human-readable governance policies into machine-executable JSON constraints for AI agents and CI pipelines to validate automatically. Outputs rule files in .ai/governance/.
Share bugs, ideas, or general feedback.
Preview — skill is under active development; surface and behavior may change.
Skill for managing AOps governance policies and deploying them to users, groups, or tenants via the uip gov aops-policy CLI.
Terminology. "AOps" = Automation Ops (a.k.a. AutomationOps), UiPath's governance console. An "AOps policy" — managed via
uip gov aops-policyand this skill — is an Automation Ops Governance Policy covering product runtime / design-time behavior (Studio, StudioX, Assistant, Robot, AI Trust Layer, …). This is distinct from a Governance Access Policy (identity / role / access control), which this skill does NOT cover.
Activate on both explicit policy requests and natural-language governance intent — users rarely say "AOps policy" by name.
Explicit requests:
uip gov aops-policy commandsGovernance intent (rule/policy patterns without naming the product):
These are AOps governance requests — treat them as a create policy flow starting at aops-policy-manage-guide.md Step 1, Case B (intent-based product selection). See the intent-mapping examples below to prime product selection, and aops-governance-recipes-guide.md for the field mappings behind each recipe.
When the user expresses a governance rule without naming a product, your job is to map the intent keywords to the right Product policy. The bootstrap (every product's form-template-locale-resource.json) is the source of truth — always rank products by locale-keyword matches (aops-policy-manage-guide Step 1, Case B). These examples are priors to narrow the search, not a substitute for grepping the locale files:
| User says... | Likely Product | Signal keywords to grep |
|---|---|---|
| "block Gemini / Claude / ChatGPT", "restrict which LLMs agents can use", "disable external AI models" | AITrustLayer | model names, "provider", "feedback", "region" |
| "lock down Studio", "disable Studio feedback / telemetry", "restrict Studio packages / activities" | Development (Studio) | "feedback", "package", "activity", "publish" |
| "control StudioX citizen-dev features", "restrict business-user automations" | Business (StudioX) | "StudioX", "citizen", "template" |
| "govern what Robot can run", "restrict attended / unattended runtime" | Robot product (check bootstrap) | "runtime", "process", "attended" |
| "control Agents / Agent Builder features", "restrict agent tool access" | Agents product (check bootstrap) | "agent", "tool", "builder" |
| "enforce a tenant-wide default", "apply to everyone in the tenant" | Any product — this is a deployment signal, not product selection. Route to aops-policy-deploy-guide.md after create. | — |
Workflow for intent-based requests:
Grep matches on each product's form-template-locale-resource.json (Case B). Present the top 3.uip login before running any uip gov aops-policy commands.name (identifier) in CLI commands, not the label shown to the user.create: always bootstrap before selecting or confirming a product. Run uip gov aops-policy template list --output-dir "$SESSION_DIR/products" --output json — this writes each product's form-template.json (whose top-level product object holds {name, label}), form-data.json, and form-template-locale-resource.json into $SESSION_DIR/products/<ProductName>/. The product catalog is implicit — enumerate products with the Glob tool on $SESSION_DIR/products/*/form-template.json and read .product.{name, label}. Do NOT create a separate products.json or run product list. Use the bootstrapped schemas to validate the user's chosen product against their stated intent; if the intent's fields live under a different product, suggest that product instead.create, read the form template, default form data, and locale labels from $SESSION_DIR/products/<ProductName>/ (produced by the bootstrap). For update, the caller creates $SESSION_DIR first (see aops-policy-manage-guide update Step 1) and then configure-guide runs template get with --output-form-data and --output-template-locale-resource into the same per-product subfolder. Use the locale file for human-readable labels and the form-data (create) or existing policy data (update) for the working blueprint. Prefer Mode A (intent-based auto-fill) over field-by-field prompting whenever the user supplied any intent. Do not construct policy data JSON manually.key as the JSON key in policy data — never the label or humanized name.{ "data": {...} }. The final policy data file must match the format of the form-data file produced by template get --output-form-data.--description, --priority, --availability) if the user skips them — do not pass empty strings.update: always get the existing policy first and show its current values before asking what to change. Use the existing policy's Data.data as the update blueprint (jq '.Data.data' > "$SESSION_DIR/existing-policy-data.json") — NOT the product's default form-data.json. Using the product defaults as the update blueprint would silently wipe every non-default setting the user previously configured.delete: always get the policy and show a summary, then ask for explicit confirmation before running the delete command.create, update, or delete call. Do not add intermediate yes/no gates (no per-page confirmation, no "save this configuration?" after configure). The caller in aops-policy-manage-guide.md owns the final review.SKILL.md, a reference file, or any other part of the skill. The user's job is to describe what they want governed; your job is to execute the existing flow (bootstrap → Case A/B → configure → review → create). If the user's intent does not map to any product after the bootstrap + locale grep, ask them to clarify the rule or pick a product from the list — do NOT propose skill edits as a workaround.uip gov aops-policy list --product-name "$PRODUCT_NAME" --order-by priority --order-direction asc --output json — even when the user already supplied a priority — and cite the policy at priority 1 (name + GUID) next to the proposed priority in the review block, along with a one-line rank-impact note ("placed last — does not reorder existing winners" vs. "outranks at the group level"). Omitting this row silently lets the user approve a priority whose group-level consequences they never saw. Exact format: aops-policy-manage-guide.md — Step 4.Policy data link with the full absolute path to $SESSION_DIR/aops-policy-data.json. Render it as a markdown link ([aops-policy-data.json](/absolute/path/to/.../aops-policy-data.json)) using the resolved absolute path — never a relative path, a literal <SESSION_DIR> placeholder, or a ~/ path. Run realpath (or equivalent) to resolve. This is the user's only chance to inspect every composed field (including defaults not surfaced in the changed-settings diff) before the mutation runs. Reviews without this link are incomplete — do not call create / update after an incomplete review. Exact format: aops-policy-manage-guide.md — Step 4 and Step 5.Availability: row in the create/update review unless the user explicitly supplied a value. Availability is the offline grace period (in days) during which a client (Studio, Assistant, etc.) keeps applying the cached copy of this policy when it cannot reach Automation Ops. It is almost always left at the server default, and surfacing it as (none) adds noise to the review. When the user did supply it, show it inline alongside Priority (e.g. Priority: 4, Availability: 30) rather than as a standalone row. Semantics: must be an integer > 0; sending 0 causes the server to normalize to 30; when multiple products contribute to a merged policy response, the smallest availability across contributors wins.These steps are for creating a new policy from scratch. For existing policies or targeted operations, jump straight to the relevant guide via the Task Navigation table below.
uip CLIwhich uip && uip --version
If not installed (both commands fail):
npm install -g @uipath/uipcli
All uip gov aops-policy commands require authentication.
uip login status --output json
If not logged in:
uip login # interactive OAuth (opens browser)
uip login --authority https://alpha.uipath.com # non-production environments
Isolate scratch files for this run in a session directory, then fetch every product's form template, default form data, and locale resource in a single call (Critical Rule #3).
SESSION_DIR="./aops-sessions/$(date +%Y%m%d-%H%M%S)-$(uuidgen | cut -c1-8 | tr '[:upper:]' '[:lower:]')"
mkdir -p "$SESSION_DIR/products"
uip gov aops-policy template list --output-dir "$SESSION_DIR/products" --output json
This writes form-template.json, form-data.json, and form-template-locale-resource.json into $SESSION_DIR/products/<ProductName>/ for every product. The product catalog is implicit — enumerate products with Glob on $SESSION_DIR/products/*/form-template.json and read .product.{name, label}.
See configure-aops-policy-data-guide.md — Step 1 for the full bootstrap procedure.
Two cases, per aops-policy-manage-guide.md:
Grep against every product's form-template-locale-resource.json to rank matches. Present the top 3 and let the user confirm. See the intent-mapping table above for priors.Prefer Mode A (intent-based auto-fill) over Mode B (field-by-field prompting) whenever the user supplied any intent (Critical Rule #4).
form-template.json.key (never the label — Critical Rule #5).form-template-locale-resource.json when surfacing choices to the user.$SESSION_DIR/aops-policy-data.json — do NOT wrap it in { "data": {...} } (Critical Rule #6).See configure-aops-policy-data-guide.md for the full component-tree traversal.
Show only the changed values (not unchanged defaults) and require an explicit yes. This is the only confirmation gate in the entire create flow (Critical Rule #12). Use the canonical wording from Confirmation-gate wording below.
The review block MUST include:
Priority row with (a) the proposed priority number, (b) the current #1 holder's policy name and GUID, and (c) a one-line rank-impact note (Critical Rule #15).Policy data row with a clickable markdown link to the composed $SESSION_DIR/aops-policy-data.json — using the resolved path, not a <SESSION_DIR> placeholder (Critical Rule #16).See aops-policy-manage-guide.md — Step 4 review template for the exact format. If you skipped the priority-landscape list call in Step 3, run it before showing the review — the user cannot consent to the rank impact without seeing whose position the new policy is landing behind.
uip gov aops-policy create \
--product-name "<PRODUCT_NAME>" \
--name "<POLICY_NAME>" \
--input "$SESSION_DIR/aops-policy-data.json" \
--output json
Omit --description, --priority, --availability if the user did not supply them (Critical Rule #7). Stop and surface the error if the command fails (Critical Rule #8).
Use AskUserQuestion to offer next steps. See Completion Output below for the exact dropdown.
form-template.json, and every value must start from form-data.json (create) or Data.data (update). Hand-written JSON silently drops or mis-names fields, producing policies that look fine to the CLI but do nothing at runtime.key — humanizing the key (e.g., feedbackEnabled → "Feedback Enabled") is often wrong. Look the label up in form-template-locale-resource.json first.template get for a single product in the create flow — you need every product's schema in $SESSION_DIR/products/ to rank intent matches against live locale files (Rule #3).AllowedApplications / BlockedURLs / BlockedEmails lists are populated. If the user's intent didn't supply values, surface the no-op to them before creating. See aops-governance-recipes-guide.md — R1/R2/R3.Unattended license type — it only covers Robot). Check the license-type → product coverage in aops-policy-commands.md — license-type list before building the tenant assignment file.Analyzer.EmbeddedRulesConfig.Rules with IsEnabled: true. If the user asks to "enforce Workflow Analyzer" without naming rules, ask which rules matter or apply a CoE baseline and confirm — do not save an empty Rules array. See aops-governance-recipes-guide.md — S3.| I need to... | Read these |
|---|---|
| Create a new policy from intent | Quick Start + aops-policy-manage-guide.md (Case B) + configure-aops-policy-data-guide.md |
| Create a policy when the user named the product | aops-policy-manage-guide.md (Case A) + configure-aops-policy-data-guide.md |
| Update an existing policy | aops-policy-manage-guide.md — blueprint from Data.data, NOT form-data.json (Rule #9) |
| Delete a policy | aops-policy-manage-guide.md — show summary + explicit yes (Rule #10) |
| List policies | aops-policy-manage-guide.md — List |
| Get a single policy by GUID | aops-policy-manage-guide.md — Get |
| Deploy a policy to a user / group / tenant | aops-policy-deploy-guide.md |
| Query what policy is deployed to a tenant | aops-policy-deployed-guide.md — use get |
| Query what rules effectively apply to me | aops-policy-deployed-guide.md — use list |
| Find a canonical recipe for a common governance intent | aops-governance-recipes-guide.md — check here first; apply the recipe's product + field mapping before field-by-field prompting |
| Configure individual field values (form.io traversal) | configure-aops-policy-data-guide.md |
| Recognize a governance intent | Intent-mapping table at the top of this SKILL.md |
| Pick the right product for an intent | Bootstrap (Step 2) + Grep on locale files (Rule #3) + intent-mapping table |
uip gov aops-policy template list --output-dir <dir> writes every product's form-template.json, form-data.json, and form-template-locale-resource.json into <dir>/<ProductName>/. There is no separate product list step — enumerate products by globbing the bootstrapped directory and reading the top-level product object from each form-template.json. This is the source of truth (Critical Rule #3).
Grep matches on each form-template-locale-resource.json. Present top 3.| Command | Returns | Use when |
|---|---|---|
deployed-policy get | Tenant-level deployed policy assignment for a (licenseType, product, tenant) | "What policy is deployed to this tenant?" |
deployed-policy list | Effective rule values for the calling user after the user → group → tenant chain | "What rules actually apply to me?" |
See aops-policy-deployed-guide.md.
The product name is the CLI identifier (e.g., Development, AITrustLayer). The label is the human display string. Always pass name to CLI flags; surface label only in user-facing messages (Critical Rule #2).
Scratch space for a single run: ./aops-sessions/<YYYYMMDD-HHMMSS>-<short-uuid>/. Holds bootstrapped product schemas under products/<ProductName>/, the working aops-policy-data.json, and (for update) existing-policy-data.json. Reuse $SESSION_DIR across related operations such as configure → deploy.
Priority is NOT what decides which policy wins across user / group / tenant — that's the resolution chain (User > Group > Tenant), which is determined by scope, not by Priority. Priority only ever matters as a tie-breaker within the same level, and in practice it only actually breaks ties at the group level:
| Level | Can multiple policies compete for the same product? | Role of Priority |
|---|---|---|
| User | No — each (user, product) has at most one assignment. | None. Priority has no effect. |
| Group | Yes — a user can belong to multiple groups, each with its own policy for the same product. | Tie-breaker. Lowest priority number wins among the competing group assignments. |
| Tenant | No — each (tenant, product, licenseType) has exactly one assignment. | None. Priority has no effect. |
Outside of the group-level tie-breaker, Priority is essentially an admin-facing ordering hint (it controls the order policies appear in the Automation Ops catalog / aops-policy list, not which one applies at runtime).
Practical consequence for the create flow: default a new policy to the largest existing priority + 1 (i.e. place it last), so creation never silently reorders the group-level tie-breaker outcome for existing users. Only lower the number when the user explicitly asks for the new policy to outrank specific existing policies at the group level. Always explain this before prompting for a priority value. See also Deployed policy vs effective rules for how scope resolution works.
Every mutation runs through a single yes/no review (Critical Rule #12). Use these templates verbatim so wording stays consistent across the skill:
| Operation | Template |
|---|---|
| Create | Create policy "<POLICY_NAME>" for <PRODUCT_LABEL>? (yes / no / keep editing) |
| Update | Apply update to policy "<POLICY_NAME>"? (yes / no / keep editing) |
| Delete | Delete policy "<POLICY_NAME>"? This cannot be undone. (yes / no) |
| Deploy (any subject) | Apply these changes to <SUBJECT_NAME>? (yes / no) |
| Deployment delete-all | Delete all policy assignments for <SUBJECT_NAME>? This cannot be undone. (yes / no) |
| Tenant remove | Remove <PRODUCT_LABEL> assignment from <TENANT_NAME>? This cannot be undone. (yes / no) |
keep editing is treated the same as no — route the user back to the relevant step (metadata / field-configure / subject-pick) and re-enter the review gate only after the change is applied.
See configure-aops-policy-data-guide.md.
When you finish a mutating operation, report:
Created policy <name> (GUID: <guid>) for product <productName>.$SESSION_DIR so the user can inspect bootstrapped schemas and the aops-policy-data.json that was submitted.delete.)AskUserQuestion to present a dropdown with these options (single post-mutation gate, per Critical Rule #12):| Option | Action |
|---|---|
| Deploy to a user | Hand off to aops-policy-deploy-guide.md with subject = user. |
| Deploy to a group | Hand off to aops-policy-deploy-guide.md with subject = group. |
| Deploy to the tenant | Hand off to aops-policy-deploy-guide.md with subject = tenant. |
| List policies to verify | Run uip gov aops-policy list --output json and show the new/updated entry. |
| Query effective rules | Run deployed-policy list (or get) per aops-policy-deployed-guide.md. |
| Something else (last option) | Accept free-form string input and act on it (e.g., "just leave it", "export the policy data", "create another one"). |
Do not run any of these actions automatically. Wait for the user's selection.
Per-operation adjustments to the dropdown:
create or update: offer all options above.deploy: replace the three Deploy options with a single Verify deployment option that runs deployed-policy get <licenseType> <productName> <tenantIdentifier> to confirm the assignment took effect. Keep Query effective rules (via deployed-policy list) as the follow-up check for chain-resolved values.delete: offer only List policies to verify and Something else.uip gov aops-policy subcommand, its flags, input/output shapes, and authentication modes (including S2S token acquisition). Every other guide links here for command details rather than inlining them.$SESSION_DIR/products/.deployment <subject> configure --input. Non-interactive: the agent builds the assignment JSON, calls configure --input, and verifies with deployment <subject> get.get) vs every applicable rule for the calling user (list). Positional argument reference (<LICENSE_TYPE> <PRODUCT_NAME> <TENANT_ID>) and S2S flag semantics (--s2s-token, --user-id, --tenant-only).