Azure DevOps Repos-first template architecture for reusable CI pipelines. Use when designing or debugging Azure Pipelines YAML templates, splitting PR validation from post-merge main workflows while reusing one core CI template, enforcing strict compile-time/runtime variable rules, building typed template APIs (`stepList`, `jobList`, `stageList`, `templateContext`), or creating self-contained dependency-management templates for TypeScript/Python/R using bun, npm, and pixi—e.g., "one CI template for PR and main", "fix expression timing bug", "design jobList template contract".
Install with Tessl CLI
npx tessl i github:jjjermiah/dotagents --skill azuredevops-pipelines-template94
Does it follow best practices?
Validation for skill structure
Build production-grade Azure Pipelines template systems for Azure Repos. Reuse one CI core across PR and main, keep templates self-contained, and make variable timing explicit so behavior is predictable.
pr: for Azure Repos PR validation.azuredevops-pipelines-loggingUse both skills when template design and script signaling intersect:
azuredevops-pipelines-logging owns ##vso[...] and ##[...] command
correctness, escaping, masking, and output-variable propagation details.Use three files as a baseline:
azure-pipelines-pr.yml - branch-policy validation pipeline for PRs.azure-pipelines-main.yml - post-merge main CI pipeline.templates/ci-core.yml - shared implementation logic.The two entry pipelines should only set triggers and template parameters. Keep all jobs, stages, and steps in the shared template.
azure-pipelines-pr.yml should use trigger: none and pr: none; connect
this pipeline to target branches via Build Validation branch policy.azure-pipelines-main.yml should use CI trigger on main and pr: none.Choose syntax by evaluation phase:
${{ }} compile-time template expression:
if, each, template insertion).$[ ] runtime expression:
$( ) macro syntax:
Never mix these syntaxes casually. Most template bugs are timing bugs.
For each template:
type and sensible defaults.values: when practical.parameters, not hidden globals.stepList, jobList, stageList) where needed.stepList to inject controlled step hooks.jobList with templateContext for suite metadata and fan-out jobs.stageList for environment promotion templates.object instead of stringList.Design dependency installation as dedicated step templates and include them from
ci-core.yml based on typed parameters.
bun install --frozen-lockfile or npm ci.pixi install, pixi run <task>.pixi install, pixi run <task>.Use one explicit parameter (for example dependencyMode: fast|locked) to alter
install strictness between PR and main.
pr/main/core) and draft template API.${{ }} only.condition: logic with $[ ] where required.##vso[...] command details to
azuredevops-pipelines-logging when needed.When this skill is used, return:
pr/main/core) and file map.azuredevops-pipelines-logging: load when the template design requires
concrete ##vso[...] command snippets, output variable propagation, secret
masking, or rich log formatting semantics.stepList, jobList, and stageList APIs.If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.