Wie man ein Issue dem Copilot-Coding-Agent zuweist
Der komplette Walkthrough für 2026: übergeben Sie ein GitHub-Issue an Copilots Coding-Agent — jetzt als Cloud-Agent dokumentiert —, sehen Sie zu, wie er plant, eine Draft-PR öffnet und Tests in GitHub Actions laufen lässt, dann reviewen, iterieren und mergen. Jeder Schritt ist auf die exakte Minute der Quellvideos gemappt.
TL;DR — Issues 2026 an Copilot zuweisen
- Zuweisen geht mit einem Klick: Issue öffnen, Assignees anklicken, Copilot wählen. Der Agent reagiert mit einem Eyes-Emoji, startet eine flüchtige GitHub-Actions-Umgebung und öffnet eine Draft-PR, der Sie aus der Issue-Timeline folgen können.
- GitHubs Doku nennt ihn jetzt Copilot Cloud Agent — dasselbe Produkt, das UI und Blogposts weiter Coding Agent nennen. Beide Namen funktionieren in der Suche, in Support-Threads und in diesem Guide.
- Sie brauchen einen bezahlten Copilot-Plan und Schreibzugriff aufs Repo. Gratis-Plan-Konten sehen Copilot gar nicht in der Assignees-Liste; bei Business und Enterprise muss ein Admin die Richtlinie erst aktivieren.
- Das Review bleibt menschlich: Copilot erbittet Ihr Review, wenn er fertig ist, @copilot-Kommentare schicken Änderungen zurück, und die PR wird erst nach menschlicher Freigabe gemergt. Der Demo-Lauf in diesem Guide dauerte 8 Min. 14 Sek.
Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository
Kanal: :The Code Wolf13:00
How to Get the Most Out of the Copilot Coding Agent
Kanal: :GitHub1:56
How the GitHub Copilot coding agent works | GitHub Checkout
Kanal: :GitHub6:58
Starting GitHub Copilot sessions
Docs: :docs.github.com
About the Copilot cloud agent
Docs: :docs.github.com
Die Frames in diesem Guide stammen aus den beiden sauberen Bildschirmaufnahmen oben; jeder Still wurde in voller Größe geprüft. Das GitHub-Checkout-Interview dient ausschließlich als Faktenquelle — seine Bildsegmente tragen das Kamera-Overlay des Presentators, daher wurden daraus keine Frames übernommen.
Screenshots werden zur Identifikation und für Kommentare verwendet. „Use GitHub Copilot Coding Agent to Solve Open Issues in a GitHub Repository“ © The Code Wolf; „How to Get the Most Out of the Copilot Coding Agent“ und „How the GitHub Copilot coding agent works“ © GitHub. Alle Produktnamen sind Marken ihrer jeweiligen Eigentümer.
Zuweisen, verfolgen, mergen: der 13-Schritte-Walkthrough
Bevor Sie das Issue zuweisen
- 1
Öffnen Sie den Issues-Tab des Repos und wählen Sie eine klar umrissene Aufgabe
Issues kommen meist vom Product Owner, vom Team oder aus der Community. Im Demo-Repo sind drei offen — ein Snowflake-Connector, sortierbare Spalten und benannte Favoriten. Jede davon ist ein Feature in Ein-PR-Größe, genau die Größe, die der Coding-Agent am besten meistert. Sie können mehrere Issues auf einmal zuweisen; jedes bekommt eigene Sitzung und eigene Draft-PR.
Der Issues-Tab des Demo-Repos mit drei offenen Community-Feature-Requests.Ansehen bei 9:31 - 2
Schreiben Sie Problem und Akzeptanzkriterien ins Issue
Copilot sieht nur den Issue-Titel, die Beschreibung und die Kommentare, die im Moment der Zuweisung existieren. Ein gutes Issue nennt das Problem, warum es zählt, und die Akzeptanzkriterien — GitHubs eigenes Beispiel listet Stichpunkt-Kriterien, die Erfolg überprüfbar machen. Vergessenes lässt sich nachtragen, aber nur als Kommentar am Pull Request, den Copilot stellt, denn das Issue liest er danach nicht erneut.
Ein klar umrissenes Issue: Beschreibung, Motivation und überprüfbare Akzeptanzkriterien.Ansehen bei 0:17 - 3
Prüfen Sie, ob der Agent für Ihr Konto aktiviert ist
Issues lassen sich nur mit einem bezahlten Copilot-Plan an Copilot zuweisen. Prüfen Sie github.com/settings/copilot/features — die persönliche Einstellungsseite listet Coding agent (Preview) unter Copilot in der Seitenleiste, neben den Enabled-Schaltern für Copilot in der CLI, Chat in GitHub Mobile und die anderen Editor-Preview-Features. Bei Copilot Business oder Enterprise muss ein Administrator die Richtlinie für die Organisation aktivieren, bevor die Option erscheint.
Die Copilot-Features-Seite, auf der Coding agent (Preview) seinen aktivierten Status zeigt.Ansehen bei 4:00
Das Issue an Copilot zuweisen
- 4
Öffnen Sie das Assignees-Menü und wählen Sie Copilot
Öffnen Sie das Issue und klicken Sie in der rechten Seitenleiste auf Assignees. Das Dropdown listet Personen plus additional options — darunter Copilot, untertitelt „Your AI pair programmer“. Wählen Sie es wie ein Teammitglied; die Doku weist darauf hin, dass das Zuweisen von Issues an Copilot in öffentlicher Preview und änderbar ist. Lieber die Tastatur? gh agent-task create (GitHub CLI 2.80.0 oder neuer, öffentliche Preview) startet dieselbe Art Sitzung aus Ihrem Terminal.
Das Assignees-Dropdown mit hervorgehobenem Copilot — Your AI pair programmer.Ansehen bei 4:16 - 5
Bestätigen Sie die Zuweisung und setzen Sie optionale Hinweise
Copilot sitzt jetzt neben menschlichen Assignees. Der Zuweisungsdialog bietet außerdem ein optionales Prompt-Feld für Kontext, Einschränkungen oder konkrete Anforderungen, Dropdowns für Ziel-Repository und Start-Branch — Sie brauchen Schreibzugriff aufs gewählte Repo, und der Cloud-Agent muss dort aktiviert sein — plus Auswahlfelder für Custom Agent, KI-Modell und Reasoning. Alles optional: ohne Extras startet Copilot allein mit dem Issue-Text.
Offizielles GitHub-Material, wie Copilot aus dem Assignees-Dropdown gewählt wird.Ansehen bei 0:04 - 6
Sehen Sie der Timeline zu, wie Copilot die Arbeit bestätigt
Innerhalb von Sekunden reagiert das Issue: Copilot setzt eine Eyes-Reaktion und ein „Copilot has started work“-Event landet in der Timeline. In dieser Aufzeichnung sehen Sie die Zuweisungs-Events, Copilots eigene Kommentare und — eine Minute später — „Copilot linked a pull request that will close this issue“ mit Verweis auf den neuen WIP-Entwurf. Per E-Mail gibt es ebenfalls Updates zum Sitzungsverlauf.
Issue-Timeline: Zuweisungs-Events, Copilot-Kommentare und der verlinkte WIP-Pull-Request.Ansehen bei 5:22
Den Hintergrundlauf verfolgen
- 7
Verfolgen Sie den Lauf in GitHub Actions
Der Cloud-Agent arbeitet in einer flüchtigen Umgebung auf GitHub-Actions-Basis. Öffnen Sie den Actions-Tab, dort finden Sie einen Lauf, der nach dem Issue benannt ist — hier „Fixing issue #5“ — mit einem copilot-Job, dessen Schritte Prepare Copilot, Start MCP Servers, Processing Request, Clean Up und Save Data heißen. Ein Reviewer muss womöglich „Approve and run workflows“ klicken, bevor Copilots Pushes Ihre CI ausführen.
Die laufenden Schritte des copilot-Jobs im GitHub-Actions-Lauf zum Issue.Ansehen bei 5:00 - 8
Öffnen Sie die Draft-PR, die Copilot stellt
Copilot schweigt nicht bis zum Schluss — er öffnet sofort einen Draft-Pull-Request und aktualisiert ihn laufend. Die Issue-Timeline verlinkt direkt dorthin („a pull request that will close this issue“), und der PR-Body beginnt als Kopie des Issues und füllt sich dann mit dem Plan des Agenten und abgehaktem Fortschritt. Behalten Sie ihn im Auge wie den Branch eines Kollegen.
Das Linked-Pull-Request-Event der Issue-Timeline zeigt auf die neue Draft-PR.Ansehen bei 5:31 - 9
Lesen Sie Copilots PR-Notizen
Am Ende liest sich der Draft-Pull-Request, als hätte ihn ein guter Kollege geschrieben: „Copilot wants to merge 3 commits into main from copilot/fix-5-4“, eine Sektion What's Added mit Kern-Implementierung, UI-Integration und Systemintegration, dazu eine Sektion Connection String Format. Die Seitenleiste zeigt „Copilot is done — completed after 8m 14s“. Dieser Lauf brauchte knapp neun Minuten von Anfang bis Ende.
Die selbstgeschriebene Beschreibung der Draft-PR mit der Laufzeit in der Seitenleiste.Ansehen bei 5:38
Review, Iteration, Merge
- 10
Untersuchen Sie den Files-changed-Diff
Der Files-changed-Tab zeigt jeden Commit des Agenten: hier sechs Dateien, darunter ein neues SnowflakeDatabaseService.cs mit 119 hinzugefügten Zeilen — eingeleitet von einem Kommentar, der die KI-Generierung vermerkt —, das NuGet-Paket in der csproj und der Service, registriert für Dependency Injection wie seine Oracle-, PostgreSQL- und SQL-Server-Geschwister. Lesen Sie ihn genau wie die PR eines Kollegen.
Files changed auf Pull Request 14: sechs Dateien und der neue generierte Service.Ansehen bei 12:15 - 11
Reviewen, wenn Copilot darum bittet
Abgeschlossene Sitzungen melden sich — ein Banner zeigt „Copilot requested your review on this pull request“ mit einem Add-your-review-Button. Kommentieren Sie einzelne Zeilen oder geben Sie ein normales Review ab; Copilot nimmt Review-Kommentare und @copilot-Erwähnungen von Personen mit Schreibzugriff auf und pusht neue Commits auf dieselbe PR. Folgeiterationen gehen schneller, weil er den Kontext früherer Sitzungen an diesem Pull Request behält.
Das Review-requested-Banner über Copilots eigener Changes-Made-Zusammenfassung.Ansehen bei 9:38 - 12
Mergen wie jeden anderen Pull Request
Sobald der Diff stimmt, mergen Sie normal. Die Merge-Box erinnert sogar daran, was das Schließen der PR bewirkt: „Successfully merging this pull request may close these issues“ — verknüpft mit dem Snowflake-Feature-Request, an dem der Agent arbeitete. Menschliche Freigabe ist das Tor; der Agent mergt nie selbst, und CI-Läufe brauchen womöglich den „Approve and run workflows“-Klick, bevor sie auf Copilots Commits laufen.
Die Merge-Box verknüpft den Pull Request zurück mit seinem Ursprungs-Issue.Ansehen bei 12:45 - 13
Künftige Läufe mit copilot-instructions.md steuern
Für dauerhafte Regeln ergänzen Sie eine .github/copilot-instructions.md — Konventionen, Build-/Test-/Lint-Schritte, Repo-Struktur. GitHubs eigenes Beispiel setzt Code Standards und eine Required-Before-Each-Commit-Checkliste, die mit npm run lint beginnt; die Code-Wolf-Demo verlangt gründliche, als KI gekennzeichnete Kommentare, und der nächste generierte Diff hält sich daran. MCP-Server für Tools jenseits von GitHub — Notion, Linear, Datenbanken — konfigurieren Sie auf der Copilot-Einstellungsseite des Repositorys.
Eine copilot-instructions.md mit Code-Standards, denen der Agent folgt.Ansehen bei 0:47
Voraussetzungen: Pläne, Berechtigungen und der Aktivierungsschalter
Drei Dinge bedingen die Option Assignees → Copilot. Erstens der Plan: laut GitHubs Doku ist „der Copilot Cloud Agent für alle bezahlten Copilot-Pläne verfügbar“ — Pro, Pro+, Business und Enterprise. Konten im Gratis-Plan sehen Copilot gar nicht in der Assignees-Liste — der häufigste Grund für die Annahme, das Feature fehle.
Zweitens die Aktivierung. Persönliche Konten prüfen die Features-Seite ihrer Copilot-Einstellungen (github.com/settings/copilot/features), wo Coding agent (Preview) unter Copilot in der Seitenleiste auftaucht. Bei Business und Enterprise muss „ein Administrator die entsprechende Richtlinie aktivieren“, bevor irgendjemand in der Org die Option bekommt — fehlt sie in einem Org-Repo, ist das ein Gespräch mit dem Admin, kein Bug.
- 1Ein bezahlter Copilot-Plan (Pro, Pro+, Business oder Enterprise) — Gratis-Plan-Konten haben keine Zuweisen-an-Copilot-Option
- 2Schreibzugriff auf das Ziel-Repository — Sie können nur Repos wählen, in die Sie schreiben dürfen und wo der Cloud-Agent aktiviert ist
- 3Der aktivierte Agent: github.com/settings/copilot/features für persönliche Konten, eine Org-weite Richtlinie für Business und Enterprise
- 4GitHub Actions im Repo verfügbar — der Agent läuft in einer flüchtigen, Actions-basierten Umgebung, und Enterprise Managed Users können ihn nicht in persönlichen Repos nutzen
Drittens die Laufzeit: Zuweisungen sind in öffentlicher Preview, jede Sitzung läuft in einer flüchtigen GitHub-Actions-Umgebung mit hartem 59-Minuten-Limit, und Internetzugriff aus der Sandbox ist standardmäßig gefiltert. Sitzungen, die stocken, laufen nach der Stunde in ein Timeout — der Fix ist, das Issue zu entziehen und neu zuzuweisen.
Sitzungs-Logs: zusehen, wie ein Hintergrund-Agent arbeitet
Jede Sitzung hinterlässt an drei Orten eine Log-Spur. Die Issue-Timeline hält Zuweisung, Copilots Kommentare und die verlinkte Draft-PR fest. Der Actions-Tab zeigt die internen Schritte des copilot-Jobs — Umgebung vorbereiten, MCP-Server starten, Anfrage verarbeiten, aufräumen. Und die PR selbst wird zur Statusseite des Agenten: Der Body beginnt als Kopie des Issues und füllt sich mit einem Plan, der beim Arbeiten abgehakt wird.
Polling ist unnötig. Copilot mailt, wenn die Draft-PR steht, und erneut, wenn er Ihr Review erbittet, und die Eyes-Reaktion plus das „Copilot has started work“-Event bestätigen in Sekunden, dass eine Sitzung wirklich läuft. Die Sitzungslog-Ansicht der Doku geht weiter: Sie können die Arbeit live verfolgen und den Pull Request sogar mit einem Klick aus den Logs öffnen.
In der Demo — ein moderates Feature, ein voller Snowflake-Datenbank-Connector über sechs Dateien — endete die Arbeit nach 8 Min. 14 Sek. Agentenzeit, der PR-Link erschien etwa neun Minuten nach der Zuweisung auf dem Issue. Einfache Änderungen kommen meist in wenigen Minuten zurück; alles, was nahe der Stunde noch läuft, gilt als festgefahren — neu zuweisen.
Iteration und Leitplanken: Kommentare, Instruktionen und MCP
Die Zuweisen-und-Review-Schleife geht davon aus, dass Copilots erster Entwurf nicht perfekt ist. Fünf Hebel formen das Ergebnis, ohne dass Sie je eine IDE öffnen:
- 1@copilot-Kommentare — erwähnen Sie @copilot in einem PR-Kommentar (Schreibzugriff nötig, nur offene PRs), und er startet eine Folgesitzung an derselben PR; einzelne Review-Kommentare lassen sich mit Fix with Copilot delegieren oder gesammelt abarbeiten
- 2copilot-instructions.md — eine .github/copilot-instructions.md trägt Ihre Konventionen, Build-/Test-/Lint-Befehle und Commit-Regeln in jede Sitzung; GitHubs eigenes Beispiel liefert eine Required-Before-Each-Commit-Checkliste
- 3MCP-Server — auf der Copilot-Einstellungsseite des Repos konfiguriert, geben sie dem Agenten Tools jenseits von GitHub; GitHubs Checkout-Demo zeigt ihn über MCP eine Notion-Produktspezifikation lesen
- 4Das optionale Prompt bei der Zuweisung — Kontext, Einschränkungen und konkrete Anforderungen, die mit dem Issue mitkommen
- 5Auswahlfelder für Custom Agent, Modell und Reasoning — pro Sitzung anders wählen im Zuweisungsdialog oder den Standard in den Einstellungen ändern
Die Leitplanken bleiben bei Ihnen: Änderungen sind auf ein Repository pro Sitzung beschränkt, der Agent kann seine eigene Arbeit weder genehmigen noch mergen, und Workflows, die er anstößt, warten auf „Approve and run workflows“, sofern Sie sie nicht auf die Allowlist setzen. Ihr PR-Review ist das Sicherheitsnetz — den Merge-Button drückt nie der Agent.