IDD Skill: Workflow-Vorlage für Issue-Driven Development

Für wen es geeignet ist

• Entwickler und kleine Teams, die ihre tägliche Entwicklung im eigenen Git-Repository betreiben und „vom Issue bis zum Merge" als wiederholbaren Ablauf verankern wollen: Nach dem Import durchläuft der KI-Coding-Agent im Repository den offiziell beschriebenen Workflow – einsatzbereite Issues finden, die Verantwortung übernehmen, in einem Branch implementieren, einen PR öffnen, Review-Feedback bearbeiten, auf CI warten, gemäß der im Repository gewählten Merge-Richtlinie mergen und aufräumen. Das Projekt beschreibt den Workflow als „portabel": Er kommt mit dem Repository ins Haus, statt an ein einzelnes Werkzeug gebunden zu sein.
• Entwickler, die mehrere KI-Coding-Tools parallel nutzen und den Ablauf nicht auf einen einzelnen Client festlegen wollen: Laut offizieller Dokumentation läuft der Kernzyklus übergreifend auf GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode und Antigravity CLI (früher Gemini CLI).
• Teams, die mehrere Arbeitssitzungen parallel an unterschiedlichen Issues arbeiten lassen wollen: Laut offizieller Angabe ist die Standardrichtlinie im verteilten Modus fully_autonomous_merge, die Arbeitssitzungen bis zum Merge durchlaufen lässt; wie sich Sitzungen koordinieren und Konflikte vermeiden, wird offiziell nicht erläutert.
• Was sich vor der Einführung zu klären lohnt: Die offizielle Seite sagt nicht, ob Hosting-Plattformen außer GitHub unterstützt werden – dieser Punkt ist unbestätigt; wenn das Team vollautomatische Merges nicht akzeptiert, muss die Standardrichtlinie vorab bewertet oder angepasst werden, und wie das geht, wird offiziell nicht ausgeführt.

Der erste Versuch in 3 Minuten

• Voraussetzungen: ein Git-Repository, in dem du Branches anlegen und PRs öffnen darfst; dazu eine Umgebung mit den offiziell gelisteten Abhängigkeiten des kompletten Zyklus – git, ein authentifizierter gh CLI (oder eine gleichwertige GitHub-MCP-Integration, eins von beiden genügt), jq sowie ein REST-Client wie curl.
• Installationsort und -weg: Kein manuelles Kopieren von Dateien nötig. Der offizielle Weg besteht darin, dem KI-Agenten im Ziel-Repository direkt den Import-Befehl zu geben; der Onboarding-Leitfaden übernimmt das Kopieren der Vorlage.
• Auslösen: Im Repository einen unterstützten Agenten öffnen und diesen offiziellen Satz wortwörtlich eingeben:

Import and onboard github:kurone-kito/idd-skill's IDD into this repository.

• Den ersten Versuch auf risikoarme Schritte beschränken: Den Agenten den Workflow-Leitfaden lesen lassen, die vorhandenen einsatzbereiten Issues auflisten und den Plan für den nächsten Schritt erläutern lassen – ohne zu übernehmen und ohne Code zu ändern. Der offiziell beschriebene Zyklus beginnt genau mit „Leitfaden lesen, einsatzbereites Issue finden, übernehmen"; vor dem Übernehmen kannst du jederzeit stoppen.
• Erfolgssignal: Gibt der Agent die Kernpunkte des Workflows wieder und listet die vorhandenen Issues korrekt auf, greifen Import und Leitfaden; sind die Vorlagedateien ins Repository kopiert, ist das Onboarding abgeschlossen. Einen konkreten Ablagepfad nennt die offizielle Dokumentation nicht – maßgeblich ist die tatsächliche Ausgabe des Agenten (unbestätigt).

Anwendungsfälle

