GitHub-Repos, Issues und PRs als Markdown speichern (Guide 2026)

GitHub-Inhalte sind über READMEs, Issues, PRs, Discussions und Gists verstreut --- und davon irgendetwas einem LLM zu füttern ist mühsam, solange es nicht in Markdown vorliegt. Das README ist zwar schon da, aber der Teil, den du wirklich brauchst, ist der 80-Kommentare-Issue-Thread, in dem jemand endlich den Workaround gefunden hat, oder die PR, in der der Breaking Change erklärt wurde, oder die Discussion, die erklärt, warum die API so designt wurde. Nichts davon ist einen Klick entfernt davon, nutzbarer Claude-Kontext zu sein.

Dieser Guide deckt jede Methode ab, GitHub-Inhalte in sauberes Markdown zu konvertieren --- vom einzelnen README über eine lange PR-Diskussion bis zum gesamten Repo.

Warum GitHub-Inhalte als Markdown speichern?

Markdown ist das Format, das überall funktioniert, wohin Code-Wissen muss:

• Füttere es einem LLM --- Claude, ChatGPT, Gemini und lokale Modelle lesen alle Markdown nativ als Kontext, mit erhaltenen Codeblöcken und Sprach-Identifiern
• Lege es in Obsidian oder Notion ab --- eine Datei pro Issue oder Repo, vollständig durchsuchbar, korrekt gegliedert
• Archiviere einen Thread, bevor er gelockt oder gelöscht wird --- Maintainer schließen Issues, Repos werden privat, deine Notizen sollten nicht von GitHubs Uptime abhängen
• Baue Offline-Dokumentation --- kompiliere READMEs aus mehreren Repos zu einer einzigen Referenz
• Zitiere einen bestimmten Kommentar in einem langen Thread --- zur einen nützlichen Antwort in einer 200-Kommentare-Issue zurückzuspringen ist eine Suche entfernt

Der Use Case, der 2026 den meisten GitHub-zu-Markdown-Traffic treibt, ist der erste: Entwickler wollen einen LLM zu einer Library, einem Bug oder einer Designentscheidung befragen, und das Einfügen der URL gibt dem Modell nicht, was es braucht.

Methode 1: Save (Am schnellsten, ein Klick)

Save ist eine Chrome-Erweiterung, die jede GitHub-Seite mit einem Klick in eine Markdown-Datei verwandelt. Sie liest die gerenderte Seite, rekonstruiert das ursprüngliche Markdown wo möglich und produziert etwas, das direkt in Claude, Obsidian oder deinen Docs-Ordner fällt.

Wie es funktioniert:

1. Öffne die GitHub-Seite in Chrome --- Repo, Issue, PR, Discussion, Gist oder Wiki
2. Klicke auf das Save-Erweiterungssymbol in deiner Toolbar
3. Eine .md-Datei wird sofort heruntergeladen (oder landet in deinem Save Vault, falls verbunden)

Was du bekommst:

• READMEs mit intakten Codeblöcken, Tabellen und Überschriften
• Titel, Body, Status, Thread-Kommentare von Issue und PR
• Discussion-Threads mit korrekter Verschachtelung
• Verlinkte referenzierte Issues und @mentions erhalten
• Labels, Milestones, Assignees als Frontmatter
• Codeblöcke behalten ihren Sprach-Identifier (Syntax-Highlighting funktioniert in Markdown-Viewern)
• Gists (single-file und multi-file) unterstützt
• Frontmatter mit Repo, Autor, Datum, URL und State (open/closed/merged)

Was entfernt wird:

• GitHub-Navigation, Sidebars und Footer
• Reaktions-Emoji-Reihen unter jedem Kommentar
• “X hidden items”-Aufklapper (Save expandiert und inkludiert sie)
• Bot-Kommentare von CI, Dependabot und Stale-Bot (umschaltbar)
• Wiederholte Quote-Replies, die nur den vorherigen Kommentar echoen

Am besten für: Entwickler, die mit KI debuggen, Tech Writer beim Doc-Compilen, Forscher beim Thread-Archivieren, alle, die eine persönliche Wissensbasis darüber aufbauen, wie Libraries in der Praxis wirklich funktionieren. Wenn du sauberes Markdown brauchst, das du in Claude einfügst oder in Obsidian liest, ist das der sauberste Weg.

