Cómo guardar repos, issues y PRs de GitHub como Markdown (Guía 2026)

El contenido de GitHub está disperso entre READMEs, issues, PRs, discussions y gists --- y alimentar cualquier cosa a un LLM es doloroso si no está en Markdown. El README ya está ahí, sí, pero la parte que realmente necesitas es ese hilo de 80 comentarios donde alguien finalmente dio con el workaround, o la PR donde se explicó el breaking change, o la discussion que explica por qué la API se diseñó así. Nada de eso está a un clic de ser contexto utilizable para Claude.

Esta guía cubre todos los métodos para convertir contenido de GitHub en Markdown limpio --- desde un único README hasta una larga discusión de PR o un repo entero.

¿Por qué guardar contenido de GitHub como Markdown?

Markdown es el formato que funciona en cualquier lugar donde necesite ir el conocimiento del código:

• Dáselo a un LLM --- Claude, ChatGPT, Gemini y los modelos locales leen Markdown nativamente como contexto, con los bloques de código e identificadores de lenguaje preservados
• Mételo en Obsidian o Notion --- un archivo por issue o repo, totalmente buscable, con cabeceras correctas
• Archiva un hilo antes de que se bloquee o elimine --- los mantenedores cierran issues, los repos se vuelven privados, tus notas no deberían depender del uptime de GitHub
• Construye documentación offline --- compila READMEs de varios repos en una sola referencia
• Cita un comentario específico en un hilo largo --- volver a la única respuesta útil en una issue de 200 comentarios está a una búsqueda de distancia

El caso de uso que más tráfico GitHub-a-Markdown impulsa en 2026 es el primero: los desarrolladores quieren preguntarle a un LLM sobre una librería, un bug o una decisión de diseño, y pegar la URL no le da al modelo lo que necesita.

Método 1: Save (El más rápido, un clic)

Save es una extensión de Chrome que convierte cualquier página de GitHub en un archivo Markdown con un clic. Lee la página renderizada, reconstruye el Markdown original cuando es posible y produce algo que cae directamente en Claude, Obsidian o tu carpeta de docs.

Cómo funciona:

1. Abre la página de GitHub en Chrome --- repo, issue, PR, discussion, gist o wiki
2. Haz clic en el icono de la extensión Save en tu barra de herramientas
3. Un archivo .md se descarga al instante (o aterriza en tu Save Vault si está conectado)

Lo que obtienes:

• READMEs con bloques de código, tablas y cabeceras intactos
• Título, cuerpo, estado y comentarios anidados de issue y PR
• Hilos de discussion con anidamiento correcto
• Issues referenciadas y @mentions preservadas
• Labels, milestones, assignees como frontmatter
• Los bloques de código mantienen su identificador de lenguaje (así el resaltado de sintaxis funciona en los visores Markdown)
• Gists (single-file y multi-file) soportados
• Frontmatter con repo, autor, fecha, URL y estado (open/closed/merged)

Lo que se elimina:

• Navegación, barras laterales y pie de página de GitHub
• Filas de emojis de reacción bajo cada comentario
• Plegados “X hidden items” (Save los expande y los incluye)
• Comentarios de bots de CI, dependabot y stale-bot (conmutable)
• Quote-replies repetidas que solo repiten el comentario anterior

Ideal para: Desarrolladores depurando con IA, redactores técnicos compilando docs, investigadores archivando hilos, cualquiera que construya una base de conocimiento personal sobre cómo funcionan realmente las librerías en la práctica. Si necesitas Markdown limpio para pegar en Claude o leer en Obsidian, este es el camino más limpio.

Ejemplo de salida

Guardar un hilo de 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.

Ese archivo está a un pegado de ser contexto utilizable para Claude, a una pulsación de tecla de ser una nota Obsidian permanente.

Método 2: API de GitHub + Script

Las APIs REST y GraphQL de GitHub exponen todo --- READMEs, issues, comentarios, diffs de PR. Puedes escribir un script para obtener y convertir.

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

Ideal para: Equipos de ingeniería construyendo pipelines de documentación, cualquiera que escriba scripts de exportación masiva de issues o PRs en muchos repos.

Problemas con este enfoque:

