g-ki/agent-skills – Aufgabe implementieren

Aufgabe implementieren

Liefere ein 1-Punkt-Ticket als PR zur Überprüfung aus, der genau das enthält, was das Ticket verlangt – und nicht mehr.

Eingabe

$ARGUMENTS

• Ticket, erforderlich: ein Tracker-Key (z. B. ENG-123) oder eine lokale ID (z. B. T-04). Falls nicht angegeben, liste die bereiten Tickets (Status open, Abhängigkeiten gemerged) auf, kritischer Pfad zuerst, und frage, welches bearbeitet werden soll. Im unbeaufsichtigten Modus melde stattdessen blocked.
• --tasks <datei>: die lokale Aufgaben-Datei. Falls nicht angegeben, suche nach der *.tasks.md, die das Ticket enthält, im lokalen, git-ignorierten RFC-Ordner des Projekts (z. B. .rfcs/), dann docs/rfcs/.
• --base <branch>: der Branch, von dem ausgegangen und auf den der PR abzielen soll. Standard ist main. Ein nicht-main base bedeutet, dass der PR auf einem anderen ungemergten PR gestapelt ist.
• --branch <name>: der zu verwendende Branch-Name. Andernfalls folge der Namensregel in Schritt 1.
• --feedback <pr>: nicht implementieren, sondern Review-Feedback zu einem bestehenden PR adressieren (siehe letzter Abschnitt).
• --unattended: du wurdest von einem Orchestrator gestartet und niemand kann Fragen beantworten. Frage nie; wenn du fragen würdest, stoppe und erkläre im Bericht. Arbeite in deinem eigenen Worktree.

Wo das Ticket und lokale Dateien leben

• Tracker zuerst. Wenn das Ticket einen Tracker-Key hat (als Argument oder im Feld Tracker: der Aufgaben-Datei), hole es über das verbundene Tracker-Tool (Linear, Jira, GitHub Issues, …). Wenn es veröffentlicht wurde, ist der Tracker die Quelle der Wahrheit für den Inhalt des Tickets; wenn es dort abgebrochen oder erledigt ist, stoppe und berichte.
• Andernfalls die lokale Aufgaben-Datei und für Felder, die das Tracker-Issue nicht hat (Dateien, nicht zum Umfang gehörend). RFCs und Aufgaben-Dateien sind lokale, unversionierte Dokumente des Entwicklers, die nur im Hauptprojektordner existieren, nicht in einem Worktree. Wenn du in einem Worktree bist, finde den Hauptordner mit git worktree list (erster Eintrag) und lies die Dateien dort mit absolutem Pfad. Behandle den Hauptordner als schreibgeschützt: bearbeite niemals, checke aus oder führe git-Befehle darin aus.
• Committe niemals RFC-, Notizen- oder Aufgaben-Dateien. Stage Dateien mit explizitem Pfad, nicht mit git add -A.

1. Das Ticket auswählen

• Lese das Ticket (siehe oben), einschließlich seiner Akzeptanzkriterien und Abhängigkeiten. Wenn sein Typ spike ist, stoppe: Spikes liefern eine Entscheidung, keinen PR; verweise auf /spike-task (unbeaufsichtigt: melde blocked).
• Eine Abhängigkeit ist erfüllt, wenn ihr PR in main gemerged ist (überprüfe den PR-Status mit gh oder den Status der Abhängigkeit pr-merged/done), oder wenn der Basis-Branch der eigene Branch dieser Abhängigkeit ist (Stacking). Eine Spike-Abhängigkeit ist nur erfüllt, wenn sie done ist, d. h. ihre Entscheidung wurde genehmigt und das Backlog verfeinert. Wenn eine Abhängigkeit nicht erfüllt ist, stoppe und nenne sie.
• Stelle sicher, dass der Arbeitsbaum sauber ist, führe fetch aus und erstelle den Branch vom neuesten origin/<base>.
• Branch-Name (es sei denn, --branch wurde angegeben): <benutzername>/<projekt-slug>/<aufgaben-branch>.
  • benutzername: das Präfix der bestehenden Branches des Benutzers, wenn sie diesem Muster folgen, andernfalls sein GitHub-Login (gh api user --jq .login).
  • projekt-slug: aus dem Header Project slug: der Aufgaben-Datei oder der RFC-Name in kebab-case.
  • aufgaben-branch: der Tracker-Key plus ein kurzer Slug, z. B. eng-123-add-v2-flag (der Key ermöglicht Tracker-Integrationen, den PR zu verlinken), oder t-04-add-v2-flag, wenn nicht veröffentlicht.
