Como salvar repos, issues e PRs do GitHub em Markdown (Guia 2026)

O conteúdo do GitHub está espalhado entre READMEs, issues, PRs, discussions e gists --- e jogar qualquer coisa para um LLM é doloroso a não ser que esteja em Markdown. O README já está lá, claro, mas a parte que você realmente precisa é a thread de issue com 80 comentários onde alguém finalmente descobriu o workaround, ou a PR onde o breaking change foi explicado, ou a discussion que explica por que a API foi desenhada daquele jeito. Nada disso está a um clique de virar contexto utilizável pelo Claude.

Este guia cobre todo método para converter conteúdo do GitHub em Markdown limpo --- de um único README a uma longa discussão de PR até um repo inteiro.

Por que salvar conteúdo do GitHub como Markdown?

Markdown é o formato que funciona em todo lugar onde o conhecimento de código precisa ir:

• Alimente um LLM com ele --- Claude, ChatGPT, Gemini e modelos locais leem Markdown nativamente como contexto, com blocos de código e identificadores de linguagem preservados
• Coloque no Obsidian ou Notion --- um arquivo por issue ou repo, totalmente pesquisável, com cabeçalhos corretos
• Arquive uma thread antes que seja travada ou deletada --- mantenedores fecham issues, repos viram privados, suas notas não deveriam depender do uptime do GitHub
• Construa documentação offline --- compile READMEs de múltiplos repos numa única referência
• Cite um comentário específico em uma thread longa --- pular de volta para a única resposta útil em uma issue de 200 comentários está a uma busca de distância

O caso de uso que move a maior parte do tráfego GitHub-para-Markdown em 2026 é o primeiro: desenvolvedores querem perguntar a um LLM sobre uma biblioteca, um bug ou uma decisão de design, e colar a URL não dá ao modelo o que ele precisa.

Método 1: Save (Mais rápido, um clique)

Save é uma extensão Chrome que transforma qualquer página GitHub em um arquivo Markdown com um clique. Ela lê a página renderizada, reconstrói o Markdown original quando possível e produz algo que cai direto no Claude, Obsidian ou na sua pasta de docs.

Como funciona:

1. Abra a página do GitHub no Chrome --- repo, issue, PR, discussion, gist ou wiki
2. Clique no ícone da extensão Save na sua barra de ferramentas
3. Um arquivo .md baixa instantaneamente (ou cai no seu Save Vault se conectado)

O que você obtém:

• READMEs com blocos de código, tabelas e cabeçalhos intactos
• Título, corpo, status e comentários encadeados de issue e PR
• Threads de discussion com aninhamento correto
• Issues referenciadas e @mentions preservadas
• Labels, milestones, assignees como frontmatter
• Blocos de código mantêm seu identificador de linguagem (assim o realce de sintaxe funciona em visualizadores Markdown)
• Gists (single-file e multi-file) suportados
• Frontmatter com repo, autor, data, URL e estado (open/closed/merged)

O que é removido:

• Navegação, sidebars e rodapé do GitHub
• Linhas de emoji de reação sob cada comentário
• Colapsos “X hidden items” (Save expande e inclui)
• Comentários de bots de CI, dependabot e stale-bot (alternável)
• Quote-replies repetidas que só ecoam o comentário anterior

Melhor para: Devs depurando com IA, escritores técnicos compilando docs, pesquisadores arquivando threads, qualquer um construindo uma base de conhecimento pessoal sobre como bibliotecas realmente funcionam na prática. Se você precisa de Markdown limpo para colar no Claude ou ler no Obsidian, este é o caminho mais limpo.

Exemplo de saída

Salvar uma thread de issue produz:

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

Esse arquivo está a um colar de virar contexto utilizável do Claude, a uma tecla de virar uma nota Obsidian permanente.

Método 2: API do GitHub + Script

As APIs REST e GraphQL do GitHub expõem tudo --- READMEs, issues, comentários, diffs de PR. Você pode escrever um script para buscar e converter.

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

Melhor para: Times de engenharia construindo pipelines de documentação, qualquer um scriptando exports em massa de issues ou PRs em vários repos.

Problemas com essa abordagem:

• A API retorna corpos Markdown crus, mas costurar título + corpo + comentários + metadados em um arquivo legível é problema seu
• Frontmatter (labels, milestones, assignees, estado) exige múltiplas chamadas de API e montagem manual
• Ordem dos comentários, atribuição de autor e cadeias aninhadas de respostas precisam de lógica customizada
• Rate limits são atingidos rapidamente em repos grandes (5.000 requests/hora autenticado)
• Discussions vivem atrás da API GraphQL, não REST, então o script vira dois pipelines
• Diffs de PR e comentários de review são endpoints separados de novo

Este é o método certo se você está construindo um pipeline. É exagero para uma única issue.

Método 3: Clone + conversão local (para repos inteiros)

Para READMEs e docs in-repo, o método mais simples é clonar e ler os arquivos diretamente --- já são Markdown no disco.

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

Melhor para: Devs que querem acesso offline aos docs de um repo, ou que precisam alimentar uma árvore inteira de docs para um LLM de contexto longo.

Problemas com essa abordagem:

• Só funciona para conteúdo armazenado no repo (READMEs, /docs, wiki se clonado separadamente)
• Não captura issues, PRs ou discussions --- esses vivem no banco do GitHub, não na árvore git
• Cross-references entre docs e issues quebram (#412 não resolve localmente)
• URLs de imagens em READMEs frequentemente apontam para user-attachments.githubusercontent.com e precisam ser reescritas para uso offline
• Você ainda precisa de um script para combinar e limpar se quiser um único arquivo

Bom para “quero os docs offline.” Ferramenta errada para “quero essa thread de issue com 80 comentários.”

Método 4: Copiar manualmente do navegador

O método na força bruta: abra a página, selecione tudo, cole em um editor Markdown, limpe.

Passos:

1. Abra a issue ou PR no navegador
2. Selecione a seção relevante (ou a página inteira)
3. Cole no Obsidian, VS Code ou outro editor Markdown
4. Tire o barulho de UI (reações, nav, sidebars) na mão
5. Re-adicione as code fences, conserte a ordem dos comentários, adicione frontmatter

Problemas com essa abordagem:

• Blocos de código perdem seu identificador de linguagem e realce de sintaxe
• Autoria e timestamps dos comentários acabam como texto livre, não frontmatter estruturado
• Tabelas em READMEs frequentemente colam como texto puro com separadores tab
• Linhas de reação (+1 heart rocket) vazam para o corpo
• Aninhamento de discussion encadeada colapsa em texto plano
• Leva 10 minutos para uma thread longa ; multiplique por cada issue que você salva

Funciona para um README curto. Desmonta em threads de issue reais.

Qual método você deve usar?

Cenário	Melhor método
Colar uma issue ou PR no Claude	Save --- um clique, saída estruturada
Arquivar uma longa thread de discussion	Save --- aninhamento e metadados preservados
Construir cópia offline dos docs de um repo	git clone --- READMEs já são Markdown
Exportar issues em massa em vários repos	API GitHub + script --- programático
Salvar um único README rapidamente	Save --- pula o passo do clone
Referência rápida pontual para notas pessoais	Cópia manual --- funciona para páginas curtas

Para a maioria dos devs --- especialmente qualquer um usando conteúdo do GitHub como contexto de IA --- Save é a resposta. Produz o Markdown mais limpo com zero setup, e lida com threads longas de issue na mesma velocidade que um README.

Edge cases que o Save lida

• Repos privados. Save usa sua sessão de navegador logada. Se sua conta do GitHub pode ver o repo, Save pode ler. Sem token API para configurar.
• GitHub Enterprise self-hosted. Funciona em qualquer padrão de domínio github.*. Save lê a página renderizada, então enquanto a UI for o layout padrão do GitHub, a conversão funciona.
• GitHub Discussions vs Issues. Ambos suportados. Discussions pegam sua categoria como frontmatter (category: Q&A, category: Announcements) e respostas aninhadas como estrutura encadeada.
• Diffs de PR e mudanças de arquivo. Mantidos quando relevantes. O corpo da PR, comentários de review e conversações em nível de arquivo são incluídos. O diff cru em si é resumido em vez de despejado --- normalmente você não quer 5.000 linhas de diff no seu contexto LLM.
• Linhas de emoji de reação. Removidas. As linhas +1, heart, rocket sob cada comentário são barulho para tudo exceto análise de tendências.
• Threads de issue muito longas. Para threads com centenas de comentários, Save mantém o corpo da issue, as respostas do maintainer, o comentário de resolução e um marcador “Other comments: N omitted”. Alternável para inclusão completa se você precisar de cada resposta.
• Páginas Wiki. Wikis de repo são suportados. Cada página vira um arquivo Markdown, com links internos do wiki reescritos como caminhos relativos.
• Project boards. Visões de project board são capturadas como lista estruturada: coluna → título do card → issue/PR linkada. Útil para arquivar uma sprint antes que feche.
• Comentários de bot. Dependabot, stale-bot, CodeQL, GitHub Actions --- todos detectados e alternáveis. Desligados por padrão porque quase sempre adicionam barulho.
• Blocos de código com identificadores de linguagem. A tag de linguagem de triple-backtick (```python, ```rust) é preservada para que qualquer renderizador Markdown ou LLM receba a dica de realce de sintaxe.
• Gists. Gists single-file e multi-file ambos suportados. Gists multi-file viram um único arquivo Markdown com cada arquivo como uma seção.

Combine com seu fluxo

A saída Markdown funciona onde você precisar:

• Claude / ChatGPT / Gemini --- cole o arquivo, pergunte “por que essa issue foi fechada?” ou “resuma a decisão de design nessa PR”
• Obsidian --- jogue no seu vault, linke issues a notas relacionadas, busque em cada biblioteca que você salvou
• Notion --- cole diretamente, cabeçalhos, tabelas e blocos de código renderizam corretamente
• Cursor / Claude Code --- jogue o arquivo no projeto, a IA agora tem o contexto upstream ao sugerir correções
• Save Vault --- se você conectou um, cada save do GitHub cai lá automaticamente com o repo como tag e backlinks para outras threads salvas

FAQ

Save funciona em repos privados? Sim. Usa sua sessão de navegador logada, então qualquer coisa que sua conta do GitHub possa ver, Save pode salvar. Sem setup de PAT ou OAuth requerido.

Funciona no GitHub Enterprise (self-hosted)? Sim. Qualquer UI do GitHub é suportada independente do domínio. Se sua empresa roda github.acme-corp.com, Save funciona lá também.

Vai capturar cada comentário em uma thread de 500 comentários? Por padrão, Save mantém o corpo da issue, respostas do maintainer e a resolução. Para a thread completa, alterne “Include all comments” no menu da extensão antes de salvar.

Os blocos de código são formatados corretamente? Sim. Fences de triple-backtick e identificadores de linguagem são preservados exatamente. ```python continua ```python para que qualquer LLM ou visualizador Markdown pegue o realce de sintaxe.

Lida com diffs de PR? O corpo da PR, comentários de review e conversações inline em arquivos são incluídos. O diff cru é resumido por arquivo em vez de despejado por inteiro --- geralmente o que você quer para contexto LLM. Alterne “Include raw diff” se precisar do patch completo.

E sobre GitHub Discussions? Totalmente suportado. Categorias, respostas aninhadas e status marcado-como-respondido vêm como Markdown estruturado.

Preserva @mentions e cross-references? Sim. Menções @username ficam como menções de texto puro, e referências #123 de issue são mantidas como estão. Se quiser como hyperlinks de volta ao GitHub, a extensão pode reescrevê-las ao salvar.

Funciona no site mobile do GitHub? A extensão é só Chrome desktop. No mobile, copie a URL e abra no desktop, ou compartilhe para um Save Vault no Mac.

Quanto custa? Save tem um tier grátis para você testar em alguns repos e issues. Depois disso, uma pequena assinatura cobre uso mais pesado.

Guias Save relacionados

• Salvar respostas do Stack Overflow como Markdown --- respostas aceitas com blocos de código e comentários
• Salvar conversas ChatGPT como Markdown --- cada turno, com blocos de código intactos
• Salvar conversas Claude como Markdown --- artifacts, código e raciocínio preservados
• Salvar vídeos do YouTube como Markdown --- transcrição, resumo, timestamps, marcadores de capítulo