azure-pipelines-validator — скилл для Claude Code: проверка Azure
Проверяет azure-pipelines.yml локальными скриптами: синтаксис, безопасность, best practices. Пригодится перед мержем пайплайна.
npx skills add akin-ozer/cc-devops-skills --skill azure-pipelines-validator -a claude-codeЧто делает azure-pipelines-validator
Скилл запускает bash-скрипт, который разбирает YAML Azure DevOps и выдаёт отчёт по трём корзинам: синтаксис, безопасность, best practices. Каждое замечание помечено severity — Blocking, Warning, Info — и rule ID, например hardcoded-secret или task-version-zero. Рядом с находкой идёт короткая рекомендация по исправлению.
Есть режимы: полный прогон, только синтаксис (--syntax-only), только best practices (--best-practices), только безопасность (--security-only) и строгий режим --strict, где предупреждения валят проверку. Коды возврата простые: 0 — прошло, 1 — блокирующие проблемы, 2 — неверный вызов. Пути скрипт берёт от корня репозитория через git rev-parse --show-toplevel; если корень не определился, он останавливается и просит указать путь, а не угадывает.
Для работы нужны bash и python3. Если yamllint не установлен, проверка не падает — lint просто пропускается с пометкой в отчёте. Без Python скриптовая валидация блокируется, остаётся ручной разбор YAML. Генерацией пайплайнов с нуля скилл не занимается — для этого есть azure-pipelines-generator.
Какие задачи решает
- проверить
azure-pipelines.ymlперед мержем - найти хардкод паролей и секретов в пайплайне
- поймать синтаксические ошибки в YAML до запуска сборки
- прогнать security-скан пайплайна в CI
- проверить пайплайн на best practices: версии задач, кэш, displayName
Примеры запросов агенту
- Проверь мой
azure-pipelines.ymlна синтаксис и безопасность - Запусти security-скан этого Azure DevOps пайплайна
- Почему падает этот YAML? Прогони валидатор в строгом режиме
Как установить azure-pipelines-validator
1Через Skills CLI (Vercel)
npx skills add akin-ozer/cc-devops-skills --skill azure-pipelines-validator -a claude-code2Вручную: положить файлы
~/.claude/skills/azure-pipelines-validator/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/azure-pipelines-validator/
1Через Skills CLI (Vercel)
npx skills add akin-ozer/cc-devops-skills --skill azure-pipelines-validator -a codex2Вручную: положить файлы
.agents/skills/azure-pipelines-validator/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add akin-ozer/cc-devops-skills --skill azure-pipelines-validator -a cursor2Вручную: положить файлы
.cursor/skills/azure-pipelines-validator/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install akin-ozer/cc-devops-skills azure-pipelines-validator2Вручную: положить файлы
.github/skills/azure-pipelines-validator/SKILL.md1Через Skills CLI (Vercel)
npx skills add akin-ozer/cc-devops-skills --skill azure-pipelines-validator -a gemini-cli2Командой платформы
gemini skills install https://github.com/akin-ozer/cc-devops-skills --path devops-skills-plugin/skills/azure-pipelines-validatorВручную: положить файлы
.devin/skills/azure-pipelines-validator/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add akin-ozer/cc-devops-skills --skill azure-pipelines-validator -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о azure-pipelines-validator
Как установить azure-pipelines-validator в Claude?
Выполните npx skills add akin-ozer/cc-devops-skills --skill azure-pipelines-validator -a claude-code. После этого файл скилла лежит в ~/.claude/skills/azure-pipelines-validator/SKILL.md.
Что делает azure-pipelines-validator?
Прогоняет локальный скрипт по файлу azure-pipelines.yml и возвращает отчёт с находками по синтаксису, безопасности и best practices, разложенными по severity. К каждой находке прилагается короткое исправление.
Что нужно для работы скилла?
bash и python3. Если yamllint недоступен, проверка продолжается без него, а пропуск отмечается в отчёте. Без Python остаётся только ручной разбор YAML.
Исходный текст
SKILL.md · Apache-2.0
--- name: azure-pipelines-validator description: Validate, lint, audit, or review azure-pipelines.yml — syntax, security, best practices. --- # Azure Pipelines Validator Use this skill to validate Azure DevOps pipeline YAML (`azure-pipelines.yml` / `azure-pipelines.yaml`) with local scripts first, then escalate to docs only when local output is not enough. ## Trigger Phrases Use this skill when the user asks things like: - "Validate my `azure-pipelines.yml`." - "Why is this Azure pipeline YAML failing?" - "Run a security scan on this Azure DevOps pipeline." - "Check this pipeline for best-practice issues." - "Review this pipeline in CI before merge." Do not use this skill for pipeline generation from scratch. Use `azure-pipelines-generator` for that. ## Deterministic Path Setup (No Ambiguity) Run from any directory using explicit absolute paths: ```bash REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" SKILL_DIR="$REPO_ROOT/devops-skills-plugin/skills/azure-pipelines-validator" PIPELINE_FILE="$REPO_ROOT/azure-pipelines.yml" ``` If `REPO_ROOT` is empty, stop and ask for the repository root path. Do not guess paths. Validate one file: ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" "$PIPELINE_FILE" ``` Auto-detect from current directory (up to depth 3): ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" ``` If auto-detect returns multiple files, rerun with one explicit file path. ## Local-First Execution Model 1. Preflight - Confirm `bash` and `python3` are available. - Confirm target file exists. 2. Run local validator - Default full pass: ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" "$PIPELINE_FILE" ``` - Syntax only: ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" "$PIPELINE_FILE" --syntax-only ``` - Best practices only: ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" "$PIPELINE_FILE" --best-practices ``` - Security only: ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" "$PIPELINE_FILE" --security-only ``` - Strict mode (warnings fail): ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" "$PIPELINE_FILE" --strict ``` 3. Interpret exit behavior - `0`: pass (or non-blocking checks only) - `1`: validation failed (blocking issues) - `2`: invalid invocation (missing/ambiguous file or bad args) 4. Return findings in the report format below. ## Expected Report Format (Severity Buckets) Always return results in this structure: ```text Validation Report: <path> Summary: - Blocking: <count> # Syntax errors + Security critical/high - Warning: <count> # Security medium/low + best-practice warnings - Info: <count> # Suggestions - Skipped: <count> # Explicitly name skipped checks Findings: - [Blocking][syntax][<rule-id>] line <n> - <message> - [Blocking][security-high][<rule-id>] line <n> - <message> - [Warning][security-medium][<rule-id>] line <n> - <message> - [Warning][best-practice][<rule-id>] line <n> - <message> - [Info][best-practice][<rule-id>] line <n> - <message> Remediation: - <short, concrete fix per finding> Execution Notes: - Commands run: <exact commands> - Environment/fallback notes: <tool missing, skipped checks, offline constraints> ``` ## Escalation Policy (Docs Only When Needed) Run local checks first. Escalate only when at least one condition is true: - Local finding depends on current upstream behavior (task versions, deprecations, new inputs). - User asks for "latest/current/recent" Azure Pipelines task or schema details. - Local scripts cannot determine validity for a specific task/resource syntax. Escalation order: 1. Context7 docs tooling first. ```text mcp__context7__resolve-library-id(...) mcp__context7__query-docs(...) ``` 2. Official docs second (`learn.microsoft.com` / Microsoft Azure DevOps docs). 3. General web search only if the first two are insufficient. When escalating, cite the source URL and state what local check could not answer. ## Fallback Behavior Use this matrix when tools are unavailable: - Condition: `yamllint` unavailable. - Action: Continue with syntax/best-practice/security checks. - Report note: "YAML lint skipped because yamllint is unavailable." - Condition: `python3` unavailable or venv/dependency setup fails. - Action: Mark scripted validation blocked; perform manual YAML review only if requested. - Report note: "Local scripted validation blocked by missing Python runtime/dependencies." - Condition: No network while dependencies/docs are needed. - Action: Run whatever local checks are still possible; defer doc/version verification. - Report note: "External verification deferred due offline environment." - Condition: Multiple auto-detected pipeline files. - Action: Do not pick arbitrarily; require explicit target file path. - Report note: "Validation paused until a single target file is specified." ## Rule Buckets (What the Scripts Check) Syntax examples: - `yaml-syntax` - `yaml-invalid-root` - `invalid-hierarchy` - `task-invalid-format` - `pool-invalid` - `deployment-missing-strategy` Best-practice examples: - `missing-displayname` - `task-version-zero` - `task-missing-version` - `pool-latest-image` - `missing-cache` - `missing-deployment-condition` Security examples: - `hardcoded-password` - `hardcoded-secret` - `curl-pipe-shell` - `eval-command` - `insecure-ssl` - `container-latest-tag` - `variable-not-secret` Use script output rule IDs directly in the report. ## References and Examples - Syntax reference: `docs/azure-pipelines-reference.md` - Example pipelines: `examples/` Quick local test: ```bash bash "$SKILL_DIR/scripts/validate_azure_pipelines.sh" "$SKILL_DIR/examples/basic-pipeline.yml" ``` ## Done Criteria This skill execution is done when all conditions are true: - Trigger match is explicit and plain-language examples are provided near the top. - Validation command(s) were run with unambiguous paths. - Report uses severity buckets (`Blocking`, `Warning`, `Info`, `Skipped`). - Fallback behavior is explicitly reported for unavailable tools/environment constraints. - External docs were consulted only when local checks were insufficient.
© akin-ozer · Apache-2.0 · akin-ozer/cc-devops-skills