Deine Azure-DevOps-Work-Items,
bearbeitet vom Agenten deiner Wahl
Der Sprint lebt in Azure Boards. Die User Stories und Bugs, die dir zugewiesen sind, liegen dort, mit ihren Schritten zur Reproduktion, ihren Akzeptanzkriterien und ihren Screenshots. Was du willst, ist ein Agent auf jedem davon, auf deinem eigenen Rechner, in der CLI, die zur Aufgabe passt.
AgentsRoom importiert diese Work Items in das Backlog des Projekts, mit ihrer Beschreibung, ihren Schritten zur Reproduktion, ihren Akzeptanzkriterien und ihren angehängten Dateien. Jedes wird zu einem Ticket, das du an Claude Code, Codex, GitHub Copilot CLI, Cursor oder eine andere Agent-CLI übergibst, ein Agent pro Ticket. Der Import liest nur: Nichts wird je nach Azure DevOps zurückgeschrieben.
Zwei Azure-DevOps-Projekte, eine WIQL-Abfrage, ein Agent pro Ticket: Der Import liest Azure DevOps und schreibt nie hinein.
In Azure Boards planen viele Teams im Microsoft-Umfeld ihre Arbeit: das Backlog, den Sprint, den Bug, der heute Morgen hereinkam. In Claude Code, Codex und den anderen Agent-CLIs wird immer mehr dieser Arbeit erledigt. Dazwischen ist die übliche Methode Kopieren und Einfügen: der Titel in einen Prompt, die Schritte zur Reproduktion dahinter, die Screenshots gehen unterwegs verloren.
Der Azure-DevOps-Import übernimmt diesen Schritt für dich. Du verbindest deine Organisation mit einem persönlichen Zugriffstoken, wählst ein Projekt oder schreibst eine WIQL-Abfrage, siehst dir die Work Items in der Vorschau an und importierst sie. Sie landen als normale Tickets in der Spalte TODO des Projekt-Backlogs, mit Beschreibung, Schritten zur Reproduktion und Akzeptanzkriterien in Markdown umgewandelt und den angehängten Dateien heruntergeladen, und du startest auf jedem einen Agenten wie auf jedem anderen Ticket.
Es ist keine Synchronisation in beide Richtungen. AgentsRoom schickt nur Leseanfragen an Azure DevOps: keine Statusänderung, kein Kommentar, kein geändertes Feld. Wenn ein Agent ein Work Item kommentieren oder schließen soll, ist dafür der MCP-Server von Microsoft für Azure DevOps da, und beide arbeiten zusammen, wie weiter unten erklärt.
Was der Azure-DevOps-Import macht
Eine Quelle mehr für das Backlog, neben Jira, Linear, GitHub Issues und Notion.
Ein Projekt oder deine eigene WIQL
Wähle eines deiner Projekte aus der Liste, mit einem Suchfeld, wenn es Dutzende sind, und die Abfrage wird für dich geschrieben: alles, was in diesem Projekt noch offen ist, zuletzt Geändertes zuerst. Oder schreib die WIQL selbst: ein Bereichspfad, eine Iteration, ein Tag oder AND [System.AssignedTo] = @Me, um nur deine Work Items zu behalten.
Ein Work Item, über seine Nummer
Du brauchst nur den Bug, den du gerade bekommen hast? Füge 1234, #1234, AB#1234 oder den Link des Work Items über den Import-Button der Spalte TODO ein. Es kommt allein an, oben in der Spalte, ohne den gespeicherten Import anzutasten.
Schritte zur Reproduktion und Akzeptanzkriterien inklusive
Azure DevOps verteilt die Spezifikation auf mehrere HTML-Felder. Der Import wandelt die Beschreibung, die Schritte zur Reproduktion und die Akzeptanzkriterien in Markdown um und fügt dann einen kurzen Kontextblock hinzu: Typ, Status, Bereich, Iteration, Priorität, Story Points und übergeordnetes Element. Der Agent liest die Spezifikation so, wie das Team sie geschrieben hat.
Anhänge, die der Agent öffnen kann
An das Work Item angehängte Dateien und die in seinen Text eingefügten Bilder liegen hinter deinem Azure-DevOps-Login, ein Link würde dem Agenten also nichts nützen. Der Import lädt sie auf deinen Computer herunter und hängt sie an das Ticket, bis zu 10 pro Work Item.
Typ und Status, die Sinn ergeben
Bug, User Story, Product Backlog Item, Feature, Epic, Task: Die eingebauten Typen der Prozesse Basic, Agile, Scrum und CMMI werden dem Ticket-Typ zugeordnet, und der Typ des Work Items bleibt als Tag erhalten. Ob es erledigt ist, wird an der Kategorie des Status abgelesen, nicht an seinem Namen, sodass ein in deinem Prozess geschlossenes Work Item als erledigt ankommt, ob der Status nun Closed, Done oder bei dir ganz anders heißt.
Nur lesend, Token auf deinem Rechner
Das Token braucht zwei Lese-Scopes und nichts weiter. Es ist auf deinem Computer verschlüsselt und erreicht nie unsere Server; nur die Abfrage folgt dem Projekt auf deine anderen Rechner, wo du das Token erneut einfügst.
So funktioniert es
Vier Schritte. Die ersten beiden machst du einmal pro Rechner.
- 1
Ein persönliches Zugriffstoken erstellen
Öffne in Azure DevOps User settings, dann Personal access tokens, und erstelle ein Token für deine Organisation mit zwei Scopes: Work Items (Read) und Project and Team (Read). Nichts, was schreiben kann, ist nötig.
- 2
Deine Organisation verbinden
Klicke im Backlog des Projekts auf Tickets importieren und wähle Azure DevOps. Gib den Namen der Organisation ein (den Teil nach dev.azure.com/, oder füge die vollständige Adresse ein) und das Token.
- 3
Auswählen und Vorschau ansehen
Wähle ein Projekt oder schreib eine WIQL-Abfrage und klicke dann auf Vorschau. Durchsuche die Liste nach Nummer oder Titel, hake die Work Items an, die du willst, und importiere sie, bis zu 500 auf einmal.
- 4
Jedes Ticket an einen Agenten übergeben
Die Work Items sind jetzt Tickets in TODO, jedes mit einem Link zurück zu Azure DevOps. Weise einen Agenten und ein Modell zu, hake Für diese Aufgabe in einem separaten Worktree programmieren an, wenn es einen eigenen Branch bekommen soll, und zieh das Ticket nach In Progress. Aktualisieren bringt das Board später wieder auf Stand.
Was Microsoft und die Agent-CLIs schon von sich aus können
Microsoft veröffentlicht einen MCP-Server für Azure DevOps (microsoft/azure-devops-mcp auf GitHub). Für den lokalen Server nennt seine Dokumentation claude mcp add --transport stdio azure-devops -- npx -y @azure-devops/mcp contoso für Claude Code und codex mcp add azure-devops -- npx -y @azure-devops/mcp contoso für Codex, wobei contoso für den Namen deiner Organisation steht; standardmäßig öffnet sich ein Browser, damit du dich mit deinem Microsoft-Konto anmeldest. Der Agent bekommt dann aus seiner Sitzung heraus Tools für Work Items, Repositorys, Pipelines, Wikis und Testpläne.
Microsoft betreibt außerdem eine gehostete Version dieses Servers, allgemein verfügbar seit dem 5. August 2026. Laut der Ankündigung können sich Claude Code, Claude Desktop, ChatGPT und Cursor noch nicht damit verbinden, weil sie eine OAuth-Registrierung brauchen, die Microsoft Entra ihnen derzeit nicht anbietet, deshalb bleiben diese Nutzer beim lokalen Server. Azure Boards kann ein Work Item außerdem über den Copilot-Button des Work Items an den Coding-Agenten von GitHub Copilot schicken, allgemein verfügbar seit Dezember 2025: Der Code muss in einem GitHub-Repository liegen, und der Agent antwortet mit einem Pull Request als Entwurf auf GitHub, nicht mit einer Sitzung auf deinem Computer.
Der Import von AgentsRoom erfüllt ein anderes Bedürfnis: die Work Items auf einem Board, neben deinen übrigen Tickets, mit einem Agenten pro Work Item auf deinem eigenen Rechner und in der CLI deiner Wahl, auch in den CLIs, die überhaupt keine Azure-DevOps-Integration haben, und egal, ob der Code in Azure Repos, auf GitHub oder anderswo liegt. Beides schließt sich nicht aus: Importiere die Work Items, um die Arbeit zu planen und zu starten, und gib einem Agenten den MCP-Server von Microsoft, wenn er sein Work Item selbst kommentieren oder schließen soll.
Gut zu wissen
- Nur Azure DevOps Services (dev.azure.com). Azure DevOps Server, auf deinen eigenen Servern installiert, wird nicht unterstützt.
- Eine Organisation pro Computer. Um aus einer zweiten Organisation zu importieren, verbinde sie anstelle der ersten.
- Nur in eine Richtung: Nichts geht zurück an Azure DevOps, auch nicht, wenn das Ticket hier ausgeliefert ist. Schließe das Work Item selbst, oder gib dem Agenten den MCP-Server von Microsoft.
- Das Token bleibt auf dem Computer, der es verbunden hat. Auf einem anderen Rechner zeigt der Button des Boards Neu verbinden, mit einem Badge Azure DevOps nicht verbunden, bis du auch dort ein Token einfügst.
- Bis zu 500 Work Items pro Import und bis zu 10 angehängte Dateien pro Work Item.
- Kommentare, zugewiesene Person, Links außer zum übergeordneten Element und der Verlauf werden nicht importiert: Das Ticket enthält den Titel, die Beschreibung, die Schritte zur Reproduktion, die Akzeptanzkriterien, den Kontextblock, die Tags und die Dateien.
- Azure DevOps verbinden und die Abfrage schreiben passiert am Desktop. Vom Handy aus kannst du den Import aktualisieren oder ein Work Item über seine Nummer holen; beides läuft auf deinem Computer, der eingeschaltet sein muss.
Häufige Fragen
Ist das dasselbe wie der Azure-DevOps-MCP-Server von Microsoft?
Nein. Der MCP-Server von Microsoft gibt einem Agenten Tools, um Azure DevOps aus seiner Sitzung heraus zu lesen und zu ändern, auf den CLIs, die MCP unterstützen. Der Import von AgentsRoom holt die Work Items in das Backlog des Projekts, bevor ein Agent startet, damit du sie planen, jedes an einen anderen Agenten übergeben und auf dem Board verfolgen kannst. Du kannst beides nutzen: den Import, um die Arbeit zu organisieren, den MCP-Server für einen Agenten, der sein Work Item kommentieren oder schließen soll.
Kann Claude Code Azure DevOps nutzen?
Ja, auf zwei Wegen. In einer Sitzung fügst du den lokalen MCP-Server von Microsoft mit claude mcp add --transport stdio azure-devops -- npx -y @azure-devops/mcp contoso hinzu (mit dem Namen deiner Organisation anstelle von contoso): Der Agent kann dann selbst Work Items suchen, lesen und aktualisieren. Der gehostete MCP-Server von Microsoft akzeptiert Claude Code laut seiner Ankündigung vom 5. August 2026 noch nicht. Vor der Sitzung importierst du die Work Items in AgentsRoom und übergibst jedes an einen Claude-Code-Agenten: Die Beschreibung, die Schritte zur Reproduktion, die Akzeptanzkriterien und die Dateien erreichen den Agenten mit seiner Aufgabe.
Aktualisiert AgentsRoom das Work Item, wenn der Agent fertig ist?
Nein. Der Import schickt nur Leseanfragen, mit einem Token, das nur Lese-Scopes hat: keine Statusänderung, kein Kommentar, kein geändertes Feld. Wenn das Ticket hier ausgeliefert ist, verschiebst du das Work Item selbst in Azure DevOps, oder du lässt einen Agenten das über den MCP-Server von Microsoft erledigen.
Kann ich nur die Work Items importieren, die mir zugewiesen sind?
Ja, mit WIQL: Wähle das Projekt und füge dann AND [System.AssignedTo] = @Me zu der Abfrage hinzu, die dabei für dich geschrieben wird. Du kannst auch nach einem Iterationspfad, einem Bereichspfad oder einem Tag filtern. Die Abfrage wird mit dem Projekt gespeichert, sodass Aktualisieren sie später erneut ausführt.
Kann ich nur das Work Item holen, das mir gerade zugewiesen wurde?
Ja. Nutze den Import-Button der Spalte TODO und füge seine Nummer (1234, #1234 oder AB#1234) oder seinen Link ein. Es landet oben in TODO, ohne den gespeicherten Import zu ändern, und lässt sich später einzeln vom Ticket aus aktualisieren.
Verlässt mein Azure-DevOps-Token meinen Computer?
Nein. Es wird verschlüsselt auf dem Computer gespeichert, der es verbunden hat, zusammen mit dem Namen der Organisation, und erreicht nie unsere Server. Anhänge werden nur von der verbundenen Organisation heruntergeladen, das Token wird also nie an einen anderen Host geschickt. Nur die Import-Abfrage wird in deinem Konto gespeichert, damit der Import dem Projekt auf deine anderen Rechner folgt, wo du das Token erneut einfügst.
Welche Agent-CLIs können an einem importierten Work Item arbeiten?
Alle 17 Agent-CLIs, die AgentsRoom unterstützt (Claude, Codex, GitHub Copilot CLI, Cursor und 13 weitere). Ein importiertes Work Item ist ein normales Ticket: Es läuft auf dem Agenten und dem Modell, die du ihm zuweist, im gemeinsamen Checkout oder in seinem eigenen Git-Worktree.
Funktioniert es mit Azure DevOps Server oder Team Foundation Server?
Derzeit nicht. Der Import spricht mit Azure DevOps Services auf dev.azure.com. Teams mit Azure DevOps Server, auf ihren eigenen Servern installiert, können einem Agenten trotzdem einen Azure-DevOps-MCP-Server geben, der ihre Installation unterstützt.
Das könnte dich auch interessieren
Ticket-Import
Hol deine Tickets aus Jira, Linear, GitHub Issues, Azure DevOps oder Notion in ein Backlog und übergib jedes an Claude Code, Codex, Cursor oder eine andere Agent-CLI auf deinem eigenen Rechner. Nur lesend.
Jira-Import
Importiere Jira-Cloud-Issues in AgentsRoom und übergib jede an Claude Code, Codex, Cursor oder eine andere Agent-CLI auf deinem eigenen Rechner. Projekt oder JQL, mit Anhängen. Nur lesend.
Aufgabenverwaltung
Visuelles Kanban-Board, um KI-Agenten per Drag-and-drop zu orchestrieren. Lege Aufgaben in TODO an, zieh sie nach In Progress, um automatisch einen Claude-Agenten zu starten, und verfolge den Fortschritt über die Spalten Pending und Done. Backlog-getriebene Entwicklung für paralleles KI-Coding.
Git-Worktrees
Gib jedem KI-Agenten oder Ticket einen eigenen Git-Worktree, bereit zum Bauen (Abhängigkeiten installiert, .env kopiert), dann prüfe, committe und merge ihn in einem einzigen Fenster.
MCP-Server
Deklariere einen MCP-Server einmal und gib ihn an Claude Code, Codex und jedes Agent-CLI weiter. Wähle ihn aus dem offiziellen MCP-Register, bewahre Schlüssel im Secret Manager auf und melde dich bei OAuth-Servern wie Notion oder Linear mit einem einzigen Verbinden-Button an.
Bring deine Azure-DevOps-Work-Items zu deinen Agenten
Lade AgentsRoom herunter, öffne dein Repository als Projekt, klicke dann in seinem Backlog auf Tickets importieren und wähle Azure DevOps.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutze Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.