Azure Pipelines Generator

Azure Pipelines Generator

Generate production-ready Azure DevOps pipeline YAML with deterministic steps, explicit fallbacks, and clear completion criteria.

Trigger Guidance

Use this skill when the user asks to generate or redesign Azure Pipelines YAML, for example:

• "Create azure-pipelines.yml for my Node service."
• "Build a multi-stage Azure DevOps pipeline with staging and production."
• "Generate Azure pipeline templates for reuse across repos."
• "Convert this CI flow to Azure Pipelines."

Do not use this skill for validation-only requests. For validation-only work, use azure-pipelines-validator.

Execution Model

Normative keywords:

• MUST: required
• SHOULD: default unless user asks otherwise
• MAY: optional

Deterministic sequence:

1. Classify request mode.
2. Capture minimum required inputs.
3. Load minimum references (progressive disclosure).
4. Generate YAML using the quality checklist.
5. Validate (validator skill, script fallback, or manual fallback).
6. Return output in the required report format.

If a step cannot run due to environment limits, use the fallback in that step and continue.

1) Classify Request Mode

Choose exactly one primary mode:

• Basic CI: build/test/lint for one stack.
• Multi-stage CI/CD: build -> test -> deploy with environment tracking.
• Docker: image build/push and optional deploy.
• Kubernetes: image build/push plus Kubernetes deployment.
• Language-specific: .NET, Node.js, Python, Go, Java focused.
• Template-based: reusable templates plus thin root pipeline.
• Snippet-only: partial YAML requested, not full pipeline.

Mode-to-example mapping:

• Basic CI -> examples/basic-ci.yml
• Multi-stage CI/CD -> examples/multi-stage-cicd.yml
• .NET -> examples/dotnet-cicd.yml
• Python -> examples/python-cicd.yml
• Go -> examples/go-cicd.yml
• Kubernetes -> examples/kubernetes-deploy.yml
• Template-based -> examples/template-usage.yml + examples/templates/*.yml

2) Capture Required Inputs

Collect these before generation:

• App stack and package manager
• Build/test commands and report expectations
• Deployment target (none, Azure service, Docker registry, Kubernetes)
• Environment flow (dev/staging/prod) and branch gates
• Service connections, variable groups, secret handling
• Template requirement (yes/no)

Safe defaults when missing:

• CI branches: main, develop
• Production deploy branch: main only
• Agent image: pinned image (for example ubuntu-22.04)
• Deploy image tag: immutable ($(Build.BuildId)), never deploy latest

If key details are missing, state assumptions explicitly in final output.

3) Load References (Progressive Disclosure)

Read local references first.

Always read:

• docs/yaml-schema.md
• docs/best-practices.md

Read conditionally:

• docs/tasks-reference.md when selecting tasks/inputs
• docs/templates-guide.md only for template-based mode

Then read only the closest example(s) from the mode mapping above.

Fallback behavior for missing references:

• Missing example: use nearest mode example and note substitution.
• Missing doc section: continue with known conventions and mark uncertainty.
• Snippet-only request: read only the minimum needed for safe output.

The final response MUST include:

• References used
• References skipped or missing
• Impact

4) External Docs Escalation (Only When Needed)

Escalate beyond local docs only when:

• required task info is not in local docs
• task version compatibility is unclear
• troubleshooting a task-specific failure

Use this order:

1. Context7 (mcp__context7__resolve-library-id -> mcp__context7__query-docs)
2. Official docs search (Microsoft Learn first)

If network/tools are unavailable, proceed with best-known local guidance and add a residual-risk note.

5) Pipeline Generation Checklist

Apply all items below unless user asks for a narrow snippet.

Security:

• Never hardcode secrets.
• Use service connections and variable groups/secrets.
• Use immutable deploy image tags.

Versioning:

• Pin vmImage to explicit version, not *-latest.
• Pin task major versions (Task@N).
• @0 is allowed only when that task uses major 0.

Reliability:

• Use explicit dependsOn.
• Add timeoutInMinutes for long-running jobs.
• Use branch-gated deployment condition rules.
• Use deployment jobs with environment for deploy stages.

Performance:

• Use Cache@2 where it improves dependency install time.
• Use shallow checkout when full history is not required.
• Publish only required artifacts.

Testing/observability:

• Run lint/tests in CI.
• Publish test results with condition: succeededOrFailed().
• Publish coverage when available.

Maintainability:

• Add displayName for stages/jobs/key steps.
• Use templates when logic repeats.
• Add short comments only for non-obvious logic.