Beispiel-Output

Das Speichern eines Issue-Threads erzeugt:

---
title: "Memory leak when using streaming with large responses"
repo: anthropics/anthropic-sdk-python
number: 412
author: alice-dev
state: closed
labels: ["bug", "streaming", "memory"]
assignees: ["bob-maintainer"]
milestone: "v0.34.0"
created: 2026-03-12
closed: 2026-03-18
url: https://github.com/anthropics/anthropic-sdk-python/issues/412
---

## Issue

When streaming responses larger than ~50MB, memory grows linearly and is
never released. Reproduced on Python 3.11 and 3.12, macOS and Linux.

**Reproduction:**

\`\`\`python
from anthropic import Anthropic

client = Anthropic()
with client.messages.stream(...) as stream:
    for text in stream.text_stream:
        print(text, end="")
\`\`\`

After the loop ends, `tracemalloc` shows the buffer is still resident.

## Comments

### bob-maintainer (maintainer) --- 2026-03-13

Confirmed. The internal buffer in `_streaming.py` isn't being cleared on
context exit. Looking at it now.

### alice-dev --- 2026-03-14

Thanks. Workaround for anyone hitting this: call `stream.close()`
explicitly before the `with` block exits. References #389.

### bob-maintainer (maintainer) --- 2026-03-18

Fixed in #418, released in v0.34.0. Closing.

Diese Datei ist ein Paste davon entfernt, nutzbarer Claude-Kontext zu sein, ein Tastendruck davon entfernt, eine permanente Obsidian-Notiz zu sein.

Methode 2: GitHubs API + Skript

GitHubs REST- und GraphQL-APIs legen alles offen --- READMEs, Issues, Kommentare, PR-Diffs. Du kannst ein Skript schreiben, um zu holen und zu konvertieren.

gh api repos/OWNER/REPO/issues/412 --jq '.body' > issue-412.md
gh api repos/OWNER/REPO/issues/412/comments --jq '.[].body' >> issue-412.md

Am besten für: Engineering-Teams, die Dokumentations-Pipelines bauen, jeder, der Bulk-Exporte von Issues oder PRs über viele Repos skriptet.

Probleme mit diesem Ansatz:

• Die API liefert rohe Markdown-Bodies, aber Titel + Body + Kommentare + Metadaten zu einer lesbaren Datei zusammenzunähen ist dein Problem
• Frontmatter (Labels, Milestones, Assignees, State) erfordert mehrere API-Calls und manuelles Zusammenbauen
• Kommentar-Reihenfolge, Autoren-Zuordnung und verschachtelte Reply-Chains brauchen Custom-Logik
• Rate Limits werden bei großen Repos schnell erreicht (5.000 Requests/Stunde authentifiziert)
• Discussions liegen hinter der GraphQL-API, nicht REST, also wird das Skript zu zwei Pipelines
• PR-Diffs und Review-Kommentare sind wieder separate Endpoints

Das ist die richtige Methode, wenn du eine Pipeline baust. Es ist Overkill für ein einzelnes Issue.

Methode 3: Clone + lokale Konvertierung (für ganze Repos)

Für READMEs und Docs im Repo ist die einfachste Methode, zu klonen und die Dateien direkt zu lesen --- sie sind bereits Markdown auf der Platte.

git clone https://github.com/OWNER/REPO.git
cd REPO
cat README.md docs/*.md > combined.md

Am besten für: Entwickler, die Offline-Zugang zu den Docs eines Repos wollen, oder die einen ganzen Doc-Tree einem Long-Context-LLM füttern müssen.

Probleme mit diesem Ansatz:

• Funktioniert nur für Inhalte, die im Repo gespeichert sind (READMEs, /docs, Wiki, wenn separat geklont)
• Erfasst keine Issues, PRs oder Discussions --- die leben in GitHubs Datenbank, nicht im Git-Tree
• Cross-References zwischen Docs und Issues brechen (#412 löst lokal nicht auf)
• Bild-URLs in READMEs zeigen oft auf user-attachments.githubusercontent.com und müssen für Offline-Nutzung umgeschrieben werden
• Du brauchst trotzdem ein Skript zum Kombinieren und Säubern, wenn du eine Datei willst

Okay für “Ich will die Docs offline.” Falsches Werkzeug für “Ich will diesen 80-Kommentar-Issue-Thread.”

Methode 4: Manuelles Kopieren aus dem Browser

Die Brute-Force-Methode: Seite öffnen, alles markieren, in einen Markdown-Editor einfügen, säubern.

Schritte:

1. Öffne das Issue oder die PR im Browser
2. Markiere den relevanten Abschnitt (oder die ganze Seite)
3. Füge in Obsidian, VS Code oder einen anderen Markdown-Editor ein
4. Entferne UI-Lärm (Reaktionen, Nav, Sidebars) von Hand
5. Füge Code-Fences wieder hinzu, korrigiere Kommentar-Reihenfolge, füge Frontmatter hinzu

Probleme mit diesem Ansatz:

• Codeblöcke verlieren ihren Sprach-Identifier und Syntax-Highlighting
• Kommentar-Autorschaft und Zeitstempel landen als Freitext, nicht als strukturiertes Frontmatter
• Tabellen in READMEs werden oft als reiner Text mit Tab-Trennern eingefügt
• Reaktions-Reihen (+1 heart rocket) sickern in den Body
• Discussion-Verschachtelung kollabiert zu flachem Text
• Dauert 10 Minuten für einen langen Thread; multipliziere mit jeder Issue, die du speicherst

Funktioniert für ein kurzes README. Bricht bei echten Issue-Threads zusammen.

Welche Methode solltest du verwenden?

Szenario	Beste Methode
Issue oder PR in Claude einfügen	Save --- ein Klick, strukturierter Output
Langen Discussion-Thread archivieren	Save --- Verschachtelung und Metadaten erhalten
Offline-Kopie der Docs eines Repos	git clone --- READMEs sind bereits Markdown
Bulk-Export von Issues über viele Repos	GitHub API + Skript --- programmatisch
Schnell ein einzelnes README speichern	Save --- spart den Clone-Schritt
Einmalige schnelle Referenz für persönliche Notizen	Manuelles Kopieren --- für kurze Seiten okay

Für die meisten Entwickler --- besonders jeden, der GitHub-Inhalte als KI-Kontext nutzt --- ist Save die Antwort. Es produziert das sauberste Markdown ohne jegliches Setup und behandelt lange Issue-Threads mit derselben Geschwindigkeit wie ein README.

Edge Cases, die Save handhabt

• Private Repos. Save verwendet deine eingeloggte Browser-Session. Wenn dein GitHub-Account das Repo sehen kann, kann Save es lesen. Kein API-Token zu konfigurieren.
• Self-hosted GitHub Enterprise. Funktioniert auf jedem github.*-Domain-Pattern. Save liest die gerenderte Seite, also funktioniert die Konvertierung, solange die UI GitHubs Standard-Layout ist.
• GitHub Discussions vs. Issues. Beide unterstützt. Discussions bekommen ihre Kategorie als Frontmatter (category: Q&A, category: Announcements) und verschachtelte Replies als Thread-Struktur.
• PR-Diffs und Dateiänderungen. Behalten, wenn relevant. PR-Body, Review-Kommentare und Konversationen auf Datei-Ebene sind enthalten. Der rohe Diff selbst wird zusammengefasst statt gedumpt --- du willst normalerweise nicht 5.000 Zeilen Diff in deinem LLM-Kontext.
• Reaktions-Emoji-Reihen. Entfernt. Die +1, heart, rocket-Reihen unter jedem Kommentar sind Lärm für alles außer Trend-Analyse.
• Sehr lange Issue-Threads. Bei Threads mit Hunderten von Kommentaren behält Save den Issue-Body, die Maintainer-Antworten, den Resolution-Kommentar und einen “Other comments: N omitted”-Marker. Umschaltbar auf Voll-Inkludierung, falls du jede Antwort brauchst.
• Wiki-Seiten. Repo-Wikis werden unterstützt. Jede Seite wird zu einer Markdown-Datei, mit internen Wiki-Links als relative Pfade umgeschrieben.
• Project Boards. Project-Board-Ansichten werden als strukturierte Liste erfasst: Spalte → Card-Titel → verlinkte Issue/PR. Nützlich, um einen Sprint vor dem Schließen zu archivieren.
• Bot-Kommentare. Dependabot, Stale-Bot, CodeQL, GitHub Actions --- alle erkannt und umschaltbar. Standardmäßig aus, weil sie fast immer Lärm hinzufügen.
• Codeblöcke mit Sprach-Identifiern. Der Triple-Backtick-Sprach-Tag (```python, ```rust) wird erhalten, damit jeder Markdown-Renderer oder LLM den Syntax-Highlighting-Hinweis bekommt.
• Gists. Single-file- und Multi-file-Gists, beide unterstützt. Multi-file-Gists werden zu einer Markdown-Datei mit jeder Datei als Section.

Verbinde es mit deinem Workflow

Der Markdown-Output funktioniert überall, wo du ihn brauchst:

• Claude / ChatGPT / Gemini --- füge die Datei ein, frage “warum wurde dieses Issue geschlossen?” oder “fasse die Designentscheidung in dieser PR zusammen”
• Obsidian --- lege es in deinen Vault, verlinke Issues mit verwandten Notizen, suche über jede Library, die du gespeichert hast
• Notion --- direkt einfügen, Überschriften, Tabellen und Codeblöcke rendern korrekt
• Cursor / Claude Code --- lege die Datei ins Projekt, die KI hat jetzt den Upstream-Kontext beim Vorschlagen von Fixes
• Save Vault --- wenn du einen verbunden hast, landet jedes GitHub-Save automatisch dort, mit dem Repo als Tag und Backlinks zu anderen gespeicherten Threads

FAQ

Funktioniert Save auf privaten Repos? Ja. Es verwendet deine eingeloggte Browser-Session, also kann Save alles speichern, was dein GitHub-Account sehen kann. Kein PAT- oder OAuth-Setup nötig.

Funktioniert es auf GitHub Enterprise (self-hosted)? Ja. Jede GitHub-UI wird unabhängig von der Domain unterstützt. Wenn deine Firma github.acme-corp.com betreibt, funktioniert Save dort auch.

Wird es jeden Kommentar in einem 500-Kommentar-Thread erfassen? Standardmäßig behält Save den Issue-Body, die Maintainer-Antworten und die Resolution. Für den ganzen Thread aktiviere “Include all comments” im Erweiterungsmenü vor dem Speichern.

Werden Codeblöcke korrekt formatiert? Ja. Triple-Backtick-Fences und Sprach-Identifier werden exakt erhalten. ```python bleibt ```python, damit jedes LLM oder jeder Markdown-Viewer Syntax-Highlighting bekommt.

Behandelt es PR-Diffs? PR-Body, Review-Kommentare und Inline-Datei-Konversationen sind enthalten. Der rohe Diff wird per Datei zusammengefasst statt komplett gedumpt --- normalerweise das, was du für LLM-Kontext willst. Aktiviere “Include raw diff”, falls du den vollständigen Patch brauchst.

Was ist mit GitHub Discussions? Voll unterstützt. Kategorien, verschachtelte Antworten und Marked-as-Answered-Status kommen alle als strukturiertes Markdown durch.

Behält es @mentions und Cross-References? Ja. @username-Mentions bleiben als Plain-Text-Mentions, und #123-Issue-Referenzen werden so beibehalten. Wenn du sie als Hyperlinks zurück zu GitHub willst, kann die Erweiterung sie beim Speichern umschreiben.

Funktioniert es auf der mobilen GitHub-Seite? Die Erweiterung gibt es nur für Desktop-Chrome. Auf Mobile kopiere die URL und öffne sie auf Desktop, oder teile zu einem Save Vault auf dem Mac.

Wie viel kostet es? Save hat einen kostenlosen Tier, damit du es an ein paar Repos und Issues ausprobieren kannst. Danach deckt ein kleines Abo intensivere Nutzung ab.

Verwandte Save-Guides

• Stack-Overflow-Antworten als Markdown speichern --- akzeptierte Antworten mit Codeblöcken und Kommentaren
• ChatGPT-Konversationen als Markdown speichern --- jeder Turn, mit intakten Codeblöcken
• Claude-Konversationen als Markdown speichern --- Artifacts, Code und Reasoning erhalten
• YouTube-Videos als Markdown speichern --- Transkript, Zusammenfassung, Zeitstempel, Kapitelmarker