• Wenn du direkt mit dem Benutzer arbeitest (nicht unbeaufsichtigt), setze den Status des Tickets in der Aufgaben-Datei auf in progress und im Tracker, wenn dessen GitHub-Integration dies nicht tut.

2. Nur das laden, was das Ticket braucht

Lese das Ticket, den RFC-Abschnitt, auf den es sich stützt, und die Dateien, die es nennt. Verfolge dann den tatsächlichen Ablauf: Aufrufer, vorhandene Helfer und die Tests neben dem zu ändernden Code. Lese genug, um das Problem vollständig zu verstehen, aber lade nicht den gesamten RFC oder die Sitzungshistorie; das Ticket wurde so geschrieben, dass es eigenständig ist. Wenn nicht, ist das eine Lücke, die zu melden ist, um die nicht herumgeraten werden soll.

3. Schreibe zuerst die Tests

Wandle jedes Akzeptanzkriterium in einen Test um, unter Verwendung des vorhandenen Test-Frameworks, -Orts und -Stils des Repositorys. Führe sie aus und bestätige, dass sie aus dem richtigen Grund fehlschlagen. Ein fokussierter Test pro Kriterium ist ausreichend: keine neuen Test-Hilfsprogramme, Fixtures oder Helfer, es sei denn, ein bestehendes Muster erfordert sie. Bei rein mechanischen Tickets (z. B. Hinzufügen eines Flags) ist möglicherweise kein neuer Test erforderlich, wenn das Kriterium durch bestehende Tests oder den Typprüfer abgedeckt wird; sage dies im PR.

4. Implementiere die kleinstmögliche vollständige Änderung

