Azure DevOps plugin for GitHub Copilot adds pull request and work item management

Microsoft has released an Azure DevOps plugin for the GitHub Copilot app, letting developers view and manage pull requests and work items without leaving the Copilot interface. The plugin, announced by Dan, a product manager for Azure Boards, Repos & Wiki, is available through the app's Customize menu under the Editor's picks tab.

The initial release covers a narrow set of operations. Users can see their assigned work items and open pull requests from a "My Work" view, open either type of item, edit work items, and edit or complete pull requests. The announcement states the value plainly: you can act on assigned work without switching to a separate Azure DevOps surface.

Setup requires a few steps. After installing the plugin, users start a new session from chat or the plugin card, sign in, and provide their Azure DevOps organization and project information. The plugin then surfaces their open pull requests and work items. There is no indication yet of how the plugin handles multiple organizations or projects, or whether switching between them requires re-entering details.

The announcement acknowledges the plugin's early state. It is described as being "in its early stages" with "functionality currently limited," and Microsoft says it plans to add more capabilities over time. What those capabilities might be is unspecified; the post invites users to suggest scenarios in comments or file issues in the GitHub app repository. There is no mention of actions like creating work items, commenting on pull requests, or viewing repository-level activity, which would be plausible candidates for future releases.

GitHub Copilot already has access to other third-party integrations, and Azure DevOps remains a widely used ALM tool, particularly in enterprise settings. For teams that run Azure DevOps for work tracking and pull requests, the plugin removes a few context switches. But the feature set is deliberately modest, and the announcement does not claim any workflow transformation.

One open question is how the plugin handles authentication and permissions beyond the initial sign-in, or whether it respects Azure DevOps access controls per user. Another is performance: whether the plugin's views update in real time or require manual refresh. These details matter for daily use, and their absence suggests the plugin is not yet positioned as a full replacement for the Azure DevOps web interface.

For now, the plugin is best understood as an early integration that handles the most common "what is assigned to me and what do I do with it" tasks. Microsoft has committed to expanding it, but has not said when or with what. Teams evaluating it should expect a limited tool that works for basic pull request and work item triage, and should treat anything beyond that as unconfirmed.