GitHub Issue-Artefakte: Ein fester Platz für Pläne und Kontext
Der Code steht im Pull Request, seine Begründung weit oben im Chat. Wenn auch die Untersuchung eines Agenten woanders liegt, beginnt die nächste Person leicht von vorn. GitHub hat am 28. Oktober Issue-Artefakte als öffentliche Vorschau vorgestellt, um solche Unterlagen beim zugehörigen Issue aufzubewahren.
Gespräch und fortgeschriebenes Dokument ergänzen sich
Artefakte können Markdown-Dokumente, externe Links und HTML-Dokumente sein: etwa Ursachenanalysen, Prototypen oder Slack- und Teams-Diskussionen. Auf github.com lassen sie sich anlegen und mit Versionshistorie bearbeiten. Sie sind von GitHub Actions-Artefakten zu unterscheiden, die Ergebnisse eines Workflow-Laufs enthalten.
Als erfundenes Beispiel dient eine doppelt verarbeitete Zahlung. Kommentare halten neue Beobachtungen fest; ein Plan beschreibt den Wiederholungsschlüssel und offene Versuche. Die erste Abbildung wurde für diesen Beitrag erstellt und zeigt keine GitHub-Oberfläche. Beobachtung und Hypothese getrennt zu notieren hilft, Vermutungen nicht zu Anforderungen werden zu lassen.
Eine Datei anhängen und denselben Kontext weiterpflegen
gh issue artifact create nimmt eine Issue-Nummer oder URL sowie Dateien oder Links entgegen. gh issue artifact create 42 retry-plan.md -R OWNER/REPO würde die Datei an Issue 42 anhängen. Repository und Nummer sind Platzhalter. Die Ausführung schreibt in das Issue; für diesen Beitrag wurde sie nicht ausgeführt.
Der Dateiname kann den Namen liefern; --name setzt ihn ausdrücklich. --body-file liest den Inhalt eines Dokuments, --attach unterstützt Bilder und Videos. gh issue artifact edit 42 1 --body-file retry-plan.md -R OWNER/REPO ersetzt später den Inhalt. Die zweite Abbildung zeigt Syntaxbeispiele, kein erfolgreich ausgeführtes Terminalprotokoll.
Aktualität und Entstehungsgeschichte behalten
edit ändert Namen oder Inhalt, aber nicht den Typ. --restore-version speichert einen früheren Namen und Inhalt als neue Version; view zeigt die Bearbeitungshistorie. So können aktuelle Pläne neben ihrer Entwicklung bestehen bleiben.
Im Zahlungsbeispiel könnte sich der Verdacht vom Timeout zur Behandlung doppelter Schlüssel verschieben. Den Plan zu aktualisieren und die neue Begründung im Kommentar zu verknüpfen ist ein Vorschlag zur Dokumentation, keine automatische Produktfunktion. Belege bleiben auch bei einem angehängten Plan nötig.
HTML-Unterstützung hängt von der Oberfläche ab
HTML-Artefakte können laut Ankündigung zwischen Vorschau und Quelltext wechseln. Das Erstellen und Anzeigen in der GitHub App wurde jedoch als künftig verfügbar beschrieben. Automatisch angehängte Sitzungsergebnisse bedeuten nicht vollständige HTML-Unterstützung überall. Auch die CLI bleibt Vorschau.
Der Gewinn liegt im Fundort des Kontexts, nicht in mehr Dokumenten. Ein vorhandener Plan und seine nächste Überarbeitung reichen, um den Ablauf auszuprobieren. Ankündigung und aktuelle CLI-Dokumentation erläutern die Grenzen.