"Vollständig" bedeutet, dass jedes Akzeptanzkriterium besteht. "Kleinstmöglich" bedeutet, dass darüber hinaus nichts getan wird. Dies folgt dem [Ponytail]-Ansatz (https://github.com/DietrichGebert/ponytail); wenn ein ponytail-Skill installiert ist, lade ihn jetzt auf seiner Standardstufe und lasse ihn diesen Schritt steuern.

Ansonsten nimm die erste Option, die funktioniert:

1. Wird das Bedürfnis bereits erfüllt? Wenn vorhandener Code die Kriterien bereits erfüllt, stoppe und schlage vor, das Ticket zu schließen.
2. Verwende wieder, was die Codebasis bereits hat: Helfer, Typen, Muster.
3. Verwende die Standardbibliothek, dann native Plattformfeatures (DB-Einschränkungen, eingebaute HTML-Eingaben, CSS vor JS), dann bereits installierte Abhängigkeiten.
4. Erst dann schreibe neuen Code, so wenig wie nötig.

Beim Schreiben:

• Keine spekulative Struktur. Keine Interfaces mit einer Implementierung, keine Fabriken für ein Produkt, keine Konfiguration für Werte, die sich nie ändern, kein "für später"-Gerüst. Bevorzuge die Bearbeitung einer vorhandenen Datei gegenüber dem Erstellen einer neuen.
• Passe dich dem umgebenden Code an: Benennung, Fehlerbehandlung, Struktur. Der Diff sollte aussehen, als hätte die Codebasis ihn geschrieben.
• Kommentare nur dort, wo der Code nicht sprechen kann. Erzähle nicht, was der Code tut, wiederhole nicht das Ticket und hinterlasse keinen auskommentierten Code oder Debug-Ausgaben. Der einzige Kommentar, der sich lohnt, ist bei einer bewussten Vereinfachung: nenne die Grenze und wann sie aktualisiert werden sollte, damit niemand sie versehentlich "korrigiert".
• Behebe Fehler an der Wurzel. Überprüfe jeden Aufrufer, bevor du eine gemeinsame Funktion änderst.
• Minimiere niemals die Sicherheit. Eingabevalidierung an Vertrauensgrenzen, Fehlerbehandlung, die Datenverlust verhindert, Sicherheit und grundlegende Barrierefreiheit werden immer ordnungsgemäß durchgeführt, auch wenn das Ticket sie nicht explizit nennt.

5. Den Umfang bewachen

Wenn sich herausstellt, dass das Ticket größer als 1 Punkt ist (mehr als etwa einen Tag, ein zweites Anliegen taucht auf oder ein Kriterium kann nicht erfüllt werden, ohne nicht verwandte Bereiche zu berühren), stoppe. Committe nichts, was über das Bereinigte hinausgeht, erkläre, was du gefunden hast, und schlage eine Aufteilung als neue Tickets zur Genehmigung vor: schreibe sie in die Aufgaben-Datei, wenn du mit dem Benutzer arbeitest, oder in den Bericht, wenn unbeaufsichtigt. Nicht verwandte Probleme, die dir auffallen, kommen in die Notizen des PRs, nicht in den Diff. Schwäche niemals ein Akzeptanzkriterium ab oder interpretiere es neu, um es bestehen zu lassen.

6. Verifizieren und PR öffnen

1. Führe die Tests, den Linter und den Typprüfer so aus, wie das Repository es tut. Wenn die Änderung Laufzeitverhalten hat und du /verify ausführen kannst, tu es; andernfalls teste das Verhalten mit den eigenen Run- oder Check-Befehlen des Projekts.
2. Lies den gesamten Diff selbst noch einmal: jede geänderte Zeile sollte auf ein Akzeptanzkriterium zurückgehen. Entferne nicht verwandte Formatierungen, Umbenennungen und überflüssige Dateien und stelle sicher, dass keine lokale RFC- oder Aufgaben-Datei hineingerutscht ist.
3. Committe gemäß dem Commit-Stil des Repositorys, pushe und öffne den PR bereit zur Überprüfung (nicht als Entwurf, damit die Review-Automatisierung läuft, es sei denn, der Benutzer hat einen Entwurf gewünscht) gegen den Basis-Branch, unter Verwendung von templates/pr.md. Setze den Tracker-Key in den Titel und verlinke das Tracker-Issue in der Beschreibung. Wenn der Basis-Branch nicht main ist, sage, auf welchem PR er gestapelt ist und dass dieser zuerst gemerged wird. Wenn du keine PRs von hier aus öffnen kannst, pushe den Branch und füge den PR-Text in deine Antwort ein.
4. Wenn du direkt mit dem Benutzer arbeitest, setze den Status des Tickets auf pr-open (oder pr-draft) und fülle Branch / PR: in der Aufgaben-Datei aus und verschiebe das Tracker-Issue in seinen Review-Status, wenn seine GitHub-Integration dies nicht tut. Unbeaufsichtigt lasse die Status dem Orchestrator.
5. Beende mit dem Bericht unten. Bei einem anwesenden Benutzer reicht eine zwei- oder dreizeilige Version.

PR-Feedback adressieren (--feedback)

Du erhältst einen PR und eine Liste von Review-Punkten, die zu adressieren sind (Kommentar-Links plus Anweisungen).

1. Hole den Branch des PRs in deinem Worktree und checke ihn aus. Lese das Ticket und die Punkte; lese den aktuellen Diff.
2. Adressiere jeden Punkt mit der kleinsten Änderung, die ihn löst, unter denselben Regeln wie in Schritt 4. Bleibe innerhalb des Umfangs des Tickets: wenn ein Punkt etwas darüber hinaus verlangt, baue es nicht; melde es als Nachverfolgung.
3. Füge neue Commits hinzu, anstatt zu amendieren oder force-push zu machen, damit die Reviewer sehen können, was sich seit ihrer Überprüfung geändert hat. Führe die Tests aus und pushe dann.
4. Antworte auf jedem adressierten Kommentar-Thread mit einer Zeile, die sagt, was sich geändert hat und den kurzen Commit-SHA. Für Punkte, bei denen dir gesagt wurde, ohne Codeänderung zu antworten, antworte mit dem angegebenen Text. Wenn du zu dem Schluss kommst, dass ein Punkt nicht geändert werden sollte, argumentiere nicht im Thread; lasse es und erkläre in deinem Bericht.
5. Beende mit dem Bericht, verwende done, wenn jeder Punkt behandelt wurde, andernfalls blocked.

Bericht

Beende deine endgültige Nachricht genau mit diesem Block, damit ein Orchestrator ihn parsen kann:

RESULT: done | blocked | needs-split | already-met
TICKET: <lokale ID> / <Tracker-Key oder "unpublished">
PR: <URL oder "none">
BRANCH: <Branch oder "none">
SKIPPED: <bewusste Grenzen oder nicht adressierte Punkte, oder "none">
NOTES: <ein oder zwei Zeilen: warum blocked, was aufzuteilen ist, Nachverfolgungen, nicht verwandte gefundene Probleme>