Ticket-to-PR · Ein nachvollziehbarer Ablauf
Ticket-to-PR verbindet einen Softwareauftrag mit Änderungen im Repository und der Übergabe ins Review. Anvil Coder plant die Umsetzung, koordiniert Coding-Agenten und dokumentiert Prüfergebnisse. Im gehosteten Dienst entsteht ein Pull-Request-Entwurf, den euer Team vor dem Merge beurteilt.
Beschreibt Verhalten, Grenzen und Akzeptanzkriterien im internen Board oder angebundenen Tracker. Verknüpft das passende Repository und eure Projektregeln.
Der Auftrag wird in kleine Arbeitsschritte mit Abhängigkeiten zerlegt. Prüft offene Annahmen und konfiguriert die benötigten Freigaben.
Agenten erzeugen Commits. Konfigurierte Prüfungen liefern Befunde; Build und Tests benötigen eine verfügbare Toolchain.
Öffnet den Pull Request beim Git-Hoster. Prüft Diff, Akzeptanzkriterien und tatsächlich ausgeführte Checks vor eurer Merge-Entscheidung.
Beispielaufgabe · kein Benchmark
Der Titel allein lässt viele Entscheidungen offen. Diese Akzeptanzkriterien machen den Auftrag für Umsetzung und Review konkreter:
Die Übergabe sollte die Implementierung, Teständerungen und Prüfergebnisse zusammenbringen. Nicht ausgeführte Tests und offene Annahmen gehören in eure Review-Entscheidung.
Gebt dem Auftrag genug Kontext: betroffene Funktion, gewünschtes Verhalten, relevante Dokumentation und ausdrücklich ausgeschlossene Änderungen. Ein kleines, klar abgegrenztes Ticket erleichtert die Beurteilung des ersten Ergebnisses.
Bei einem grösseren Vorhaben beginnt ihr mit der Spezifikation und kuratierten Epics. Die Ticket-Erzeugung bereitet Arbeit vor; sie startet für sich allein keinen Coding-Lauf.
Verbindet drei Perspektiven: Was war beauftragt, was wurde geändert und was wurde geprüft? Die Commit-Historie hilft, die Umsetzung nachzuvollziehen. Der Laufbericht hält die ausgeführten Prüfungen und ihre Ergebnisse fest.
Ein bestandener Check deckt nur das ab, was er tatsächlich prüft. Fachliche Richtigkeit, angemessene Berechtigungen und unerwartete Auswirkungen beurteilt ihr weiterhin am konkreten Diff.