RU

---
name: github-repo-care
version: 1.0.0
type: protocol
author: Lukas Geiger + Codex
created: 2026-06-18
updated: 2026-06-18
aliases: [github-pflege, repo-veroeffentlichen, repo-release, privacy-gate, release-gate]
description: Протокол для безопасного создания, публикации, релиза, аудита и обслуживания репозиториев GitHub: проверка локальных правил и блокировок, создание .gitignore перед первым git add, проверка конфиденциальности, подготовка README/i18n/баннера/метаданных, проверка тегов релиза и релизов GitHub, а также обновление профилей организаций, файлов llms.txt и ссылок в реестрах.

standalone: true
anthropic_compatible: true
bach_compatible: true
bach_origin: false
category: dev
tags: [github, repo, release, privacy, i18n, marketing, ci, documentation]
language: ru
status: active
dependencies: {'tools': ['git', 'gh', 'rg'], 'services': ['GitHub'], 'protocols': [], 'python': []}
provenance: {'origin': 'custom', 'origin_path': '~/.codex/skills/github-repo-care/', 'origin_version': '1.0.0', 'origin_repo': None, 'last_sync_from_origin': '2026-06-18', 'last_sync_to_origin': None, 'local_changes_since_sync': False}
---

<img src="banner.png" width="100%" alt="github-repo-care banner">

> **Русский** — Официальная русская версия `github-repo-care`.


# GitHub Repo Care — Чистая публикация и обслуживание репозиториев (Русский)

## Когда использовать

Используйте этот навык, когда необходимо создать, опубликовать, выпустить релиз, провести аудит или обслужить репозиторий GitHub. Это особенно важно перед первым публичным пушем, для тегов релизов, метаданных репозитория, профилей организаций и проверок конфиденциальности.

Не используйте его для чистой разработки без этапа публикации на GitHub. Сначала завершите соответствующий рабочий процесс разработки или отладки, а затем активируйте этот навык для публикации.

## Основное правило

Подготовьте репозиторий перед первым публичным пушем. Правильный `.gitignore`, проверка конфиденциальности (privacy gate), лицензия, README, метаданные и история релизов обходятся значительно дешевле до появления публичной истории.

## Рабочий процесс и порядок действий

1. **Изучить локальные правила.** Проверьте `AGENTS.md`, `CLAUDE.md`, `START.md`, политику релизов, политику именования и политику блокировок при их наличии.
2. **Проверить блокировки.** Если `LOCK.txt` или соответствующий `LOCK.*.txt` активен, не редактируйте этот область/скоуп.
3. **Зафиксировать идентичность репозитория.** Подтвердите имя, организацию, видимость, лицензию и назначение проекта в одном предложении.
4. **Создать `.gitignore` перед `git add`.** Исключите секреты, локальные данные, базы данных, результат сборки, виртуальные окружения, кэши, файлы IDE и личные заметки.
5. **Добавить базовые публичные файлы.** Типичные файлы: `README.md`, `LICENSE`, `CHANGELOG.md`, `SECURITY.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `llms.txt` и CI.
6. **Написать README для удобства обнаружения.** Первый экран: назначение, установка, использование, модель конфиденциальности, структура проекта, лицензия и каноническое имя репозитория.
7. **Добавить визуальные элементы.** Добавьте баннер, логотип или скриншот, если это облегчает понимание проекта. Избегайте абстрактных декораций, если можно использовать реальное изображение продукта или понятную концептуальную схему.
8. **Осознанно спланировать i18n.** Минимум: английский плюс язык проекта. Предпочтительный стандартный набор для пользовательских модулей: немецкий, английский, испанский, упрощенный китайский, японский и русский.
9. **Запустить тесты и дымовые проверки (smokes).** Выполните локальную проверку перед тем, как заявлять об успехе или создавать релиз.
10. **Пройти проверку конфиденциальности (privacy gate).** Проверьте индексируемый/отслеживаемый набор файлов (staged/tracked) на наличие секретов, локальных путей, персональных данных (PII), `.env`, баз данных, приватных документов, сгенерированных артефактов и поврежденных символов (mojibake).
11. **Закомитить и отправить.** Выполняйте commit только после успешного прохождения проверки. Затем создайте или подключите репозиторий GitHub, сделайте push и проверьте состояние удаленного репозитория.
12. **Установить метаданные.** Проверьте описание (description), темы (topics), домашнюю страницу (homepage), видимость (visibility) и ветку по умолчанию.
13. **Создать релиз.** Создайте тег (tag) и релиз на GitHub (GitHub release); проверьте CI как для ветки, так и для тега.
14. **Обновить точки обнаружения.** Добавьте ссылки из профиля организации, `llms.txt`, центральных реестров, локальных индексов модулей и README экосистемы.
15. **Финальная проверка.** Проверьте удаленный README, страницу релизов, темы (topics), CI и ссылки.

## Проверка конфиденциальности (Privacy Gate)

Ищите в индексируемом или отслеживаемом наборе (staged/tracked), а не только в видимом рабочем дереве.

```bash
git diff --cached --check
git ls-files
rg -n "C:\\\\Us[e]rs\\\\|C:/Us[e]rs/|/c/Us[e]rs/|s[k]-[A-Za-z0-9]|gh[p]_|gh[o]_|API[_-]?KEY|TO[K]EN|PASS[W]ORD|SEC[R]ET|\\x{C3}|\\x{C2}|\\x{FFFD}" .
```

Для публичных модулей также задокументируйте `RELEASE_GATE.md` или аналогичный отчет: дата, проверенные команды, результат, оставшиеся предупреждения и намеренные исключения. Если секрет когда-либо попадал в коммит, простого удаления из `HEAD` недостаточно; ротируйте секрет.

## Метаданные GitHub

После пуша явно настройте метаданные и данные релиза.

```bash
gh repo edit ORG/REPO --description "Short concrete description" \
  --add-topic local-first --add-topic python --add-topic llm
