yeet

yeet ist ein offizieller, kuratierter Skill aus dem öffentlichen Repository openai/skills. Er beschreibt einen eng begrenzten Arbeitsablauf für den Fall, dass eine Person ausdrücklich darum bittet, Änderungen zu stagen, zu committen, zu pushen und anschließend einen GitHub Pull Request in einem zusammenhängenden Flow zu eröffnen. Laut Anbieter ist dieser Skill ausschließlich für eine solche explizite Bitte vorgesehen. Er ist damit keine allgemeine Freigabe, selbstständig Änderungen zu veröffentlichen, und auch kein Ersatz für eine Prüfung des Diffs, der Branches oder der Zielorganisation. Die Primärquelle ist der Ordner skills/.curated/yeet im offiziellen Repository. Als passende OpenAI-Dokumentation dient die offizielle Codex-Dokumentation, die Codex als Umgebung für Entwicklungsaufgaben und Pull-Request-Arbeit beschreibt.

Zweck und klarer Auslöser

Der Name yeet steht hier für eine bewusst gebündelte GitHub-Arbeitsfolge. Der Skill soll nur aktiviert werden, wenn die Nutzerabsicht alle wesentlichen Schritte ausdrücklich umfasst. Dazu gehören das Vorbereiten des Arbeitsbaums, das Erstellen eines Commits, das Übertragen des Branches zum Remote und das Öffnen eines Pull Requests. Eine Bitte um Code-Review, eine Bitte um einen Commit oder eine Bitte um eine lokale Änderung reicht allein nicht aus. Diese Grenze reduziert das Risiko, dass ein Agent aus einer vagen Formulierung heraus externe Repository-Zustände verändert.

Vor dem eigentlichen Flow verlangt die Anbieteranleitung die Prüfung, ob die GitHub CLI gh vorhanden ist und ob eine gültige Anmeldung besteht. Der Skill setzt außerdem ein Repository mit einem passenden Remote und ausreichenden Berechtigungen voraus. Fehlt die CLI oder ist die Sitzung nicht authentifiziert, soll der Agent anhalten und die zuständige Person um Einrichtung oder Anmeldung bitten. Zugangsdaten, Tokens und private Konfigurationen gehören nicht in diesen Katalogeintrag und werden vom Skill nicht bereitgestellt.

Ablauf für nachvollziehbare Pull Requests

Der beschriebene Ablauf beginnt mit der Ermittlung des Repository-Stammverzeichnisses und der Prüfung, ob bereits auf dem Standardbranch gearbeitet wird. Falls nötig, wird ein beschreibender Branch angelegt. Danach soll der Agent den Status prüfen, Änderungen bewusst auswählen und einen prägnanten Commit mit einer zur Aufgabe passenden Beschreibung erstellen. Vor dem Push bleibt die Kontrolle über den Änderungsumfang wichtig: Unbeabsichtigte Dateien, lokale Geheimnisse, generierte Artefakte und fremde Arbeitsstände müssen aus dem Commit ferngehalten werden.

Vor dem Eröffnen des Pull Requests soll der Agent eine vorhandene GitHub-Vorlage im Repository erkennen und berücksichtigen. Der Pull Request braucht einen aussagekräftigen Titel und einen erklärenden Text, der den tatsächlichen Änderungsumfang abbildet. Die Anleitung unterscheidet zwischen dem Erstellen eines neuen Entwurfs und dem Bearbeiten eines bereits vorhandenen Pull Requests. Ein bestehender veröffentlichter Review-Status darf nicht ohne ausdrücklichen Grund zurückgesetzt werden. Diese Vorgaben machen den Ablauf für Teams besser nachvollziehbar und verhindern, dass eine technische Automatisierung redaktionelle Konventionen des Projekts übergeht.

Grenzen, Sicherheit und Verantwortlichkeit

Der Skill führt potenziell externe und dauerhafte Aktionen aus. Ein Push verändert den Remote-Zustand, und ein Pull Request kann Benachrichtigungen, Prüfungen oder Deployment-Prozesse auslösen. Deshalb muss die ausdrückliche Nutzeranweisung vom Agenten klar erkannt werden. Vor dem Commit sollte der Diff auf sensible Inhalte, destruktive Änderungen und falsche Ziel-Remotes geprüft werden. Die GitHub-Berechtigungen müssen dem Prinzip der geringsten Rechte folgen. Auch ein erfolgreich geöffneter Pull Request beweist nicht, dass der Code sicher, korrekt oder für den Merge bereit ist.

Laut Anbieter ist yeet eine Anleitung für einen bestimmten Agenten-Workflow und kein eigenständiger GitHub-Dienst. Der Erfolg hängt von gh, der lokalen Repository-Konfiguration, der GitHub-Anmeldung, Branch-Regeln, Review-Anforderungen und der ausgewählten Codex-Umgebung ab. Der Skill nennt keine konkreten Preise und ersetzt keine Organisationsrichtlinie. Teams sollten Branch-Schutz, verpflichtende Reviews, Secret-Scanning und CI weiterhin unabhängig prüfen. Die offizielle Quelle und der Quellstand sollten vor der produktiven Nutzung erneut kontrolliert werden.