/uipath-aops

name: uipath-aops
description: "UiPath StudioAdmin AOps (`uip aops`) — SourceControl discovery plus CICD pipelines. Drives `aops connection` / `repo` / `project` / `solution` to resolve a GitHub or Azure source binding, `aops pipeline processes` to pick an already-published Orchestrator process, then composes a PipelineDto for `pipeline create` / `save-and-run` and follows runs via `aops execution logs --follow`. Replaces the retired `uip sc` and `uip cicd` tools. For AOps governance policies (`uip gov aops-policy`)→uipath-governance. For `uip solution pack/publish/deploy`→uipath-platform. For workflow authoring (.xaml/.cs)→uipath-rpa."  # <!-- uip-check-skip -->
when_to_use: "User wants to discover StudioAdmin SourceControl state or create, run, or edit a UiPath CICD pipeline that builds source from an SC-synced Studio Solution or standalone project and binds it to an already-published Orchestrator process. Triggers: 'create a pipeline for X process', 'set up CI/CD for this solution', 'build + run my pipeline', 'list my source control connections', `uip aops`, `uip sc`, `uip cicd`, StudioAdmin SourceControl, PipelineDto."  # <!-- uip-check-skip -->
allowed-tools: Bash, Read, Write, Edit, Glob, Grep

UiPath StudioAdmin AOps — Source Control + CICD Pipelines

Depends on the `@uipath/aops-tool` CLI plugin; install via `uip tools install @uipath/aops-tool` before using.

> **Tool migration.** `@uipath/sc-tool` (`uip sc`) and `@uipath/cicd-tool` (`uip cicd`) were unified into `@uipath/aops-tool` (`uip aops`). `@uipath/cicd-tool` is gone from npm. Every `uip sc <verb>` and `uip cicd <verb>` becomes `uip aops <verb>` — the verb trees merged without renaming any subcommand. See [migration-guide.md](references/migration-guide.md). <!-- uip-check-skip -->

Build a StudioAdmin CICD pipeline that binds two independent things:

• **Source** — one Studio project the pipeline checks out on every run. Two equivalent ways to reach it:
• **Solution path** — a project inside a Studio Solution surfaced by `aops connection solutions <connection-id>`
• **Standalone-project path** — a project surfaced directly by `aops connection projects <connection-id>` (no enclosing Solution)
• **Target** — an already-published Orchestrator automation process surfaced by `aops pipeline processes`. The pipeline runs / updates this process as part of its execution.

When to Use This Skill

• User wants a new pipeline for a Studio Solution or standalone project already synced to StudioAdmin
• User names a published Orchestrator process and wants a pipeline that runs / updates it
• User says "create / build / wire a pipeline" against a Solution or a process
• User wants a one-shot "create and run" with execution id + log follow
• User wants to inspect or kick off an existing pipeline run, or edit one after creation
• User wants to inspect SourceControl state — connections, repos, branches, project files, commit history

Do NOT use this skill for:

• AOps **governance** policies (`uip gov aops-policy` — Studio / Robot feature restrictions) → `uipath-governance`. Same "AOps" word, different product surface.
• Packing or publishing a `.nupkg` (`uip solution pack/publish/deploy`) → `uipath-platform`
• Authoring or editing workflow code (`.xaml`, `.cs`) → `uipath-rpa`
• Creating the SourceControl connection itself — connections are UI-only via the StudioAdmin web app
• Publishing a new process — processes are published separately (Studio publish / `uip solution publish`)

Vocabulary

| Term in this skill | What it means | |---|---| | **SourceControl connection** | A StudioAdmin-side link to GitHub or Azure DevOps. Lists via `aops connection list`. UI-provisioned. | | **Studio Solution** | A `.uipx` container surfaced by SourceControl, holding one or more projects. Lists via `aops connection solutions <connection-id>`. | | **Project** (in this skill) | A Studio project — the **source** for the pipeline build. Reached two ways: nested inside a Solution (via `connection solutions`) OR standalone (via `connection projects`). Any project `Type` is eligible for source binding. | | **Published (automation) process** | An already-deployed Orchestrator process the pipeline runs / updates. Lists via `aops pipeline processes`. **Independent of any project type.** | | **PipelineDto** | The wire format `pipeline create` / `save-and-run` consume via `--file`. Carries source binding (project + repository + branch) AND target binding (`processIdentifier`). | | **EditPipelineDto** | The narrower shape `pipeline update --file` consumes — `identifier`, `name`, `runMode`, `description`, `arguments` only. |

The published process is NOT the same thing as a Studio project of type "Process". Studio project types describe how to build / package source. Published processes are runnable artifacts in Orchestrator. The pipeline glues them: build source → update / run the target process.

Critical Rules

1. **The tool is `aops`, not `sc` / `cicd`.** Run `uip tools list --output json` and confirm an entry with `commandPrefix: "aops"`. If missing: `uip tools install @uipath/aops-tool`. If the registry does not know the package, see [migration-guide.md § Install](references/migration-guide.md#install). Then `uip login status --output json`; if not logged in, `uip login`. 2. **Response keys are PascalCase; `--file` input keys are camelCase.** The CLI PascalCases every key inside the stdout `Data` payload (`Identifier`, `RemoteId`, `CloneUrl`, `DefaultBranch`, `ProjectRelativePath`). The JSON you *write* for `--file` must use the DTO's own camelCase names (`repositoryId`, `projectPath`, `processIdentifier`). Never round-trip stdout into `--file`. Use `--output-file` when you need a raw DTO on disk. 3. **Sources come from AOps, not local disk.** Do NOT scan `*.sln` / `*.uipx` / `project.json` files. Discover via `uip aops connection solutions <connection-id>` and `uip aops connection projects <connection-id>`. Local files don't carry `connect