# Ado Pr Publish Flow

> End-to-end Azure DevOps PR publish workflow for Andromeda.iOS. Use when asked to commit and push all current changes, verify conflict risk against latest remote dev, resolve and re-commit if conflicts exist, and open a PR to dev with Azure CLI. Enforce branch naming `users/andreym/{ticketNumber}-some-short-explanation`, PR title naming `{ticket type}

- Skill: `akmarinov/ado-pr-publish-flow` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add akmarinov/ado-pr-publish-flow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/akmarinov/ado-pr-publish-flow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: akmarinov (https://skillmd.com/u/akmarinov)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/akmarinov/ado-pr-publish-flow

---


# Ado Pr Publish Flow

## Overview

Publish the current branch to Azure DevOps with consistent naming, linking, and conflict handling rules.
Complete the flow in one pass: commit, push, check conflicts against `origin/dev`, resolve if needed, create PR, and return the PR URL.
Run git history-changing steps sequentially, never in parallel (especially `commit` and `push`).

## Workflow

### 1) Collect context and normalize work item IDs

1. Read current branch: `git rev-parse --abbrev-ref HEAD`.
2. Resolve Azure DevOps defaults if needed:
   - `az devops configure --defaults organization=https://dev.azure.com/TCMD project=Andromeda`
3. Determine in-scope AB IDs from user input first.
4. If IDs are not explicitly provided, infer from:
   - Branch pattern `users/andreym/<id>-...`
   - Existing commit text containing `AB#<id>`
5. Fetch each ID with relations:
   - `az boards work-item show --id <id> --expand relations -o json`
6. Build two ID sets:
   - Commit link IDs: all in-scope IDs.
   - PR link IDs: all provided/in-scope IDs, plus parent IDs for any provided child item.

### 2) Enforce branch naming convention

1. Required pattern for features/bugs:
   - `users/andreym/{ticketNumber}-some-short-explanation`
   - Example: `users/andreym/1111-localization`
2. If creating a new branch for a ticket, base it on latest `origin/dev`:
   - `git fetch origin dev`
   - `git switch -c users/andreym/<firstId>-<short-slug> origin/dev`
3. If the current branch does not match and you have at least one AB ID, create a compliant branch from the current `HEAD` only when explicitly continuing pre-existing work.
4. If the current branch already matches, keep using it.

### 3) Commit and push all current changes

1. Stage all current changes:
   - `git add -A`
2. Generate a concise commit subject from the diff:
   - Base on changed files and the dominant intent.
   - Keep the subject short and specific.
3. Ensure the commit message includes AB linking with `Fixes AB#...`.
4. Use this format:
   - Subject: `<TicketType> #<id>[ #<id>...]: <short change summary>`
   - Body/footer: `Fixes AB#<id> AB#<id> ...`
5. Normalize `<TicketType>` for commit subjects to `Infra`/`Feature`/`Bug` (never `Task`) using the same mapping rules as PR titles.
6. Push (sequentially after commit; do not run in parallel with commit):
   - `git push -u origin <current-branch>`
7. Verify push propagated to remote before creating PR:
   - `git fetch origin`
   - `git rev-parse HEAD`
   - `git rev-parse origin/<current-branch>`
   - If SHAs differ, push again and re-check.

### 4) Check conflict risk against latest `origin/dev`

1. Fetch latest target branch:
   - `git fetch origin dev`
2. Detect conflict risk without modifying history:
   - `BASE=$(git merge-base HEAD origin/dev)`
   - `git merge-tree "$BASE" HEAD origin/dev | rg '<<<<<<<|>>>>>>>'`
3. If no conflict markers are found, continue to PR creation.
4. If conflict markers are found:
   - Merge latest dev into current branch: `git merge origin/dev`
   - Resolve conflicts in files.
   - Stage resolved files: `git add <resolved-files>`
   - Commit conflict resolution with AB linking:
     - Subject: `Infra #<id>[ #<id>...]: Resolve merge conflicts with dev`
     - Body/footer: `Fixes AB#<id> AB#<id> ...`
   - Push updated branch again.

### 4.5) Validate PR branch contains only intended commits

1. Inspect divergence from target:
   - `git log --oneline --left-right origin/dev...HEAD`
2. Confirm commits on the `>` side are in scope for the current ticket(s).
3. If unrelated commits are present:
   - Rebase/cherry-pick onto latest `origin/dev`.
   - Prefer `git rebase --onto origin/dev <old-base> <current-branch>` when linear cleanup is straightforward.
   - Otherwise create a clean branch from `origin/dev`, cherry-pick intended commits, then force-push with lease:
     - `git push --force-with-lease origin <current-branch>`

### 5) Build PR title and description with naming/linking rules

1. Use PR title format:
   - `{ticket type} #{ticket number}: {name of story}`
2. Ticket type rules:
   - PR titles may only use: `Infra`, `Feature`, `Bug` (never `Task`).
   - Use type from Azure Boards when available, then normalize to one of: `Infra`, `Feature`, `Bug`.
   - If Azure Boards returns `Task`, resolve the parent work item type and use it when it maps to `Infra`/`Feature`/`Bug`.
   - If parent type is missing or still not mappable, default PR title type to `Feature`.
3. Ticket number rules:
   - Include all provided work item ticket numbers.
   - Do not include parent-only ticket numbers in the PR title.
   - Multiple numbers format example: `Bug #1234 #5678: Fix login crash`
4. Story name rule:
   - Use the primary story/work item title or a short meaningful explanation.
5. PR description must be Markdown and include:
   - What changed
   - Why it changed
   - How it was validated
   - Links section with `Fixes AB#...`
6. PR link policy:
   - In commit(s): include `Fixes AB#...` for all in-scope IDs.
   - In PR: include all provided item IDs in `Fixes AB#...`.
   - If a provided item has a parent, include that parent ID too.
   - Parent IDs are linked as PR work items only and are not added to the PR title.

### 6) Create PR with Azure CLI

1. Write PR description to a markdown file (for example `pr.md`).
2. Create the PR to `dev`:
   - `az repos pr create --repository Andromeda.iOS --source-branch <current-branch> --target-branch dev --title "<title>" --description @pr.md --work-items <pr-link-ids> --delete-source-branch true`
3. Return the PR URL from command output.
4. Remove temporary `pr.md` after PR creation.

## Output requirements

1. Report:
   - Current branch used
   - Commit(s) created
   - Whether conflicts were detected/resolved
   - Final PR title
   - Final PR URL
2. If required metadata is missing (for example no AB ID), fail fast and state what is missing.
3. Never skip naming or linking conventions.