• La API devuelve cuerpos Markdown crudos, pero unir título + cuerpo + comentarios + metadatos en un solo archivo legible es problema tuyo
• El frontmatter (labels, milestones, assignees, estado) requiere múltiples llamadas a la API y ensamblaje manual
• El orden de los comentarios, la atribución de autor y las cadenas anidadas de respuestas requieren lógica personalizada
• Los rate limits se alcanzan rápido en repos grandes (5.000 requests/hora autenticado)
• Las Discussions viven detrás de la API GraphQL, no REST, así que el script son dos pipelines
• Los diffs de PR y comentarios de review son endpoints separados otra vez

Este es el método correcto si estás construyendo un pipeline. Es exagerado para una sola issue.

Método 3: Clone + conversión local (para repos enteros)

Para READMEs y docs in-repo, el método más simple es clonar y leer los archivos directamente --- ya son Markdown en disco.

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

Ideal para: Desarrolladores que quieren acceso offline a los docs de un repo, o que necesitan alimentar un árbol completo de docs a un LLM de contexto largo.

Problemas con este enfoque:

• Solo funciona para contenido almacenado en el repo (READMEs, /docs, wiki si se clona por separado)
• No captura issues, PRs ni discussions --- esas viven en la base de datos de GitHub, no en el árbol git
• Las referencias cruzadas entre docs e issues se rompen (#412 no resuelve localmente)
• Las URLs de imágenes en READMEs suelen apuntar a user-attachments.githubusercontent.com y necesitan ser reescritas para uso offline
• Sigues necesitando un script para combinar y limpiar si quieres un solo archivo

Bien para “quiero los docs offline.” Herramienta equivocada para “quiero este hilo de issue de 80 comentarios.”

Método 4: Copiar manualmente desde el navegador

El método de fuerza bruta: abre la página, selecciona todo, pega en un editor Markdown, límpialo.

Pasos:

1. Abre la issue o PR en el navegador
2. Selecciona la sección relevante (o toda la página)
3. Pega en Obsidian, VS Code u otro editor Markdown
4. Quita a mano el ruido de UI (reacciones, nav, barras laterales)
5. Vuelve a añadir las fences de código, arregla el orden de comentarios, añade frontmatter

Problemas con este enfoque:

• Los bloques de código pierden su identificador de lenguaje y el resaltado de sintaxis
• La autoría y timestamps de los comentarios acaban como texto libre, no frontmatter estructurado
• Las tablas de los READMEs a menudo se pegan como texto plano con separadores de tab
• Las filas de reacción (+1 heart rocket) se cuelan en el cuerpo
• El anidamiento de discussion se colapsa a texto plano
• Toma 10 minutos por un hilo largo; multiplica por cada issue que guardas

Funciona para un README corto. Se desmorona en hilos de issue reales.

¿Qué método debes usar?

Escenario	Mejor método
Pegar una issue o PR en Claude	Save --- un clic, salida estructurada
Archivar un hilo de discussion largo	Save --- anidamiento y metadatos preservados
Copia offline de docs de un repo	git clone --- los READMEs ya son Markdown
Exportar issues en masa en muchos repos	API GitHub + script --- programático
Guardar un único README rápido	Save --- evita el paso de clone
Referencia rápida puntual para notas personales	Copia manual --- vale para páginas cortas

Para la mayoría de desarrolladores --- especialmente cualquiera que use contenido de GitHub como contexto de IA --- Save es la respuesta. Produce el Markdown más limpio con cero configuración, y maneja hilos largos de issue a la misma velocidad que un README.

Casos límite que Save maneja

• Repos privados. Save usa tu sesión de navegador logueada. Si tu cuenta de GitHub puede ver el repo, Save puede leerlo. Sin token de API que configurar.
• GitHub Enterprise auto-alojado. Funciona en cualquier patrón de dominio github.*. Save lee la página renderizada, así que mientras la UI sea el layout estándar de GitHub, la conversión funciona.
• GitHub Discussions vs Issues. Ambos soportados. Las Discussions obtienen su categoría como frontmatter (category: Q&A, category: Announcements) y respuestas anidadas como estructura en hilo.
• Diffs y cambios de archivo en PR. Mantenidos cuando son relevantes. Cuerpo de la PR, comentarios de review y conversaciones a nivel de archivo se incluyen. El diff crudo se resume en lugar de volcarse --- normalmente no quieres 5.000 líneas de diff en tu contexto LLM.
• Filas de emojis de reacción. Eliminadas. Las filas +1, heart, rocket bajo cada comentario son ruido para todo salvo análisis de tendencias.
• Hilos de issue muy largos. Para hilos con cientos de comentarios, Save mantiene el cuerpo de la issue, las respuestas del mantenedor, el comentario de resolución y un marcador “Other comments: N omitted”. Conmutable a inclusión completa si necesitas cada respuesta.
• Páginas Wiki. Los wikis de repo están soportados. Cada página se convierte en un archivo Markdown, con los enlaces internos del wiki reescritos como rutas relativas.
• Project boards. Las vistas de project board se capturan como lista estructurada: columna → título de la tarjeta → issue/PR enlazada. Útil para archivar un sprint antes de que cierre.
• Comentarios de bots. Dependabot, stale-bot, CodeQL, GitHub Actions --- todos detectados y conmutables. Desactivados por defecto porque casi siempre añaden ruido.
• Bloques de código con identificadores de lenguaje. La etiqueta de lenguaje triple-backtick (```python, ```rust) se preserva para que cualquier renderizador Markdown o LLM reciba la pista de resaltado de sintaxis.
• Gists. Gists de un solo archivo y multi-archivo, ambos soportados. Los gists multi-archivo se convierten en un solo archivo Markdown con cada archivo como sección.

Combínalo con tu flujo de trabajo

La salida Markdown funciona donde la necesites:

• Claude / ChatGPT / Gemini --- pega el archivo, pregunta “¿por qué se cerró esta issue?” o “resume la decisión de diseño en esta PR”
• Obsidian --- déjalo en tu vault, enlaza issues a notas relacionadas, busca en todas las librerías que has guardado
• Notion --- pega directamente, cabeceras, tablas y bloques de código renderizan correctamente
• Cursor / Claude Code --- deja el archivo en el proyecto, la IA ahora tiene el contexto upstream al sugerir correcciones
• Save Vault --- si has conectado uno, cada guardado de GitHub aterriza ahí automáticamente con el repo como tag y backlinks a otros hilos guardados

FAQ

¿Funciona Save en repos privados? Sí. Usa tu sesión de navegador logueada, así que cualquier cosa que tu cuenta de GitHub pueda ver, Save puede guardar. No requiere setup de PAT u OAuth.

¿Funciona en GitHub Enterprise (auto-alojado)? Sí. Cualquier UI de GitHub está soportada independientemente del dominio. Si tu empresa corre github.acme-corp.com, Save también funciona ahí.

¿Capturará cada comentario en un hilo de 500 comentarios? Por defecto, Save mantiene el cuerpo de la issue, respuestas del mantenedor y la resolución. Para el hilo completo, activa “Include all comments” en el menú de la extensión antes de guardar.

¿Los bloques de código se formatean correctamente? Sí. Las fences triple-backtick y los identificadores de lenguaje se preservan exactamente. ```python se queda como ```python para que cualquier LLM o visor Markdown obtenga resaltado de sintaxis.

¿Maneja los diffs de PR? El cuerpo de la PR, comentarios de review y conversaciones inline en archivos se incluyen. El diff crudo se resume por archivo en lugar de volcarse íntegro --- normalmente lo que quieres para contexto LLM. Activa “Include raw diff” si necesitas el parche completo.

¿Y las GitHub Discussions? Totalmente soportado. Categorías, respuestas anidadas y estado marcado-como-respondido vienen como Markdown estructurado.

¿Preserva @mentions y referencias cruzadas? Sí. Las menciones @username se quedan como menciones de texto plano, y las referencias #123 a issues se mantienen tal cual. Si las quieres como hipervínculos de vuelta a GitHub, la extensión puede reescribirlas al guardar.

¿Funciona en el sitio móvil de GitHub? La extensión es solo para Chrome desktop. En móvil, copia la URL y ábrela en desktop, o comparte a un Save Vault en Mac.

¿Cuánto cuesta? Save tiene una capa gratuita para que puedas probarlo en algunos repos e issues. Después, una pequeña suscripción cubre uso más intensivo.

Guías Save relacionadas

• Guardar respuestas de Stack Overflow como Markdown --- respuestas aceptadas con bloques de código y comentarios
• Guardar conversaciones de ChatGPT como Markdown --- cada turno, con bloques de código intactos
• Guardar conversaciones de Claude como Markdown --- artefactos, código y razonamiento preservados
• Guardar vídeos de YouTube como Markdown --- transcripción, resumen, timestamps, marcadores de capítulo