codex-pr-body

Bestimmen des/der PR(s)

Wenn dieser Skill aufgerufen wird, können die zu aktualisierenden PR(s) explizit angegeben werden. Im Normalfall werden die zu aktualisierenden PR(s) jedoch aus dem Branch/Commit abgeleitet, an dem der Benutzer gerade arbeitet. Bei normaler Git-Nutzung (d.h. nicht Sapling, wie unten besprochen) musst du eventuell eine Kombination aus git branch und gh pr view <branch> --repo openai/codex --json number --jq '.number' verwenden, um den PR zu bestimmen, der mit dem aktuellen Branch/Commit verbunden ist.

Inhalt der PR-Beschreibung

Verwende gh, um den Titel und die Beschreibung des Pull Requests entsprechend dem angegebenen PR zu bearbeiten. Überprüfe unbedingt die vorhandene PR-Beschreibung, ob wichtige Informationen erhalten bleiben sollten. Entferne z.B. niemals ein Bild aus der vorhandenen PR-Beschreibung, da der Autor möglicherweise keine Möglichkeit hat, es wiederherzustellen, wenn du es entfernst.

Es ist entscheidend zu erklären, warum die Änderung vorgenommen wird. Wenn im aktuellen Gespräch, in dem dieser Skill aufgerufen wird, die Motivation diskutiert wurde, halte diese unbedingt in der PR-Beschreibung fest.

Die Beschreibung sollte auch erklären, was sich geändert hat, aber dies sollte nach dem Warum erscheinen.

Beschränke die Diskussion auf die Nettoänderung des Commits. Es ist im Allgemeinen verpönt, Änderungen zu besprechen, die während der Entwicklung des Pull Requests versucht, aber später rückgängig gemacht wurden. Wenn du die PR-Beschreibung umschreibst, musst du möglicherweise solche Details entfernen, wenn sie für zukünftige Leser nicht mehr angemessen oder von Interesse sind.

Vermeide Verweise auf absolute Pfade auf meiner lokalen Festplatte. Wenn du über einen Pfad sprichst, der sich innerhalb des Repositorys befindet, verwende einfach den repo-relativen Pfad.

Vermeide Verweise auf vertrauliche Informationen, einschließlich, aber nicht beschränkt auf Codenamen oder OpenAI-interne URLs.

Es ist im Allgemeinen hilfreich zu besprechen, wie die Änderung verifiziert wurde. Es ist jedoch unnötig, Dinge zu erwähnen, die CI automatisch prüft, z.B. nimm "just fmt ausgeführt" nicht als Teil des Testplans auf. Allerdings ist es oft angebracht, die neuen Tests zu identifizieren, die absichtlich eingeführt wurden, um das durch den Pull Request eingeführte neue Verhalten zu verifizieren.

Verwende Markdown, um den Pull Request professionell zu formatieren. Stelle sicher, dass "Code-Dinge" in einfachen Backticks erscheinen, wenn sie inline referenziert werden. Fenced Codeblöcke sind nützlich, um Code zu referenzieren oder ein Shell-Transkript zu zeigen. Verwende außerdem GitHub-Permalinks, wenn du auf vorhandene Code-Stücke verweist, die für die Änderung relevant sind.

Verweise auf relevante Pull Requests oder Issues, obwohl es nicht nötig sein sollte, im eigenen PR-Body auf den Pull Request zu verweisen.

Wenn als Ergebnis dieser Änderung Dokumentation auf https://developers.openai.com/codex aktualisiert werden sollte, vermerke dies bitte in einem separaten Abschnitt am Ende des Pull Requests. Lasse diesen Abschnitt weg, wenn keine Dokumentation aktualisiert werden muss.

Arbeiten mit Stapeln (Stacks)

Manchmal besteht ein Pull Request aus einem Stapel von Commits, die aufeinander aufbauen. In diesen Fällen sollte die PR-Beschreibung die Nettoänderung widerspiegeln, die durch den Stapel als Ganzes eingeführt wird, und nicht die einzelnen Commits, aus denen der Stapel besteht.

Ähnlich kann es vorkommen, dass ein Benutzer ein Tool wie Sapling verwendet, um gestapelte Pull Requests zu nutzen. In diesem Fall kann die base des PR ein Branch sein, der der head eines anderen PR im Stapel ist, und nicht main. In diesem Fall besprich nur die Nettoänderung zwischen base und head des PR, der gegen diese gestapelte Basis eröffnet wird, und nicht die Änderungen relativ zu main.

Sapling

Wenn .git/sl/store vorhanden ist, dann wird dieses Git-Repository von Sapling SCM (https://sapling-scm.com) verwaltet.

Führe in Sapling Folgendes aus, um zu sehen, ob ein GitHub-Pull Request mit der aktuellen Revision verbunden ist:

sl log --template '{github_pull_request_url}' -r .

Alternativ kannst du sl sl ausführen, um den aktuellen Entwicklungsbranch zu sehen und ob ein GitHub-Pull Request mit dem aktuellen Commit verbunden ist. Wenn die Ausgabe zum Beispiel wäre:

  @  cb032b31cf  72 minutes ago  mbolin  #11412
╭─╯  tui: show non-file layer content in /debug-config
│
o  fdd0cd1de9  Today at 20:09  origin/main
│
~

• @ zeigt an, dass der aktuelle Commit cb032b31cf ist
• es ist ein Entwicklungsbranch, der einen einzelnen Commit enthält, der von origin/main abgezweigt ist
• er ist mit dem GitHub-Pull Request #11412 verbunden