Verisk Pipelines

---
name: verisk-pipelines
description: Analyze and update Azure DevOps pipelines using the shared Verisk.Pipelines library. Use when requests involve ADO YAML templates, default steps/jobs/stages, full pipeline templates, template parameters, or behavior inherited from shared pipeline utilities.
---
# Verisk Pipelines

Treat Azure DevOps pipeline work as `Verisk.Pipelines` work by default.

## Workflow

1. Detect whether the target repository uses ADO pipelines by checking for `.azure/pipelines/` or `azure-pipelines*.yml`.
2. Inspect local pipeline YAML files first to find template references and parameters.
3. Refresh the local mirror of `Verisk.Pipelines` before answering questions or proposing changes.
4. Prefer existing shared templates (full pipelines, jobs, then steps) over custom inline YAML.
5. Keep changes minimal and composable by reusing existing template parameters and defaults.
6. Validate with the repository's existing pipeline validation commands where available.

## Source Of Truth

Do not rely on memory for pipeline behavior. Use a git mirror in `/tmp` as the primary reference.

Default git URL:
- `https://VIS-Claims@dev.azure.com/VIS-Claims/Architecture/_git/Verisk.Pipelines`

Override options:
- `VERISK_PIPELINES_GIT_URL` environment variable, or
- explicit user-provided git URL.

Sync commands:

```bash
CACHE_DIR="/tmp/verisk-pipelines-repo"
REPO_URL="${VERISK_PIPELINES_GIT_URL:-https://VIS-Claims@dev.azure.com/VIS-Claims/Architecture/_git/Verisk.Pipelines}"

if [ -d "$CACHE_DIR/.git" ]; then
  git -C "$CACHE_DIR" fetch --prune origin
  DEFAULT_BRANCH="$(git -C "$CACHE_DIR" symbolic-ref --short refs/remotes/origin/HEAD | sed 's#^origin/##')"
  git -C "$CACHE_DIR" checkout "$DEFAULT_BRANCH"
  git -C "$CACHE_DIR" reset --hard "origin/$DEFAULT_BRANCH"
else
  git clone "$REPO_URL" "$CACHE_DIR"
fi
```

Refresh this mirror before pipeline analysis so guidance matches current shared templates.

## What To Read
From the git mirror, prioritize:

top-level README and docs for conventions
template files defining shared pipelines/jobs/steps
template parameter definitions and defaults
examples or sample pipelines that show expected usage
When inspecting templates, trace:

Pipeline-level templates
Nested job/stage templates
Nested step templates
Final parameter values after overrides

## Guardrails
Prefer existing shared templates before adding custom YAML.
Prefer full shared pipeline templates first, then job templates, then step templates.
Do not invent template paths, parameters, or variable names; verify symbols in source.
Keep secrets and environment-specific values in variable groups/service connections, not hardcoded YAML.
Preserve existing trigger/PR/path filter behavior unless explicitly asked to change it.
Keep pipeline changes small, reviewable, and aligned with repository conventions.

## Answering Questions About Pipelines
When asked how a pipeline works:

Read the local repo pipeline YAML first.
Resolve referenced templates against Verisk.Pipelines.
Follow nested template usage to compute effective behavior.
Explain the resulting steps/jobs/stages and key parameter values.
Cite exact file paths used in the analysis.

## Validation
After pipeline changes:

Run the repository's standard pipeline validation/lint/test command(s), if present.
Report exactly which command was run and whether it passed.