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.

6) Validation Workflow

Default path (MUST for full pipeline generation):

1. Generate or update YAML.
2. Validate with azure-pipelines-validator.
3. Fix findings.
4. Re-run validation until no blocking issues remain.

Script fallback if validator skill is unavailable but local validator scripts exist:

bash devops-skills-plugin/skills/azure-pipelines-validator/scripts/validate_azure_pipelines.sh <pipeline-file>

Manual fallback when neither skill nor script can run:

1. YAML structure/indentation sanity
2. Hierarchy sanity (stages -> jobs -> steps)
3. Task format sanity (Task@Major)
4. Secret exposure scan (no plaintext credentials/tokens)
5. Deployment safety scan (environment usage, immutable deploy tags)

When fallback is used, final response MUST include:

• Validation status: Manual fallback
• Checks performed
• Residual risk

Validation MAY be skipped only for:

• snippet-only YAML
• documentation-only examples
• explicit user request to skip validation

7) Output Contract

Final response MUST include:

1. Pipeline YAML (or template set)
2. Required setup:
   • service connections
   • variable groups/secrets
   • environments and approvals/checks
3. Validation result:
   • validator status, script status, or manual fallback status
4. Assumptions
5. References used/skipped and impact
6. Optional next improvements

8) Canonical Example Flows

Example A: Full multi-stage generation

1. Select mode: Multi-stage CI/CD.
2. Capture stack/deploy/service-connection inputs.
3. Read docs/yaml-schema.md, docs/best-practices.md, and examples/multi-stage-cicd.yml.
4. Add requested customizations (stages, branch gates, environments, tasks).
5. Validate with azure-pipelines-validator; fix and re-run.
6. Return YAML + setup + validation + assumptions + references.

Example B: Quick snippet generation

1. Select mode: Snippet-only.
2. Read only the minimum required reference section.
3. Generate focused YAML snippet with safe defaults.
4. Skip full validation and state Validation status: Skipped (snippet-only).
5. Return snippet + assumptions + references.

9) Definition of Done

The execution is complete only when all applicable checks pass:

• Request mode is explicitly chosen.
• Assumptions are explicit for missing inputs.
• YAML follows checklist requirements (security, versioning, reliability, performance, maintainability).
• Validation path is documented (validator, script fallback, or manual fallback).
• Final response follows the output contract, including references and impact.