← ClaudeAtlas

azure-mergelisted

Run the Azure DevOps Symphony merge lane: publish or reuse an Azure DevOps PR, merge it, babysit relevant rollout proof, verify live behavior when scoped, and reconcile the tracker after proof is satisfied.
PedroAVJ/swe-stack · ★ 0 · DevOps & Infrastructure · score 70
Install: claude install-skill PedroAVJ/swe-stack
# Symphony Azure Merge Use this skill when Pedro wants the full Azure DevOps ship flow for a repo: branch, publish, PR, merge, rollout proof when relevant, tracker reconciliation, and worktree cleanup. This is the generic Azure DevOps lane. If the current repo has repo-local `merge`, `publish-changes`, release, or deployment skills, prefer those local rules for project-specific facts and then use this skill as the lifecycle shape. ## Required Repo Facts Derive these before mutating anything: - Azure DevOps organization URL from `git remote get-url origin`. - Project name from the remote URL or repo docs. - Repository name from the remote URL or repo docs. - Target branch from the remote default branch or repo docs. - Relevant pipeline names from `azure-pipelines.yml`, repo docs, or Azure CLI. - Relevant production/preview endpoints from repo docs or deployment config. - Tracker issue and terminal/review states when a tracker is involved. Do not hardcode facts from a different client or repo. ## Branch And Publish Policy - Always branch local work before publishing. - If local changes exist on the target branch, create `codex/{description}`. - If already on a feature branch, stay there unless Pedro asks otherwise. - Never commit directly to the target branch unless Pedro explicitly asks. - If the worktree is mixed, stage only intended files and ask when scope is ambiguous. - Use repo-local publish guidance when present. Otherwise use `azure-publish-changes`. ## Qu