Как сохранять репозитории, Issues и PR GitHub в формате Markdown (Руководство 2026)

Контент GitHub разбросан по READMEs, issues, PR, discussions и gists --- и скармливать что-либо из этого LLM мучительно, если это не в Markdown. README уже есть, конечно, но та часть, которая вам действительно нужна, это тред issue с 80 комментариями, где кто-то наконец нашёл обходной путь, или PR, в котором был объяснён breaking change, или discussion, объясняющий, почему API спроектировано именно так. Ничего из этого не находится в одном клике от того, чтобы стать пригодным контекстом для Claude.

Это руководство охватывает все методы конвертации контента GitHub в чистый Markdown --- от одного README до длинного обсуждения PR и целого репозитория.

Зачем сохранять контент GitHub как Markdown?

Markdown --- это формат, который работает везде, куда должно отправляться знание о коде:

• Скормите его LLM --- Claude, ChatGPT, Gemini и локальные модели нативно читают Markdown как контекст, с сохранением блоков кода и идентификаторов языка
• Положите в Obsidian или Notion --- один файл на issue или репозиторий, полностью с поиском, с корректными заголовками
• Заархивируйте тред до того, как он будет залочен или удалён --- мейнтейнеры закрывают issues, репозитории становятся приватными, ваши заметки не должны зависеть от аптайма GitHub
• Постройте офлайн-документацию --- скомпилируйте READMEs из нескольких репозиториев в одну справку
• Цитируйте конкретный комментарий в длинном треде --- вернуться к единственному полезному ответу в issue из 200 комментариев --- это один поиск

Сценарий использования, который двигает большую часть трафика GitHub-в-Markdown в 2026 году, --- это первый: разработчики хотят задать LLM вопрос о библиотеке, баге или дизайн-решении, а вставка URL не даёт модели то, что ей нужно.

Метод 1: Save (Самый быстрый, один клик)

Save --- это расширение Chrome, которое превращает любую страницу GitHub в файл Markdown одним кликом. Оно читает отрендеренную страницу, реконструирует оригинальный Markdown там, где это возможно, и производит что-то, что прямиком ложится в Claude, Obsidian или вашу папку с документацией.

Как это работает:

1. Откройте страницу GitHub в Chrome --- репозиторий, issue, PR, discussion, gist или wiki
2. Нажмите на иконку расширения Save в панели инструментов
3. Файл .md скачивается мгновенно (или попадает в ваш Save Vault, если подключён)

Что вы получаете:

• READMEs с нетронутыми блоками кода, таблицами и заголовками
• Заголовок, тело, статус и тредовые комментарии issue и PR
• Треды discussion с правильной вложенностью
• Связанные референсные issues и @mentions сохранены
• Labels, milestones, assignees как frontmatter
• Блоки кода сохраняют свой идентификатор языка (так подсветка синтаксиса работает в просмотрщиках Markdown)
• Gists (single-file и multi-file) поддерживаются
• Frontmatter с репозиторием, автором, датой, URL и состоянием (open/closed/merged)

Что удаляется:

• Навигация, сайдбары и футер GitHub
• Ряды emoji-реакций под каждым комментарием
• Свёртки “X hidden items” (Save разворачивает и включает их)
• Комментарии ботов от CI, dependabot и stale-bot (переключаемо)
• Повторяющиеся quote-reply, которые просто эхом отзываются на предыдущий комментарий

Лучше всего для: Разработчиков, дебажащих с ИИ, технических писателей, компилирующих документацию, исследователей, архивирующих треды, любого, кто строит личную базу знаний о том, как библиотеки реально работают на практике. Если вам нужен чистый Markdown, который вы вставите в Claude или прочитаете в Obsidian, это самый чистый путь.

Пример вывода

Сохранение треда issue даёт:

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

Этот файл --- в одной вставке от того, чтобы стать пригодным контекстом Claude, в одном нажатии клавиши от того, чтобы стать постоянной заметкой Obsidian.

Метод 2: API GitHub + скрипт

REST и GraphQL API GitHub раскрывают всё --- READMEs, issues, комментарии, diffs PR. Можно написать скрипт, чтобы получать и конвертировать.

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

Лучше всего для: Инженерных команд, строящих пайплайны документации, любого, кто скриптует массовый экспорт issues или PR между многими репозиториями.

Проблемы с этим подходом:

• API возвращает сырые тела Markdown, но сшивать заголовок + тело + комментарии + метаданные в один читаемый файл --- это ваша проблема
• Frontmatter (labels, milestones, assignees, state) требует нескольких вызовов API и ручной сборки
• Порядок комментариев, атрибуция автора и вложенные цепочки ответов требуют кастомной логики
• Rate limits быстро достигаются на больших репозиториях (5 000 запросов/час с аутентификацией)
• Discussions живут за GraphQL API, не REST, так что скрипт превращается в два пайплайна
• Diffs PR и комментарии review --- снова отдельные эндпоинты

Это правильный метод, если вы строите пайплайн. Это overkill для одного issue.

Метод 3: Clone + локальная конвертация (для целых репозиториев)

Для READMEs и документации в репозитории самый простой метод --- клонировать и читать файлы напрямую --- они уже Markdown на диске.

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

Лучше всего для: Разработчиков, которые хотят офлайн-доступа к документации репозитория, или которым нужно скормить целое дерево документации long-context LLM.

Проблемы с этим подходом:

• Работает только для контента, хранящегося в репозитории (READMEs, /docs, wiki, если клонирован отдельно)
• Не захватывает issues, PR или discussions --- те живут в базе данных GitHub, не в git-дереве
• Перекрёстные ссылки между документацией и issues ломаются (#412 не разрешается локально)
• URL изображений в READMEs часто указывают на user-attachments.githubusercontent.com и должны быть переписаны для офлайн-использования
• Вам всё равно нужен скрипт, чтобы объединить и почистить, если хотите один файл

Нормально для “хочу документацию офлайн.” Неправильный инструмент для “хочу этот тред issue из 80 комментариев.”

Метод 4: Ручное копирование из браузера

Метод грубой силы: откройте страницу, выделите всё, вставьте в редактор Markdown, почистите.

Шаги:

1. Откройте issue или PR в браузере
2. Выделите релевантный раздел (или всю страницу)
3. Вставьте в Obsidian, VS Code или другой редактор Markdown
4. Уберите UI-шум (реакции, навигацию, сайдбары) вручную
5. Заново добавьте code fences, исправьте порядок комментариев, добавьте frontmatter

Проблемы с этим подходом:

• Блоки кода теряют свой идентификатор языка и подсветку синтаксиса
• Авторство и временные метки комментариев заканчиваются как свободный текст, не как структурированный frontmatter
• Таблицы в READMEs часто вставляются как обычный текст с tab-разделителями
• Ряды реакций (+1 heart rocket) просачиваются в тело
• Вложенность тредов discussion сводится к плоскому тексту
• Занимает 10 минут на длинный тред; умножьте на каждый issue, который вы сохраняете

Работает на коротком README. Разваливается на реальных тредах issue.

Какой метод вам использовать?

Сценарий	Лучший метод
Вставить issue или PR в Claude	Save --- один клик, структурированный вывод
Заархивировать длинный тред discussion	Save --- вложенность и метаданные сохранены
Построить офлайн-копию документации репозитория	git clone --- READMEs уже Markdown
Массово экспортировать issues между многими репозиториями	GitHub API + скрипт --- программно
Быстро сохранить один README	Save --- пропустите шаг clone
Разовая быстрая справка для личных заметок	Ручное копирование --- работает для коротких страниц

Для большинства разработчиков --- особенно для тех, кто использует контент GitHub как контекст ИИ --- Save --- это ответ. Он производит самый чистый Markdown без какой-либо настройки и обрабатывает длинные треды issue с той же скоростью, что и README.

Граничные случаи, которые обрабатывает Save

• Приватные репозитории. Save использует вашу авторизованную сессию браузера. Если ваш аккаунт GitHub может видеть репозиторий, Save может его прочитать. Никакого API-токена настраивать не нужно.
• Self-hosted GitHub Enterprise. Работает на любом паттерне домена github.*. Save читает отрендеренную страницу, так что пока UI --- стандартный layout GitHub, конвертация работает.
• GitHub Discussions vs Issues. Оба поддерживаются. Discussions получают свою категорию как frontmatter (category: Q&A, category: Announcements) и вложенные ответы как тредовую структуру.
• Diffs PR и изменения файлов. Сохраняются, когда релевантны. Тело PR, комментарии review и разговоры на уровне файлов включаются. Сырой diff сам по себе суммируется, а не сваливается --- обычно вам не нужны 5 000 строк diff в контексте LLM.
• Ряды emoji-реакций. Удаляются. Ряды +1, heart, rocket под каждым комментарием --- это шум для всего, кроме анализа трендов.
• Очень длинные треды issue. Для тредов с сотнями комментариев Save сохраняет тело issue, ответы мейнтейнера, комментарий о решении и маркер “Other comments: N omitted”. Переключаемо на полное включение, если вам нужен каждый ответ.
• Страницы Wiki. Wiki репозиториев поддерживаются. Каждая страница становится одним файлом Markdown, с внутренними wiki-ссылками, переписанными как относительные пути.
• Project boards. Виды project board захватываются как структурированный список: колонка → название карточки → связанный issue/PR. Полезно, чтобы заархивировать спринт перед закрытием.
• Комментарии ботов. Dependabot, stale-bot, CodeQL, GitHub Actions --- все обнаруживаются и переключаемы. По умолчанию выключены, потому что почти всегда добавляют шум.
• Блоки кода с идентификаторами языка. Тег языка triple-backtick (```python, ```rust) сохраняется, так что любой рендерер Markdown или LLM получает подсказку для подсветки синтаксиса.
• Gists. Single-file и multi-file gists оба поддерживаются. Multi-file gists становятся одним файлом Markdown с каждым файлом как секцией.

Сочетайте с вашим рабочим процессом

Вывод Markdown работает везде, где вам это нужно:

• Claude / ChatGPT / Gemini --- вставьте файл, спросите “почему этот issue был закрыт?” или “суммируй дизайн-решение в этом PR”
• Obsidian --- закиньте в ваш vault, свяжите issues с релевантными заметками, ищите по каждой библиотеке, которую вы сохранили
• Notion --- вставьте напрямую, заголовки, таблицы и блоки кода рендерятся правильно
• Cursor / Claude Code --- закиньте файл в проект, ИИ теперь имеет upstream-контекст при предложении исправлений
• Save Vault --- если подключён, каждое сохранение GitHub автоматически попадает туда с репозиторием как тегом и обратными ссылками на другие сохранённые треды

FAQ

Работает ли Save на приватных репозиториях? Да. Использует вашу авторизованную сессию браузера, так что всё, что может видеть ваш аккаунт GitHub, может сохранить Save. Никакой настройки PAT или OAuth не требуется.

Работает ли он на GitHub Enterprise (self-hosted)? Да. Любой UI GitHub поддерживается независимо от домена. Если ваша компания запускает github.acme-corp.com, Save работает и там.

Захватит ли он каждый комментарий в треде из 500 комментариев? По умолчанию Save сохраняет тело issue, ответы мейнтейнера и решение. Для полного треда переключите “Include all comments” в меню расширения перед сохранением.

Правильно ли форматируются блоки кода? Да. Triple-backtick fences и идентификаторы языка сохраняются точно. ```python остаётся ```python, так что любой LLM или просмотрщик Markdown получает подсветку синтаксиса.

Обрабатывает ли он diffs PR? Тело PR, комментарии review и инлайн-разговоры на файлах включаются. Сырой diff суммируется по файлам, а не сваливается целиком --- обычно то, что вам нужно для контекста LLM. Переключите “Include raw diff”, если вам нужен полный патч.

А как насчёт GitHub Discussions? Полностью поддерживаются. Категории, вложенные ответы и статус помеченный-как-отвеченный --- всё приходит как структурированный Markdown.

Сохраняет ли он @mentions и перекрёстные ссылки? Да. Упоминания @username остаются как plain-text упоминания, а ссылки issue #123 сохраняются как есть. Если хотите их как гиперссылки обратно на GitHub, расширение может переписать их при сохранении.

Работает ли он на мобильном сайте GitHub? Расширение только для десктопного Chrome. На мобильном скопируйте URL и откройте на десктопе, или поделитесь в Save Vault на Mac.

Сколько это стоит? У Save есть бесплатный уровень, чтобы вы могли попробовать его на нескольких репозиториях и issues. После этого небольшая подписка покрывает более тяжёлое использование.

Связанные руководства Save

• Сохранение ответов Stack Overflow как Markdown --- принятые ответы с блоками кода и комментариями
• Сохранение диалогов ChatGPT как Markdown --- каждый ход, с нетронутыми блоками кода
• Сохранение диалогов Claude как Markdown --- artifacts, код и рассуждение сохраняются
• Сохранение видео YouTube как Markdown --- транскрипт, резюме, временные метки, маркеры глав