GitHub Extrakt

Was macht GitHub Extrakt?

Problem, das dieser Skill löst

Ein Nutzer wirft einen GitHub-Link hin. Meistens will er nicht einen Haufen Dateiinhalte, sondern er will drei Dinge verstehen:

1. Wofür ist dieses Projekt überhaupt da?
2. Welches Problem soll diese Änderung lösen?
3. Warum wurde dieser Ansatz gewählt? Dateien, Diffs und Metadaten sind nur Beweise. Die Beweise als Ergebnis zu präsentieren bedeutet, nicht extrahiert zu haben – der Leser bekommt eine Tabelle, kann aber nicht sagen, warum dieses Repository existiert. Erfolgskriterium (ein Satz): Eine Person, die dieses Repository noch nie gehört hat, kann nach dem Lesen der ersten 300 Wörter in eigenen Worten wiedergeben: "Welches Problem löst es, was wurde geändert, warum wurde es so geändert". Wenn das nicht geht, ist die Extraktion noch nicht abgeschlossen.

Schritt 0: Lies zuerst das "Projekt", dann die "Seite"

Bevor du PR/Issue aufrufst, verstehe den Träger selbst. Wenn du diesen Schritt überspringst, hängt alles Weitere in der Luft.

Zu beantwortende Frage	Wo nachlesen
Was ist das für ein Projekt	description des Repos, topics, Anfang der README
Welche Lücke füllt es / was ersetzt es	"Warum"-Spalten jedes Pakets in der README
Wer nutzt es in welchem Szenario	Install / Usage / Develop der README
Wo steht diese Änderung im Projekt	Basis-Branch des PR, Rolle des geänderten Pakets in der Liste
Monorepos / Plugin-Sammlungen bitte nicht überspringen: Gib zuerst eine Tabelle mit "Paketname → Aufgabenbeschreibung in einem Satz" aus, sonst kann der Leser die Änderung nicht einordnen. Wenn die README viele Fachbegriffe verwendet (z. B. "Lifecycle Hooks", "ctx.web seam"), übersetze sie erst in ein, zwei einfache Sätze, bevor du zum eigentlichen Inhalt kommst.

Schritt 1: Identifiziere den URL-Typ

URL-Form	Typ	Hauptdatenquelle
github.com/{o}/{r}	Repo	/readme + git/trees?recursive=1
…/issues/{n}	Issue	issues/{n}
…/pull/{n}	PR	pulls/{n} + pulls/{n}/files + pull/{n}.diff
…/commit/{sha}	Commit	commits/{sha}
…/blob/{ref}/{path}	Datei	contents/{path}?ref={ref} (base64)
#1 ist ein Fragment, kein Pfad. Issues und PRs teilen sich einen Nummernraum: Wenn /issues/1 per 302 auf /pull/1 weiterleitet, dann ist es ein PR, und das muss klar gesagt werden.

Schritt 2: Verwende die API, nicht das HTML

• Das HTML der Seite liefert nur die Navigationsleiste und abgeschnittene Texte – für den vollständigen Inhalt verwende api.github.com.
• Patches beziehe von patch-diff.githubusercontent.com/raw/{o}/{r}/pull/{n}.diff (die URL github.com/.../pull/n.diff leitet Cross-Origin um – verwende direkt die finale Adresse).
• raw.githubusercontent.com ist oft nicht verfügbar: verwende stattdessen die base64-Daten aus contents und dekodiere lokal.
• Falls git / curl lokal mit TLS SEC_E_NO_CREDENTIALS fehlschlagen, repariere nicht die Shell, sondern verwende die web_fetch-Funktion des Harnesses. Ein fehlgeschlagenes clone ist kein Grund, die Aufgabe abzubrechen.

Schritt 3: Kreuzvalidierung

additions/deletions/changed_files ↔ Liste der files ↔ Hunk im .diff; Head-SHA des PR ↔ Patch-Referenz; merged – schau nicht nur auf state=closed. Bei Inkonsistenzen weiterprüfen (meist Paginierung oder alter Patch) – liefere kein widersprüchliches Ergebnis ab.

Schritt 4: Strukturiere das Ergebnis „lesbar"

Die Reihenfolge ist verbindlich: Erklärung vor den Beweisen. Der Leser sollte nicht durch 200 Zeilen Tabelle blättern, um zu verstehen, worum es geht.

