Ein Agent löst das Jira-Ticket, ein Mensch entscheidet, wo es darauf ankommt
#Für die meiste Arbeit an einem Jira-Ticket braucht es keinen Menschen: das Ticket und seine Anhänge lesen, die Stelle im Code finden, die Änderung schreiben und prüfen. In diesem Referenzprojekt erledigt ein einziger Skill all das. Ein Mensch entscheidet nur dort, wo ein Fehler etwas kosten würde. Er gibt den Plan frei, bevor sich eine Datei ändert, entscheidet über Vorschläge des Reviewers, die über den Plan hinausgehen, und gibt Commit und Push frei. Ist die Änderung gepusht, kommentiert der Skill das Ticket, setzt es auf «In Review» und gibt es an die Person zurück, die es erfasst hat.
Der Skill besteht aus schriftlichen Anweisungen, nicht aus Programmcode. Die Darstellungen unten zeigen seine Dateien und Regeln als Pseudocode – als Konzept, nicht als Quellcode. Zwei Dinge prägen den Skill: Ein kurzer Router verweist für jede der elf Phasen auf eine eigene Datei, und jeder Lauf hinterlässt eine Änderung im Working Tree und einen Kommentar im Ticket.
analyze-and-resolve-jira-issue/├── SKILL.md // der Router – eine Zeile pro Phase└── references/ // eine Datei pro Phase, einzeln geladenIst die Analyse unsicher, wird gefragt statt geplant
Die Analyse bewertet ihre eigene Konfidenz, bevor sonst etwas geschieht, und eine niedrige Bewertung führt zu Rückfragen statt zu einem Plan. Ohne diese Verzweigung schreibt der Skill einen überzeugten Plan auf eine Vermutung – das Teuerste, was er hervorbringen kann.
Konfidenz = hoch | mittel | niedrigniedrig heisst fragen; nie auf dieser Grundlage planennach zwei Fragerunden noch niedrig: abbrechenhoch heisst weiterhin: keine automatische UmsetzungDer Plan wird vor jeder Änderung bestätigt
Keine Datei ändert sich, bevor ein Mensch die vorgeschlagene Lösung gelesen und ihr zugestimmt hat. Konfidenz ist keine Zustimmung, und ein Skill, der diesen Schritt überspringt, ist nur schnell bis zum ersten Mal, an dem er falsch liegt.
Plan vorschlagen, dann auf Freigabe wartenfreigegeben: umsetzen, begrenzt auf dieses RepositoryDer Reviewer ist nicht der Autor
Die Umsetzung prüft ein eigener Agent, der mit leerem Kontext startet und nichts ändert. Läuft das Review im selben Kontext wie die Umsetzung, liest der Reviewer dieselben Überlegungen noch einmal, aus denen der Code entstanden ist, und gibt ihnen recht.
Review = frischer Kontext, nur lesendBefunde innerhalb des Plans: der Hauptlauf behebt sieVorschläge über den Plan hinaus: ein Mensch entscheidethöchstens zwei RundenEin Mensch an den Stellen, auf die es ankommt
Lesen und Analysieren laufen von selbst, und der Skill fragt nur nach, wenn er unsicher ist. Ein Mensch gibt den Plan frei und entscheidet über Vorschläge des Reviewers, die darüber hinausgehen. Er bestimmt, ob die Änderung von Hand geprüft wird, und gibt Commit und Push frei. Ohne diese letzte Freigabe verlässt nichts den Rechner.
Freigaben: Plan · Vorschläge darüber hinaus · manuelle Prüfung · Commit und Pushkeine Branches, kein Umschreiben, keine übersprungenen Hooksder Status bewegt sich erst, wenn die Änderung remote istDie Rückmeldung ist für die Person, die das Ticket erfasst hat
Der Kommentar am Ticket ist für die Person geschrieben, die es erfasst hat, und eine Prüfliste entfernt vor dem Absenden die Engineering-Rückstände. Ein Kommentar voller Dateipfade und Phasennummern berichtet den Prozess statt das Ergebnis.
Kommentar = fachliche Zusammenfassung, dann Detailsentfernen: Dateipfade, Kommandos, Commit-Hashes, Phasennummern, Subagenten, Iterationszähleroptional: was rund um die Änderung zu testen istEine Regel sorgt dafür, dass der Tracker stimmt. Ein Status darf sich erst bewegen, wenn die Änderung gepusht ist – so zeigt das Ticket nie einen Stand, den es auf dem Remote noch nicht gibt. Wird der Push abgelehnt, endet der Lauf sauber und das Ticket bleibt exakt so, wie es war: kein Kommentar, kein Statuswechsel, keine Neuzuweisung.
- 11Phasen, je eine Referenzdatei
- 3Entscheidungen, die ein Mensch in jedem Lauf trifft: Plan, manuelle Prüfung, Push