Come salvare repo, issue e PR di GitHub come Markdown (Guida 2026)

I contenuti di GitHub sono sparsi tra README, issue, PR, discussion e gist --- e darne in pasto uno a un LLM è doloroso se non è in Markdown. Il README è già lì, certo, ma la parte che ti serve davvero è il thread di issue con 80 commenti dove qualcuno alla fine ha trovato il workaround, o la PR dove è stato spiegato il breaking change, o la discussion che spiega perché l’API è stata progettata in quel modo. Niente di tutto ciò è a un clic dall’essere contesto utilizzabile per Claude.

Questa guida copre ogni metodo per convertire contenuti di GitHub in Markdown pulito --- da un singolo README a una lunga discussione su una PR fino a un intero repo.

Perché salvare i contenuti GitHub come Markdown?

Markdown è il formato che funziona ovunque la conoscenza del codice debba andare:

• Dallo in pasto a un LLM --- Claude, ChatGPT, Gemini e i modelli locali leggono tutti Markdown nativamente come contesto, con i blocchi di codice e gli identificatori di linguaggio preservati
• Mettilo in Obsidian o Notion --- un file per issue o repo, completamente ricercabile, con intestazioni corrette
• Archivia un thread prima che venga bloccato o eliminato --- i maintainer chiudono issue, i repo diventano privati, le tue note non dovrebbero dipendere dall’uptime di GitHub
• Costruisci documentazione offline --- compila READMEs di più repo in un unico riferimento
• Cita un commento specifico in un lungo thread --- tornare all’unica risposta utile in un’issue da 200 commenti è a una ricerca di distanza

Il caso d’uso che guida la maggior parte del traffico GitHub-a-Markdown nel 2026 è il primo: gli sviluppatori vogliono interrogare un LLM su una libreria, un bug o una decisione di design, e incollare l’URL non dà al modello ciò di cui ha bisogno.

Metodo 1: Save (Il più veloce, un clic)

Save è un’estensione Chrome che trasforma qualsiasi pagina GitHub in un file Markdown con un clic. Legge la pagina renderizzata, ricostruisce il Markdown originale dove possibile e produce qualcosa che cade dritto in Claude, Obsidian o nella tua cartella docs.

Come funziona:

1. Apri la pagina GitHub in Chrome --- repo, issue, PR, discussion, gist o wiki
2. Clicca sull’icona dell’estensione Save nella tua barra strumenti
3. Un file .md viene scaricato istantaneamente (o atterra nel tuo Save Vault se connesso)

Cosa ottieni:

• README con blocchi di codice, tabelle e intestazioni intatti
• Titolo, corpo, stato e commenti annidati di issue e PR
• Thread di discussion con annidamento corretto
• Issue di riferimento e @mentions preservate
• Label, milestone, assegnatari come frontmatter
• I blocchi di codice mantengono il loro identificatore di linguaggio (la colorazione sintattica funziona nei visualizzatori Markdown)
• Gist (single-file e multi-file) supportati
• Frontmatter con repo, autore, data, URL e stato (open/closed/merged)

Cosa viene rimosso:

• Navigazione, sidebar e footer di GitHub
• Righe di emoji di reazione sotto ogni commento
• Collassi “X hidden items” (Save li espande e li include)
• Commenti di bot da CI, dependabot e stale-bot (commutabile)
• Quote-reply ripetute che fanno solo eco al commento precedente

Ideale per: Sviluppatori che fanno debug con l’IA, technical writer che compilano documentazione, ricercatori che archiviano thread, chiunque costruisca una base di conoscenza personale su come funzionano davvero le librerie nella pratica. Se ti serve Markdown pulito da incollare in Claude o leggere in Obsidian, questa è la via più pulita.

Esempio di output

Salvare un thread di issue produce:

---
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.

Quel file è a un incolla dall’essere contesto utilizzabile per Claude, a un tasto dall’essere una nota Obsidian permanente.

Metodo 2: API di GitHub + Script

Le API REST e GraphQL di GitHub espongono tutto --- README, issue, commenti, diff di PR. Puoi scrivere uno script per recuperare e convertire.

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

Ideale per: Team di ingegneria che costruiscono pipeline di documentazione, chiunque scripti export massivi di issue o PR su molti repo.

Problemi con questo approccio:

• L’API restituisce corpi Markdown grezzi, ma cucire titolo + corpo + commenti + metadati in un singolo file leggibile è un tuo problema
• Il frontmatter (label, milestone, assegnatari, stato) richiede più chiamate API e assemblaggio manuale
• Ordine dei commenti, attribuzione dell’autore e catene annidate di risposte richiedono logica custom
• I rate limit si raggiungono in fretta su repo grandi (5.000 richieste/ora autenticato)
• Le Discussion vivono dietro l’API GraphQL, non REST, quindi lo script diventa due pipeline
• Diff di PR e commenti di review sono di nuovo endpoint separati

Questo è il metodo giusto se stai costruendo una pipeline. È esagerato per una singola issue.

Metodo 3: Clone + conversione locale (per repo interi)

Per README e docs in-repo, il metodo più semplice è clonare e leggere i file direttamente --- sono già Markdown su disco.

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

Ideale per: Sviluppatori che vogliono accesso offline ai docs di un repo, o che hanno bisogno di dare in pasto un intero albero di docs a un LLM long-context.

Problemi con questo approccio:

• Funziona solo per contenuti memorizzati nel repo (README, /docs, wiki se clonato separatamente)
• Non cattura issue, PR o discussion --- quelle vivono nel database di GitHub, non nell’albero git
• I cross-reference tra docs e issue si rompono (#412 non si risolve localmente)
• Le URL delle immagini nei README spesso puntano a user-attachments.githubusercontent.com e devono essere riscritte per l’uso offline
• Hai comunque bisogno di uno script per combinare e pulire se vuoi un singolo file

Va bene per “voglio i docs offline.” Strumento sbagliato per “voglio questo thread di issue da 80 commenti.”

Metodo 4: Copia manuale dal browser

Il metodo brute-force: apri la pagina, seleziona tutto, incolla in un editor Markdown, ripulisci.

Passi:

1. Apri la issue o PR nel browser
2. Seleziona la sezione rilevante (o l’intera pagina)
3. Incolla in Obsidian, VS Code o un altro editor Markdown
4. Rimuovi a mano il rumore UI (reazioni, nav, sidebar)
5. Ri-aggiungi le code fence, sistema l’ordine dei commenti, aggiungi frontmatter

Problemi con questo approccio:

• I blocchi di codice perdono il loro identificatore di linguaggio e la colorazione sintattica
• Paternità e timestamp dei commenti finiscono come testo libero, non frontmatter strutturato
• Le tabelle nei README spesso si incollano come testo semplice con separatori tab
• Le righe di reazione (+1 heart rocket) trapelano nel corpo
• L’annidamento delle discussion collassa in testo piatto
• Ci vogliono 10 minuti per un thread lungo ; moltiplica per ogni issue che salvi

Funziona per un README breve. Va a pezzi su veri thread di issue.

Quale metodo dovresti usare?

Scenario	Metodo migliore
Incollare una issue o PR in Claude	Save --- un clic, output strutturato
Archiviare un lungo thread di discussion	Save --- annidamento e metadati preservati
Copia offline dei docs di un repo	git clone --- i README sono già Markdown
Export massivo di issue su molti repo	API GitHub + script --- programmatico
Salvare velocemente un singolo README	Save --- evita lo step di clone
Riferimento rapido una tantum per note personali	Copia manuale --- per pagine corte

Per la maggior parte degli sviluppatori --- specialmente chiunque usi contenuti GitHub come contesto IA --- Save è la risposta. Produce il Markdown più pulito senza setup, e gestisce thread di issue lunghi alla stessa velocità di un README.

Edge case che Save gestisce

• Repo privati. Save usa la tua sessione di browser loggata. Se il tuo account GitHub può vedere il repo, Save può leggerlo. Nessun token API da configurare.
• GitHub Enterprise self-hosted. Funziona su qualsiasi pattern di dominio github.*. Save legge la pagina renderizzata, quindi finché la UI è il layout standard di GitHub, la conversione funziona.
• GitHub Discussions vs Issues. Entrambi supportati. Le Discussion ottengono la categoria come frontmatter (category: Q&A, category: Announcements) e le risposte annidate come struttura a thread.
• Diff di PR e modifiche ai file. Mantenuti quando rilevanti. Corpo della PR, commenti di review e conversazioni a livello file sono inclusi. Il diff grezzo stesso viene riassunto invece che riversato --- di solito non vuoi 5.000 righe di diff nel tuo contesto LLM.
• Righe di emoji di reazione. Rimosse. Le righe +1, heart, rocket sotto ogni commento sono rumore per tutto tranne l’analisi delle tendenze.
• Thread di issue molto lunghi. Per thread con centinaia di commenti, Save mantiene il corpo dell’issue, le risposte del maintainer, il commento di risoluzione e un marker “Other comments: N omitted”. Commutabile a inclusione completa se ti serve ogni risposta.
• Pagine Wiki. I wiki dei repo sono supportati. Ogni pagina diventa un file Markdown, con i link interni del wiki riscritti come path relativi.
• Project board. Le viste di project board vengono catturate come lista strutturata: colonna → titolo card → issue/PR linkata. Utile per archiviare uno sprint prima che si chiuda.
• Commenti di bot. Dependabot, stale-bot, CodeQL, GitHub Actions --- tutti rilevati e commutabili. Disattivati di default perché aggiungono quasi sempre rumore.
• Blocchi di codice con identificatori di linguaggio. Il tag di linguaggio triple-backtick (```python, ```rust) è preservato in modo che qualsiasi renderer Markdown o LLM riceva l’hint di colorazione sintattica.
• Gist. Gist single-file e multi-file entrambi supportati. I gist multi-file diventano un singolo file Markdown con ogni file come sezione.

Abbinalo al tuo workflow

L’output Markdown funziona ovunque tu ne abbia bisogno:

• Claude / ChatGPT / Gemini --- incolla il file, chiedi “perché è stata chiusa questa issue?” o “riassumi la decisione di design in questa PR”
• Obsidian --- mettilo nel tuo vault, collega issue a note correlate, cerca su ogni libreria che hai salvato
• Notion --- incolla direttamente, intestazioni, tabelle e blocchi di codice si renderizzano correttamente
• Cursor / Claude Code --- metti il file nel progetto, l’IA ora ha il contesto upstream quando suggerisce fix
• Save Vault --- se ne hai connesso uno, ogni salvataggio GitHub atterra lì automaticamente con il repo come tag e backlink ad altri thread salvati

FAQ

Save funziona su repo privati? Sì. Usa la tua sessione di browser loggata, quindi qualsiasi cosa il tuo account GitHub possa vedere, Save può salvarla. Nessuna configurazione PAT o OAuth richiesta.

Funziona su GitHub Enterprise (self-hosted)? Sì. Qualsiasi UI di GitHub è supportata indipendentemente dal dominio. Se la tua azienda fa girare github.acme-corp.com, Save funziona anche lì.

Catturerà ogni commento in un thread da 500 commenti? Di default, Save mantiene il corpo dell’issue, le risposte del maintainer e la risoluzione. Per il thread completo, attiva “Include all comments” nel menu dell’estensione prima di salvare.

I blocchi di codice sono formattati correttamente? Sì. Le fence triple-backtick e gli identificatori di linguaggio sono preservati esattamente. ```python resta ```python in modo che qualsiasi LLM o visualizzatore Markdown ottenga la colorazione sintattica.

Gestisce i diff di PR? Corpo della PR, commenti di review e conversazioni inline sui file sono inclusi. Il diff grezzo è riassunto per file invece che riversato in blocco --- di solito ciò che vuoi per contesto LLM. Attiva “Include raw diff” se ti serve la patch completa.

E le GitHub Discussions? Pienamente supportate. Categorie, risposte annidate e stato segnato-come-risposto arrivano tutti come Markdown strutturato.

Preserva @mentions e cross-reference? Sì. Le menzioni @username restano come menzioni di testo semplice, e i riferimenti di issue #123 sono mantenuti tali e quali. Se li vuoi come hyperlink verso GitHub, l’estensione può riscriverli al salvataggio.

Funziona sul sito mobile di GitHub? L’estensione è solo per Chrome desktop. Su mobile, copia l’URL e aprila su desktop, oppure condividi a un Save Vault su Mac.

Quanto costa? Save ha un piano gratuito così puoi provarlo su qualche repo e issue. Dopo, un piccolo abbonamento copre uso più intenso.

Guide Save correlate

• Salvare le risposte di Stack Overflow come Markdown --- risposte accettate con blocchi di codice e commenti
• Salvare le conversazioni ChatGPT come Markdown --- ogni turno, con blocchi di codice intatti
• Salvare le conversazioni Claude come Markdown --- artefatti, codice e ragionamento preservati
• Salvare i video YouTube come Markdown --- trascrizione, riassunto, timestamp, marker dei capitoli