Anvil CoderAnmelden

Ticket-to-PR · Ein Weg ohne Rekonstruktion

Vom Ticket zum Pull Request mit KI

Sechs Agenten-PRs à 800 Zeilen in der Queue, keine Spur, warum. Standup in einer Stunde. Anvil Coder liefert das Gegenteil: ein Ticket wird zu einer Kette kleiner, benannter Commits, jeder mit dem Auftrag, unter dem er entstand, übergeben als Draft-Pull-Request in dein Repository. Der Reviewer liest, statt zu raten.

Vier Schritte, einer davon ist deiner

  1. Du ziehst das Ticket

    Im internen Board oder in Jira, YouTrack, GitHub oder GitLab: eine Story auf „Bereit“ ziehen genügt. Mehr Startknopf gibt es nicht.

  2. Der Plan entsteht

    Der Auftrag wird in kleine Arbeitsschritte mit Abhängigkeiten zerlegt. Offene Punkte stehen als Annahmen im Lauf, nicht versteckt im Code.

  3. Agenten bauen

    Jeder Arbeitsschritt läuft unter denselben Guardrails, wird gebaut und getestet und hinterlässt seinen Commit. Was durchfällt, wird repariert, bevor es weitergeht.

  4. Du reviewst

    Der Draft-PR liegt bei deinem Code-Host. Diff, Akzeptanzkriterien und Prüfprotokoll stehen beieinander. Du merged, wenn es passt.

Ein Ticket, wie es im Backlog liegt

Beispiel

CSV-Export für die gefilterte Bestellliste

Der Kunde fragt seit zwei Wochen danach, das Team hat keine Luft. Der Titel allein lässt vieles offen; vier Sätze Akzeptanzkriterien machen daraus einen Auftrag, den eine Maschine ausführen und ein Mensch beurteilen kann:

Am nächsten Morgen liegt der Draft-PR da: Endpoint, Service, Tests, Doku, vier Commits. Das Prüfprotokoll zeigt, was lief. Dein Review dauert so lange wie ein Kaffee.

Was ein gutes Ticket braucht

Genug Kontext für jemanden, der dein Projekt nicht kennt: betroffene Funktion, gewünschtes Verhalten, was ausdrücklich nicht geändert werden soll. Klein und klar abgegrenzt ist für den ersten Auftrag besser als ambitioniert.

Für ein grösseres Vorhaben beginnst du im Spec-Studio: Aus der Spezifikation werden Epics und Stories, die du kuratierst, bevor eine davon läuft.

Von der Spezifikation zu Tickets

Was du im Review siehst

Drei Dinge nebeneinander: Was war beauftragt, was wurde geändert, was wurde geprüft. Die Commit-Historie erzählt die Umsetzung Schritt für Schritt; der Laufbericht hält die ausgeführten Prüfungen fest.

Ein Check deckt, was er prüft. Ob die Lösung fachlich die richtige ist, bleibt deine Entscheidung, und genau dafür hast du jetzt wieder Zeit.

Den ganzen Weg im Blog nachlesen

Fragen vor dem ersten Lauf

Können wir unseren Tracker behalten?
Ja. Internes Board, YouTrack, GitHub Issues, Jira Cloud und GitLab Issues werden in beide Richtungen angebunden. Der Lauf startet, wenn du eine Story auf den Trigger-Zustand ziehst.
Merged Anvil Coder automatisch?
Nein. Das Ergebnis kommt als Draft-PR, und ein Mensch merged. Zusätzliche Freigabepunkte während des Laufs stellst du je Projekt ein.
Was, wenn Tests nicht laufen konnten?
Dann steht das im Laufbericht, und der PR ist als unverifiziert markiert. Du ergänzst die Toolchain im Stack-Profil oder lässt deine CI prüfen, bevor du merged.