Fall 1: Ein einsatzbereites Issue komplett abliefern. Szenario: Im Backlog gibt es bereits als einsatzbereit markierte Issues, und du willst den geschlossenen Kreis vom Übernehmen bis zum Merge prüfen. Weisung an den Agenten: „Übernimm ein einsatzbereites Issue und schließe die Implementierung ab." Es durchläuft den offiziellen Gesamtzyklus – Workflow-Leitfaden lesen, Issue übernehmen, im Branch implementieren, PR öffnen, Review-Feedback bearbeiten, auf CI warten, gemäß der gewählten Merge-Richtlinie mergen und aufräumen. Beobachtbare Stationen in dieser Reihenfolge: ein Branch erscheint, der PR wird erstellt, der CI-Status ändert sich, Merge und Branch-Aufräumen – jeder Schritt entspricht einer festen Phase des offiziellen Zyklus. Unter der Standardrichtlinie fully_autonomous_merge läuft die Arbeitssitzung bis zum Merge durch; prüfe daher vor dem ersten Lauf, ob CI-Gates und Branch-Schutz stehen, oder lege in der Weisung ausdrücklich fest, dass diesmal beim PR Schluss ist.

Fall 2: Nur entdecken und planen, nichts verändern. Szenario: Du willst erst bewerten, ob der Ablauf zum Repository passt, und ihn noch nichts anfassen lassen. Weisung: „Lies den Workflow-Leitfaden, liste alle einsatzbereiten Issues mit einem Implementierungsansatz je Issue auf und übernimm nichts." Dabei wird nur die erste Hälfte des Zyklus genutzt (Leitfaden lesen, Issues finden); Branches oder PRs entstehen nicht. Wie Issues als „einsatzbereit" markiert werden, ist offiziell nicht erklärt; meldet der Agent eine leere Liste, prüfe zuerst, wie Issue-Status im Repository gesetzt werden. Zu erwarten sind eine Issue-Liste und ein Implementierungsplan als Text; ob implementiert wird, entscheidet deine nächste Weisung. Hältst du den Plan für tragfähig, nimm ein Issue heraus und durchlaufe mit ihm den vollen Zyklus wie in Fall 1.

Grenzen der Nutzung

• Nebenwirkungen und Bestätigungspunkte: Der Import kopiert Vorlagedateien ins Repository; ob dabei nur neue Dateien entstehen oder auch bestehende geändert werden, wird offiziell nicht gesagt – sieh dir nach dem Import zuerst die Änderungsliste des Agenten an. Der komplette Zyklus legt Branches an, committet Code, öffnet PRs und läuft unter der Standardrichtlinie fully_autonomous_merge bis zum Merge. Welche Aktionen vorher eine Bestätigung einholen, wird offiziell nicht aufgeschlüsselt; lege daher in jeder Weisung den erlaubten Rahmen ausdrücklich fest.
• Netzwerk- und Befehlszugriff: Der komplette Zyklus verlangt einen authentifizierten gh CLI bzw. eine gleichwertige GitHub-MCP-Integration und nennt REST-Clients wie curl – der Agent greift im Zyklus über diese Werkzeuge auf GitHub-Schnittstellen zu (Issues lesen, PRs erstellen und mergen usw.); welche Endpunkte genau und ob weiterer Netzwerkzugriff stattfindet, wird offiziell nicht aufgeschlüsselt.
• Laufzeitumgebung und Client-Voraussetzungen: Offiziell gelistet ist, dass der Kernzyklus übergreifend auf GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode und Antigravity CLI (früher Gemini CLI) läuft; ob Agenten außerhalb der Liste funktionieren, ob es zusätzliche Betriebssystem-Anforderungen gibt und ob bei fehlenden Abhängigkeiten ein eingeschränkter Betrieb möglich ist, bleibt offen.
• Offiziell genannte Grenzen und Unbekannte: Das offizielle Material erwähnt keine Unterstützung für Hosting-Plattformen außer GitHub und erklärt weder, welche Merge-Richtlinien es neben fully_autonomous_merge gibt, noch wie man zwischen ihnen wechselt; das Wiederholungsverhalten des Agenten nach CI-Fehlern ist ebenfalls unbestätigt. Maßgeblich für diese Details ist der Wortlaut des Workflow-Leitfadens, der ins Repository importiert wurde.