---
name: Azure DevOps via SecureVault
triggers:
  - azure devops
  - azure
  - az cli
  - securevault
replaces_orchestrator: false
---

# Azure DevOps via SecureVault

Wrap all `az` CLI calls with `securevault run --profile Azure_DevOps <command>`. PAT is injected from OS keychain as `AZURE_DEVOPS_EXT_PAT`. Agent never sees credentials.

- Profile name is **`Azure_DevOps`** (case-sensitive — not `azure-devops`).
- On Windows do **not** add the `--` separator between `securevault run --profile Azure_DevOps` and the command — it breaks under cmd. Just append the command directly.

## Org and project
The org and project the vault PATs are scoped to are persisted in `~/.azure/azuredevops/config` (set once via `az devops configure --defaults`). A 401 on every call almost always means the wrong org is configured — verify with `az devops configure --list` before assuming the token is expired.

## Before first use
```bash
securevault health   # start backend if fails: securevault &
securevault run --profile Azure_DevOps az devops configure --list   # confirm org/project defaults
```

## Examples
```bash
# Create PR
securevault run --profile Azure_DevOps az repos pr create --repository <repo> --source-branch <branch> --target-branch main --title "title" --org <org> --project <project>

# PR threads
securevault run --profile Azure_DevOps az devops invoke --area git --resource pullRequestThreads --route-parameters project=<p> repositoryId=<r> pullRequestId=<id> --org <org>

# Clone
securevault run --profile Azure_DevOps git clone https://<org>@dev.azure.com/<org>/<project>/_git/<repo>

# Push
securevault run --profile Azure_DevOps git push origin <branch>
```

## Rules
- ALWAYS use `securevault run --profile Azure_DevOps` for authenticated ops
- NEVER use `az` directly, NEVER ask for PAT values
- `#<number>` in Azure DevOps PR comments/descriptions auto-links to a **work item**, not a PR. To reference a PR, use the full URL: `[PR 12345](https://dev.azure.com/ORG/PROJECT/_git/REPO/pullrequest/12345)`

## PR Comments
When leaving comments on pull requests (e.g. replying to reviewer questions), write structured, human-readable responses:
- Use **bold** for key terms and section headers
- Use bullet lists and numbered lists for clarity
- Compare before/after when explaining a change
- Explain the "why" clearly — the reviewer is a person, not a compiler
- Keep technical but conversational — no walls of unformatted text

### Posting comments via API
When using `az devops invoke` to post PR comments with `--in-file`, **always write a fresh file** with the comment payload immediately before posting. Never reuse a temp file path that may contain stale content from a previous operation — this can accidentally post unrelated comments to the wrong PR thread.