RU

Русский — Официальная русская версия 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), а не только в видимом рабочем дереве.

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

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

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

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

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 существовал до первого add.
• Публичная документация, лицензия, безопасность, правила участия, changelog и llms.txt присутствуют.
• README содержит имя репозитория, назначение, установку, использование, конфиденциальность и лицензию.
• Требования к i18n выполнены.
• Баннер, логотип или скриншот присутствуют при необходимости.
• Тесты и дымовые проверки пройдены.
• Проверки конфиденциальности, путей, секретов, баз данных и закодированных символов чисты.
• Описание GitHub, темы (topics), тег, релиз и CI проверены.
• Профиль организации, реестр и ссылки экосистемы обновлены.

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

1.0.0 (2026-06-18)

• Создан начальный протокол обслуживания и публикации репозиториев.