Pbi Dispatcher Ado Swe

PBI Dispatcher — ADO (Copilot SWE)

Dispatch work items to the Copilot SWE agent for ADO-hosted repos. The agent is triggered by tagging the work item with the target repo and assigning it to GitHub Copilot. This skill is for ADO repos only. For GitHub repos, use pbi-dispatcher-github.

Configuration

Read .github/orchestrator-config.json for:

• modules — module-to-repo mapping (each module has a repo key)
• repositories — repo details: slug (org/project/repo), baseBranch, host
• ado.org — ADO organization name
• ado.project — ADO project name

To resolve a module to dispatch details:

1. Look up modules.<module>.repo → get the repo key
2. Look up repositories.<repo> → get slug, baseBranch
3. Parse the slug to extract org, project, and repo name

Prerequisites

• ADO MCP Server running — for updating work items
• Copilot SWE agent enabled/onboarded for the target ADO repository
• Work items with clear descriptions (from the pbi-creator skill)

Workflow

1. Read Work Items

Read PBI details from ADO (via MCP) or from chat context. Need:

• AB# ID (work item ID)
• Target repo module
• Full description should already be on the work item (set by pbi-creator)

2. Check Dependencies

For each work item, check if dependencies (other AB# IDs) have merged PRs. Skip blocked items.

2a. Gather Cross-PBI Context for Dependencies

For each work item that HAS dependencies on already-merged PBIs, enrich the work item description with context about what those dependencies changed. This helps the Copilot SWE agent understand what preceding PBIs introduced.

For each merged dependency, query the linked PR (check the work item's links or search):

Use mcp_ado_wit_get_work_item to read the dependency work item and check for linked PRs.

If a merged PR is found, append to the work item description (via mcp_ado_wit_update_work_item):

## Dependency Context

This work item depends on already-merged changes:

### AB#<dep-id>: <dep-title> (PR merged)
Key changes introduced: [summary from PR title and description]
Build on these changes. Do NOT duplicate or re-implement what the dependency already added.

If no linked PR is found, skip — the PBI description is still self-contained.

3. Tag Work Item with Target Repository

Add a tag to the work item using the format:

copilot:repo=<org>/<project>/<repo>@<branch>

Use mcp_ado_wit_update_work_item to add the tag:

{
  "id": <work-item-id>,
  "fields": [
    {
      "name": "System.Tags",
      "value": "<existing-tags>; copilot:repo=<org>/<project>/<repo>@<branch>"
    }
  ]
}

Building the tag value from config:

• The repo slug in config is org/project/repo format
• The base branch comes from repositories.<repo>.baseBranch
• Example: slug msazure/One/AD-MFA-phonefactor-phoneApp-android, branch working → tag: copilot:repo=msazure/One/AD-MFA-phonefactor-phoneApp-android@working

⚠️ IMPORTANT:

• Use only ONE linking method per work item — the tag OR an artifact link, not both
• Only one repository can be linked per work item
• The branch after @ is required — use the base branch from config
• Append the new tag to existing tags (semicolon-separated), don't overwrite them. Read existing tags first via mcp_ado_wit_get_work_item, then append.

4. Assign to GitHub Copilot

Use mcp_ado_wit_update_work_item to assign the work item to GitHub Copilot:

{
  "id": <work-item-id>,
  "fields": [
    {
      "name": "System.AssignedTo",
      "value": "GitHub Copilot"
    }
  ]
}

Note: The display name is GitHub Copilot. If this doesn't work, the identity may be registered differently in the org. Check with the user.

5. What Happens Next

After assignment, the Copilot SWE agent will automatically:

1. Create a draft/WIP PR in the target repo
2. Add a comment to the work item with the PR link
3. Link the PR to the work item
4. Begin implementing the solution from the work item description

The agent uses .github/copilot-instructions.md in the target repo for coding conventions.

6. Update Orchestrator State

$su = Join-Path $HOME ".feature-orchestrator" "state-utils.js"
node $su set-step "<feature>" monitoring

Note: The PR URL won't be available immediately — the agent takes a few minutes to create the draft PR. The user can check status later via the Monitor phase.

7. Report Summary

## Dispatch Summary

| AB# | Repo | Method | Status |
|-----|------|--------|--------|
| AB#12345 | org/project/repo | Copilot SWE | ✅ Tagged & assigned to GitHub Copilot |
| AB#12346 | org/project/repo | Copilot SWE | ⏸ Blocked (waiting on AB#12345) |

### What to Expect
- The Copilot SWE agent will create a **draft PR** in a few minutes
- It will add a comment on the work item with the PR link
- Once the PR is published, review the changes and add comments to iterate
- Tag `@GitHub Copilot` in PR comments to request changes

### Next Step
> Check back in a few minutes and say **"status"** to see if the PR has been created.
> Or open the work item in ADO to see the agent's comment with the PR link.

Iterating on the PR

After the agent creates the PR:

• Add comments at the PR level or on specific files
• Tag @GitHub Copilot in PR comments (the agent won't act without the explicit tag)
• If ADO doesn't auto-complete the @-mention, type the literal text @<GitHub Copilot>
• The agent will create a new iteration with updates

Error Handling

"Repository is not yet onboarded"

The target repo needs to be onboarded to the Copilot SWE pilot program. Guide the user to follow their org's onboarding process.

Assignment fails

The GitHub Copilot identity may not be available in the org. Check:

• Is Copilot SWE enabled for this ADO organization?
• Is the identity name different? (Try searching for "Copilot" in the assignee field)

Tag format errors

Ensure the tag follows exactly: copilot:repo=<org>/<project>/<repo>@<branch>

• No spaces around = or @
• Branch name is required
• Org/project/repo must match exactly what's in ADO