1. Was ist es (150–300 Wörter, einfache Sprache) – Existenzberechtigung des Projekts, welche Lücke es füllt. Fachbegriffe beim ersten Auftreten in einem Satz erklären: hookkit = verwandelt „du musst ein Plugin schreiben, um Lifecycle-Hooks zu nutzen" in „du schreibst ein YAML".
2. Was soll diese Änderung lösen – Schreibe als Vergleich „vorher → nachher", nicht als Dateiliste.
3. Warum dieser Ansatz – Extrahiere aus der PR-Beschreibung / Commit-Nachricht die Abwägungen und Kausalketten (warum nicht Push-Trigger, warum Registry als State).
4. Änderungsliste – Tabelle: Datei / Status / Hinzufügungen+Löschungen / Wirkung in einem Satz.
5. Originaltexte – PR-Beschreibung, Commit-Nachricht wortwörtlich zitieren, nicht umschreiben.
6. Vollständiger Inhalt – Jede Datei vollständig, kein „… Rest ausgelassen".
7. Übertragbare Vorgehensweise – Nur Dinge, die der Leser wirklich selbst anwenden kann.
8. Verifikation & Abdeckung – Ans Ende als Anhang: Ergebnisse von git apply --check, Blob-SHA-Vergleiche, was nicht abgerufen werden konnte. Schreibregeln

• Ergebnis zuerst: Der erste Satz jedes Absatzes ist das Ergebnis, danach kommen die Begründungen.
• Tabellen tragen keine Erklärverantwortung. Alles, was „Was ist das" oder „Warum" erklärt, muss in vollständigen Sätzen geschrieben sein.
• Keine Dateinamen als Funktionsbeschreibung: "publish.yml geändert" ❌; "Neuen manuellen Workflow hinzugefügt: Veröffentlichung nur per Knopfdruck, standardmäßig nur Trockenlauf" ✅.
• Zahlen müssen nachvollziehbar sein, aber Validierungslogs gehören nicht an den Anfang.
• Verwende die Sprache des Nutzers.
• Antimuster: große Tabellen, die rohen Datei-Diff als Haupttext, Metadaten am Anfang, unerklärte Fachbegriffe.

Schritt 5: Selbstkontrolle

• Kann jemand nach den ersten 300 Wörtern (ohne Tabellenüberschriften) die Fragen „Was tut es / Was wurde geändert / Warum so geändert" beantworten? Wenn nicht, schreibe neu.
• Gibt es Fachbegriffe, die nicht erklärt wurden?
• Wurde „Die Dateien A, B, C haben sich geändert" als Änderungsbeschreibung verwendet?
• Wurde der Patch mit git apply --check überprüft? Falls nicht, schreibe explizit „nicht verifiziert".

Fehlermodi

Symptom	Ursache	Behandlung
Text bricht mittendrin ab	HTML abgerufen	API verwenden
404 auf raw.githubusercontent	Netzwerk-Whitelist	contents base64 dekodieren
403 Rate Limit	Nicht authentifizierte Schleife	Batchen, langsamer machen, Lücken ehrlich melden
cross-origin redirect not followed	.diff-Weiterleitung	Direktverbindung zu patch-diff…
Dateianzahl ≠ changed_files	Paginierung	?per_page=100 erneut abrufen
Leserfeedback „nicht verstanden"	Nur Beweise, keine Erklärung	Zurück zu Schritt 4, Abschnitte 1–3, neu schreiben

Grenzen

Priorität: Explizite Nutzeranweisung > Einschränkungen dieses Abschnitts > Standard-Vorsicht. Standardmäßig nur Inhalte extrahieren, nicht nebenbei clonen / builden / installieren / Tests ausführen. Für private Repos benötigt der Nutzer ein Token – nicht erfinden. Ist ein Repo archiviert, das erwähnen – die Inhalte sind trotzdem extrahierbar, aber der Status beeinflusst die Interpretation. Situationen, in denen du unbedingt nachfragen musst (statt eigenmächtig zu handeln)

• Nutzer sagt „Installiere / führe aus", aber das Ziel ist ein fremdes Repository oder es schreibt in die globale Umgebung: Zuerst den Umfang und die Rollback-Möglichkeit klären.
• Anweisung ist mehrdeutig („Bearbeite dieses Repository"): Eine Standard-Lösung vorschlagen + bitte um Bestätigung, nicht einfach loslegen.
• Aktion ist nicht umkehrbar oder ändert die Nutzerumgebung (pnpm install, globale Pakete, Profile ändern, PR erstellen, pushen, Dateien löschen): Immer vorher fragen.
• Es wird ein Credential benötigt (privates Repo, Token, SSH-Key): Einmal nachfragen; bekommst du es, verwende es, sonst gib nur öffentlich verifizierbare Teile aus und vermerke, was fehlt. Situationen, in du die Einschränkungen lockern darfst
• Es ist das eigene Repository des Nutzers und er hat klar gesagt „Mach was du willst / Installiere direkt / Frag nicht";
• oder die Aktion läuft in einem temporären Verzeichnis ab und berührt weder das Original-Repo noch den globalen Zustand (in diesem Fall wird nur die „schreiben"-Einschränkung gelockert, nicht „fremden Code ausführen"). Wenn du gelockert hast, schreibe ans Ende des Ergebnisses: „Habe auf deine Autorisierung hin X ausgeführt", damit der Übergriff sichtbar und rückgängig machbar ist.