git tag -a v1.0.0 -m "v1.0.0"
git push origin v1.0.0
gh release create v1.0.0 --repo ORG/REPO --title "v1.0.0" --notes "..."
```

Затем проверьте:

```bash
gh repo view ORG/REPO --json nameWithOwner,visibility,description,repositoryTopics,url
gh release view v1.0.0 --repo ORG/REPO --json tagName,url,isDraft,isPrerelease
gh run list --repo ORG/REPO --limit 5
```

Если после релиза CI горит красным, репозиторий еще не опубликован чисто. Для только что созданного первичного релиза допустимо незамедлительно и намеренно переместить свежий тег на исправленный коммит.

## Распространенные ошибки

| Ошибка | Исправление |
|---|---|
| `.gitignore` добавлен после `git add` | Сначала убрать из индекса (unstage), исправить правила игнорирования, затем добавить снова |
| README только на одном языке, хотя UI или навык мультиязычный | Добавить ссылки на языковые версии или локализованные README |
| Отсутствуют баннер, темы (topics) или описание | Добавить ресурсы для обнаружения перед анонсом |
| Тег релиза существует, но CI горит красным | Исправить CI и проверить новый запуск |
| README организации обновлен, но упущен `llms.txt` | Обновить как человекочитаемые, так и машиночитаемые ресурсы |
| Локальный путь отображается в публичной документации | Заменить его относительными путями или общими примерами |
| Публичный репозиторий содержит тестовую базу данных или папку notebook inbox | Удалить из отслеживания, добавить правила игнорирования, повторно запустить проверку |

## Финальный чек-лист

- [ ] Локальные правила и блокировки проверены.
- [ ] `.gitignore` существовал до первого add.
- [ ] Публичная документация, лицензия, безопасность, правила участия, changelog и `llms.txt` присутствуют.
- [ ] README содержит имя репозитория, назначение, установку, использование, конфиденциальность и лицензию.
- [ ] Требования к i18n выполнены.
- [ ] Баннер, логотип или скриншот присутствуют при необходимости.
- [ ] Тесты и дымовые проверки пройдены.
- [ ] Проверки конфиденциальности, путей, секретов, баз данных и закодированных символов чисты.
- [ ] Описание GitHub, темы (topics), тег, релиз и CI проверены.
- [ ] Профиль организации, реестр и ссылки экосистемы обновлены.

## Журнал изменений

### 1.0.0 (2026-06-18)
- Создан начальный протокол обслуживания и публикации репозиториев.