Hardcoding PRO: GitHub для вайбкодера

Начни отсюда: два готовых промпта

Выбери свою ситуацию. Скопируй промпт в Codex / Claude Code и отвечай только на 5 вопросов. GitHub-рутину агент делает сам.

НОВЫЙ ПРОЕКТ

Создать GitHub-проект с нуля

Для новой идеи, бота, сайта, агента, автоматизации или любого другого проекта.

Шаблон: PavelDumbrao/hardcoding-github-vibecoder-starter

Вставь агенту целиком.

Ты мой ИИ-агент по разработке. Я новичок в вайбкодинге и не должен вручную разбираться в Git-командах.

ИСПОЛЬЗУЙ ГОТОВЫЙ ШАБЛОН:
https://github.com/PavelDumbrao/hardcoding-github-vibecoder-starter

Твоя задача: создать МОЙ отдельный GitHub-проект из этого шаблона и дальше вести его через GitHub как единственный источник правды.



GITHUB CLI (gh) - ОБЯЗАТЕЛЬНАЯ ПОДГОТОВКА
Перед GitHub-работой сам проверь, установлен ли официальный GitHub CLI `gh` на текущей машине.

Если работаешь на Mac:
- определи среду;
- если gh отсутствует, установи его официальным способом, предпочтительно через Homebrew, если Homebrew уже используется;
- не заставляй меня вводить команды вручную.

Если работаешь на VPS/Linux:
- определи дистрибутив;
- если gh отсутствует, установи официальный GitHub CLI подходящим официальным способом;
- не используй случайные устаревшие пакеты, если доступен официальный репозиторий GitHub CLI.

После установки:
1. Проверь `gh --version`.
2. Проверь авторизацию через `gh auth status`.
3. Если GitHub не авторизован, попроси меня только пройти безопасный browser/device login. Не проси токен в обычный чат.
4. После авторизации настрой Git credential helper через `gh auth setup-git`, если это нужно текущей среде.
5. Никогда не выводи токен через `gh auth token` или `--show-token`.
6. Если на VPS нет системного credential store и gh сообщает, что авторизация хранится в файле, не печатай токен и защити файл минимальными правами.
7. Если я работаю и с Mac, и с VPS, настрой и проверь gh отдельно на каждой машине, где ИИ будет работать с GitHub.

Через gh сам создавай репозитории, branches, Pull Requests, Issues, Releases, смотри Actions/checks и управляй Secrets там, где это действительно нужно.


СНАЧАЛА НИЧЕГО НЕ СОЗДАВАЙ.

ЗАДАЙ МНЕ РОВНО 5 ВОПРОСОВ ПО ОДНОМУ:

1. Как называется проект и что мы хотим создать?
2. Кто будет пользоваться результатом?
3. Какой конкретный результат должен реально работать в конце?
4. Репозиторий должен быть private или public? Если я не понимаю разницу, объясни двумя предложениями и для бизнес-проекта предложи private.
5. Какая первая полезная функция или задача должна быть сделана прямо сейчас?

После пятого ответа действуй сам.

ЧТО ТЫ ДЕЛАЕШЬ САМ:
1. Проверь, доступен ли GitHub CLI и авторизован ли GitHub.
2. Если авторизации нет, попроси меня только пройти безопасную авторизацию GitHub через браузер. Не проси токены в обычный чат.
3. Создай мой новый репозиторий из шаблона PavelDumbrao/hardcoding-github-vibecoder-starter.
4. Не меняй исходный шаблон.
5. Открой мою копию проекта.
6. Заполни PROJECT.md моими ответами.
7. Обнови TASKS.md так, чтобы там была текущая задача и понятный следующий шаг.
8. Прочитай AGENTS.md и соблюдай его правила.
9. Для первой полезной задачи создай отдельную ветку.
10. Выполни изменения сам.
11. Запусти проверки.
12. Сделай понятный commit.
13. Push в GitHub.
14. Создай Pull Request.
15. Проверь GitHub Actions.
16. Если проверки зелёные, merge в main.
17. После merge убедись, что origin/main содержит итоговую версию.
18. Не оставляй важные изменения только локально.
19. Не коммить .env, API-ключи, токены, пароли, session-файлы и другие секреты.
20. Не проси меня выполнять Git-команды вручную.

В КОНЦЕ ДАЙ МНЕ КОРОТКИЙ ЧЕЛОВЕЧЕСКИЙ ОТЧЁТ:
- ссылка на мой GitHub-репозиторий;
- что сейчас является рабочей версией;
- что ты изменил;
- какие проверки прошли;
- ссылка на Pull Request или commit;
- какая следующая задача записана в TASKS.md.

Главный принцип: я описываю идею и результат. Всю GitHub-рутину делаешь ты.

ПРОЕКТ УЖЕ ЕСТЬ

Перевести существующий проект в GitHub

Для папки на Mac, проекта на VPS, архива или старого репозитория, в котором уже что-то работает.

Безопасный перенос без потерь.

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

Я новичок. Не проси меня вручную выполнять Git-команды, если можешь сделать это сам.



GITHUB CLI (gh) - ОБЯЗАТЕЛЬНАЯ ПОДГОТОВКА
Перед GitHub-работой сам проверь, установлен ли официальный GitHub CLI `gh` на текущей машине.

Если работаешь на Mac:
- определи среду;
- если gh отсутствует, установи его официальным способом, предпочтительно через Homebrew, если Homebrew уже используется;
- не заставляй меня вводить команды вручную.

Если работаешь на VPS/Linux:
- определи дистрибутив;
- если gh отсутствует, установи официальный GitHub CLI подходящим официальным способом;
- не используй случайные устаревшие пакеты, если доступен официальный репозиторий GitHub CLI.

После установки:
1. Проверь `gh --version`.
2. Проверь авторизацию через `gh auth status`.
3. Если GitHub не авторизован, попроси меня только пройти безопасный browser/device login. Не проси токен в обычный чат.
4. После авторизации настрой Git credential helper через `gh auth setup-git`, если это нужно текущей среде.
5. Никогда не выводи токен через `gh auth token` или `--show-token`.
6. Если на VPS нет системного credential store и gh сообщает, что авторизация хранится в файле, не печатай токен и защити файл минимальными правами.
7. Если я работаю и с Mac, и с VPS, настрой и проверь gh отдельно на каждой машине, где ИИ будет работать с GitHub.

Через gh сам создавай репозитории, branches, Pull Requests, Issues, Releases, смотри Actions/checks и управляй Secrets там, где это действительно нужно.


СНАЧАЛА НИЧЕГО НЕ ПУШЬ И НЕ МЕНЯЙ.

ЗАДАЙ МНЕ РОВНО 5 ВОПРОСОВ ПО ОДНОМУ:

1. Что это за проект и какой результат он сейчас даёт?
2. Где сейчас лежит проект: папка на компьютере, VPS, архив, старый GitHub-репозиторий или другое место?
3. Что сейчас точно работает и является последней рабочей версией?
4. Есть ли в проекте секреты: .env, API-ключи, токены, пароли, session-файлы? Если я не знаю, сам потом проведи проверку до первого push.
5. Что мы хотим сделать с проектом следующим?

После пятого ответа действуй сам.

ПОРЯДОК РАБОТЫ:
1. Найди и изучи фактические файлы проекта.
2. Если проект уже Git-репозиторий, сначала изучи remote, ветки, историю и текущее состояние. Не создавай второй репозиторий без причины.
3. Если GitHub ещё нет, создай отдельный repository в моём GitHub. Для клиентского или бизнес-проекта по умолчанию предложи private.
4. ДО ПЕРВОГО PUSH проверь проект на секреты.
5. Создай или дополни .gitignore.
6. Реальные .env, ключи, токены, session-файлы, приватные сертификаты и пароли в GitHub не отправляй.
7. Если обнаружишь, что секрет уже попадал в Git-историю, остановись и скажи, какой секрет нужно перевыпустить. Не маскируй проблему.
8. Создай README.md, PROJECT.md, TASKS.md и AGENTS.md, если их нет.
9. Зафиксируй в PROJECT.md, что является рабочей версией и что нельзя сломать.
10. Сделай первоначальные проверки проекта.
11. Только после этого создай чистый commit и push.
12. Для следующей доработки используй отдельную ветку.
13. После изменений: тесты → commit → push → Pull Request → GitHub Actions → merge в main.
14. Не используй force push на рабочий main без отдельной доказанной необходимости и моего явного подтверждения.
15. В конце проверь origin/main и убедись, что GitHub действительно содержит актуальную рабочую версию.

В КОНЦЕ ДАЙ МНЕ:
- ссылку на репозиторий;
- что было найдено;
- что сейчас считается рабочей версией;
- были ли найдены секреты;
- какие проверки прошли;
- что находится в main;
- какая следующая задача записана в TASKS.md.

GitHub должен стать памятью проекта. Если я открою новый чат через неделю, другой ИИ должен суметь восстановить состояние проекта из GitHub.

Создать копию шаблона Открыть GitHub-шаблон

GitHub для вайбкодера как память проекта — GitHub хранит проект, ИИ делает изменения, проверки подтверждают результат, а рабочая версия остаётся доступной.

Главная мысль

GitHub для вайбкодера = память проекта + история + страховка + рабочее место для ИИ.

Ты ставишь задачу→ИИ читает GitHub→делает изменения→проверяет→GitHub сохраняет результат

Ты не обязан помнить команды. Но должен понимать логику: рабочая версия не должна теряться, каждое важное изменение должно быть видно, а ИИ в новом чате обязан восстановить контекст из репозитория.

Весь практикум

0. Два стартовых промпта 1. Что такое GitHub простыми словами 2. Зачем GitHub вайбкодеру 3. Семь слов, которые нужно понять один раз GitHub CLI (gh): даём ИИ руки на Mac и VPS 4. GitHub Actions: автоматические проверки и деплой 4. Новый проект, шаблон или существующий проект 5. Безопасный workflow с ИИ Pull Request Template: единый стандарт изменений 7. Практика: шесть реальных результатов 7. Готовые рабочие промпты 9. GitHub Secrets: где хранятся ключи и токены 9. Что не надо делать 10. Когда GitHub настроен правильно

1. Что такое GitHub простыми словами

Представь Google Drive для проекта, который помнит не только файлы, но и каждое изменение.

Хранилище проекта

Код, файлы, инструкции, тесты и документация лежат в одном месте.

История

Видно, что менялось и когда. Можно сравнить версии и вернуться назад.

Рабочая среда для ИИ

Агент читает фактический проект, а не пытается вспомнить его по старому чату.

Репозиторий - это просто отдельный дом для одного проекта.

GitHub для вайбкодера простыми словами — GitHub как центр управления проектами и ИИ: код, история, структура, проверки и результат.

2. Зачем GitHub именно вайбкодеру

не потерять проект, даже если сменился компьютер или чат;
дать Codex / Claude Code точный актуальный контекст;
видеть, что именно поменял ИИ;
не ломать рабочую версию новыми экспериментами;
откатиться, если изменение оказалось плохим;
автоматически запускать тесты;
передать проект другому агенту или человеку;
иметь понятное портфолио реальных проектов;
строить деплой и обновления вокруг одного источника правды.

GitHub для вайбкодера: зачем он нужен — Проект хранится в GitHub, ИИ видит актуальный контекст, история сохраняется, а результат можно развивать дальше.

3. Семь слов GitHub, которые нужно понять один раз

Repository / репозиторий
Проект целиком: файлы + история + настройки.

Commit
Контрольная точка. ИИ закончил понятный кусок работы и зафиксировал состояние.

Branch / ветка
Безопасная отдельная линия для эксперимента. Рабочий main не ломается.

Pull Request
Предложение добавить изменения из ветки в рабочую версию. Здесь видно, что именно меняется и какие проверки прошли.

Main
Главная рабочая ветка. Здесь должна находиться подтверждённая стабильная версия проекта.

GitHub Actions
Автоматические проверки: тесты, сборка, безопасность, иногда деплой.

Release
Зафиксированный выпуск продукта: например v1.0, v1.1 или v2.0.

Не надо учить команды наизусть. Нужно понимать, что делает ИИ и почему рабочая версия защищена.

Семь слов GitHub для вайбкодера — Repository, commit, branch, Pull Request, main, GitHub Actions и release — базовая логика проекта без ручного Git.

GitHub CLI (`gh`): развязываем ИИ руки

GitHub в браузере нужен тебе. GitHub CLI нужен твоему ИИ-агенту.

Главная идея: если Codex / Claude Code имеет терминал и авторизованный gh, он может сам выполнять почти всю GitHub-рутину: создавать репозитории, Pull Request, Issues, Releases, смотреть Actions, checks и безопасно настраивать Secrets.

MAC

На твоём Mac

ИИ проверяет, установлен ли gh. Если нет, сам устанавливает официальный GitHub CLI подходящим способом. На Mac нормальный путь обычно через Homebrew, если он уже используется.

Тебе остаётся только один раз подтвердить вход в свой GitHub через безопасный браузерный flow.

VPS

На сервере

ИИ определяет Linux-дистрибутив и сам устанавливает официальный GitHub CLI. Потом авторизует GitHub через безопасный browser/device flow и проверяет доступ.

Если агент работает и на Mac, и на VPS, авторизация проверяется отдельно на каждой машине.

Что ИИ получает через `gh`

Репозитории

Создать, клонировать, посмотреть настройки и открыть проект.

Pull Request

Создать PR, посмотреть diff, дождаться checks, сделать review и merge.

Actions

Смотреть workflow, запуски, логи и результат автоматических проверок.

Issues / Projects

Создавать задачи, обновлять backlog и связывать код с задачами.

Secrets

Создавать и проверять наличие Secrets без хранения значения в репозитории.

Releases

Создавать стабильные версии, tags и release notes.

Важно: не надо давать ИИ токен текстом в чат. Нормальный путь - gh auth login с безопасным подтверждением аккаунта. После этого ИИ проверяет состояние через gh auth status. Команды, которые показывают сам токен, в обычной работе не нужны.

Бонус: современные версии GitHub CLI также могут поддерживать официальный agent skill для работы coding agents с gh. Это полезное усиление, но не обязательное условие Hardcoding PRO.

Подходит для Mac и VPS.

Развяжи себе руки для работы с моим GitHub через официальный GitHub CLI `gh`.

Я новичок. Не заставляй меня вручную устанавливать пакеты и вводить Git-команды, если у тебя есть терминал.

Сделай сам:

1. Определи текущую ОС и среду: Mac или VPS/Linux.
2. Проверь, установлен ли `gh`.
3. Если `gh` отсутствует:
   - на Mac используй официальный способ установки GitHub CLI, предпочтительно Homebrew, если Homebrew уже используется;
   - на Linux/VPS определи дистрибутив и используй официальный способ установки GitHub CLI для этого дистрибутива.
4. Проверь `gh --version`.
5. Проверь текущую авторизацию через `gh auth status`.
6. Если GitHub не авторизован:
   - НЕ проси меня отправлять Personal Access Token в чат;
   - запусти безопасный browser/device login;
   - попроси меня только подтвердить вход в GitHub в браузере, если это необходимо.
7. После авторизации снова проверь `gh auth status`.
8. Настрой Git credential helper через `gh auth setup-git`, если это нужно текущей среде.
9. Не используй `gh auth token` или `gh auth status --show-token` в обычной работе и не печатай секретные значения.
10. Если credential store недоступен на VPS и gh хранит авторизацию в локальном файле, не показывай значение токена и выставь минимально необходимые права на файл.
11. Проведи безопасный smoke-test:
   - покажи мой активный GitHub account;
   - прочитай список моих доступных репозиториев или открой текущий repo;
   - ничего не меняй и не создавай без необходимости.
12. Если я использую и Mac, и VPS, повтори настройку отдельно на каждой машине, где ИИ должен работать с GitHub.

После проверки объясни мне простыми словами:
- где установлен gh;
- под каким GitHub account он авторизован;
- может ли ИИ создавать PR, смотреть Actions и работать с репозиториями;
- нужно ли мне сделать ещё одно ручное действие.

Не показывай токены и секреты.

GitHub Actions: твой автоматический технарь внутри GitHub

Ты отправил изменения в GitHub, а дальше GitHub сам может проверить проект, собрать его и даже развернуть на сервере.

Pull Request

GitHub Actions

Тесты

Зелёный результат

Merge в main

Что такое Actions простыми словами

Это автоматические сценарии внутри GitHub. Они запускаются сами, когда происходит нужное событие: например, создан Pull Request, отправлен новый commit, изменения попали в main или ты нажал кнопку ручного запуска.

Где это находится

В репозитории есть вкладка Actions. Там видно каждый автоматический запуск: что выполнялось, какие шаги прошли и где возникла ошибка.

Что Actions может делать за тебя

запускать тесты при каждом Pull Request;
проверять стиль и качество кода;
собирать приложение;
проверять, что проект вообще запускается;
создавать готовые файлы и артефакты;
проводить проверки безопасности;
автоматически выкатывать проверенную версию на VPS или облако;
запускаться по расписанию;
запускаться вручную кнопкой;
останавливать плохое изменение до попадания в рабочую версию.

Очень упрощённо: файл внутри .github/workflows/ говорит GitHub: «когда произошло X, сделай Y и проверь Z». Писать этот файл руками тебе не нужно, его создаёт ИИ.

Событие

Например: создан Pull Request или изменения отправлены в main.

Job

Отдельная автоматическая работа, например «проверить проект» или «развернуть на сервере».

Steps

Конкретные шаги внутри работы: скачать код, поставить зависимости, запустить тесты, собрать продукт.

Для вайбкодера главное: ты не пишешь Actions вручную. Ты говоришь ИИ: «настрой автоматическую проверку проекта перед merge», а он сам определяет стек, создаёт workflow, запускает его и показывает зелёный результат.

ИИ сам определит, какие проверки нужны проекту.

Настрой в моём GitHub-проекте нормальный GitHub Actions workflow.

МОЙ РЕПОЗИТОРИЙ:
[ВСТАВЬ ССЫЛКУ НА GITHUB]

Я новичок. Не проси меня писать YAML или Git-команды вручную.

Сделай сам:

1. Изучи README.md, PROJECT.md, AGENTS.md и фактическую структуру проекта.
2. Определи стек проекта и какие проверки реально имеют смысл.
3. Посмотри, какие тесты, линтеры, сборка и другие проверки уже существуют.
4. Не придумывай тяжёлую инфраструктуру без необходимости.
5. Создай или аккуратно обнови workflow внутри .github/workflows/.
6. Минимум workflow должен запускаться на Pull Request.
7. Если это безопасно для проекта, добавь проверку push в main.
8. Workflow должен:
   - получить код проекта;
   - подготовить нужную среду;
   - установить зависимости;
   - запустить тесты;
   - запустить проверку кода, если она уже используется проектом;
   - проверить сборку или запуск, если это применимо.
9. Если workflow требует секреты, НЕ записывай их в YAML. Используй GitHub Secrets.
10. Выставь минимально необходимые permissions для workflow.
11. Не выводи секреты в логи.
12. Работай через отдельную ветку.
13. Сделай commit и push.
14. Создай Pull Request.
15. Дождись выполнения GitHub Actions.
16. Если workflow красный, сам изучи логи и исправь проблему.
17. Повторяй до зелёного результата.
18. Merge в main только после успешных проверок.
19. После merge проверь, что Actions на итоговой версии работают как задумано.

В КОНЦЕ ПОКАЖИ МНЕ:
- какие Actions ты настроил;
- на какие события они запускаются;
- какие проверки выполняются;
- ссылку на успешный запуск;
- ссылку на Pull Request;
- итоговый commit в main.

Не говори «готово», пока не существует фактического зелёного запуска GitHub Actions.

4. Три способа начать проект

С НУЛЯ

Новый репозиторий

Когда есть только идея. ИИ создаёт структуру, README, PROJECT, TASKS и первый commit.

БЫСТРО

Template Repository

Берём проверенный шаблон и создаём новый независимый проект с готовой структурой. Именно так работают наши Hardcoding PRO starters.

УЖЕ ЕСТЬ

Подключить существующий проект

ИИ сначала изучает фактические файлы и секреты, потом аккуратно делает GitHub источником правды.

Template ≠ Fork. Для нового продукта из нашей заготовки обычно нужен template. Fork чаще нужен, когда ты хочешь изменить чужой проект и потенциально отправить изменения обратно автору.

Новый проект через GitHub за пять шагов — Идея → ИИ создаёт репозиторий → структура → первый commit → готовая база для вайбкодинга.

5. Безопасный workflow, который ИИ должен делать сам

main не трогаем напрямую для заметных изменений.

origin/main→feature branch→ИИ меняет код→тесты→Pull Request→GitHub Actions→merge в main

Почему это безопасно

Если эксперимент плохой, main остаётся рабочим. Изменения можно посмотреть до объединения.

Почему это удобно с ИИ

Агент сам ведёт технический процесс, а ты получаешь ссылку на PR и понятный результат.

Безопасный GitHub workflow с ИИ — Рабочая версия main → ветка → изменения ИИ → тесты → Pull Request → Actions → merge.

Pull Request Template: ИИ всегда объясняет изменения одинаково

Pull Request не должен выглядеть как «что-то поменял, вроде работает». Шаблон заставляет ИИ каждый раз показать результат по одной понятной структуре.

Где хранится: .github/pull_request_template.md. Когда создаётся новый Pull Request, GitHub подставляет содержимое шаблона в описание PR.

Что должно быть в каждом PR

что изменено;
зачем это нужно;
как проверено;
какие есть риски;
не попали ли секреты;
обновлена ли документация;
прошли ли GitHub Actions;
готово ли изменение к merge.

Почему это особенно важно с ИИ

ИИ может делать много изменений очень быстро. PR Template заставляет его остановиться и сформулировать факты: что он реально сделал, что проверил и почему изменение безопасно объединять.

Если проект потом возьмёт другой ИИ или человек, история Pull Request становится понятной документацией проекта.

Шаблон Hardcoding PRO

# Что изменено

Коротко опиши результат человеческим языком.

# Зачем

Какую задачу пользователя или проекта решает это изменение?

# Как проверено

- [ ] Локальные тесты прошли
- [ ] Проверка кода прошла, если используется
- [ ] Сборка или запуск проверены, если применимо
- [ ] GitHub Actions зелёные
- [ ] Ключевой пользовательский сценарий проверен

# Риски

Что может затронуть изменение?

# Безопасность

- [ ] Нет `.env`, токенов, API-ключей, session-файлов и других секретов
- [ ] Новые секреты хранятся безопасно
- [ ] Не добавлены лишние права

# Перед merge

- [ ] Изменение соответствует задаче
- [ ] TASKS.md обновлён, если нужно
- [ ] README / PROJECT.md обновлены, если поведение изменилось
- [ ] Рабочая версия main не ломается

ИИ сам добавит шаблон в проект.

Добавь в мой GitHub-проект единый Pull Request Template для работы с ИИ.

МОЙ РЕПОЗИТОРИЙ:
[ВСТАВЬ ССЫЛКУ]

Я новичок. Настрой всё сам через GitHub и `gh`.

1. Сначала изучи AGENTS.md, README.md, PROJECT.md и текущий workflow проекта.
2. Создай `.github/pull_request_template.md`.
3. Шаблон должен быть коротким и заставлять автора PR указывать:
   - что изменено;
   - зачем;
   - как проверено;
   - риски;
   - безопасность и отсутствие секретов;
   - GitHub Actions;
   - готовность к merge.
4. Если проекту нужен более специфический шаблон, адаптируй его под проект, но не делай огромную анкету.
5. Обнови AGENTS.md: ИИ обязан использовать PR Template для заметных изменений и заполнять его фактическими данными.
6. Не ставь галочки формально. Галочка означает, что проверка действительно выполнена.
7. Проведи изменение через отдельную branch.
8. Commit → push → создай Pull Request через `gh`.
9. Убедись, что тело PR заполнено по шаблону.
10. Запусти GitHub Actions.
11. Если checks зелёные, merge в main.
12. После merge проверь, что `.github/pull_request_template.md` находится в main.

В конце дай:
- ссылку на PR;
- путь к шаблону;
- итоговый commit;
- подтверждение зелёных checks.

GitHub CLI и Pull Request Template для ИИ-агента — GitHub CLI даёт ИИ руки внутри GitHub, а Pull Request Template делает каждое изменение понятным и проверяемым.

Практика: шесть результатов подряд

Практика 1. Создай свой GitHub-проект

Используй первый стартовый промпт. Ответь на 5 вопросов. ИИ должен создать твою копию шаблона, заполнить PROJECT.md и провести первую задачу до main.

Что сказать ИИ

Вставь в Codex / Claude Code целиком.

Я новичок в вайбкодинге. Помоги мне пройти практику Hardcoding PRO и создать мой первый нормальный GitHub-проект.

ИСПОЛЬЗУЙ ШАБЛОН:
https://github.com/PavelDumbrao/hardcoding-github-vibecoder-starter

Я не должен писать Git-команды руками. Всю техническую работу с GitHub делаешь ты.

Сначала задай мне РОВНО 5 вопросов ПО ОДНОМУ:
1. Как называется проект и что мы хотим создать?
2. Кто будет пользоваться результатом?
3. Какой конкретный результат должен реально работать в конце?
4. Репозиторий должен быть private или public? Если я не понимаю разницу, объясни двумя предложениями и предложи безопасный вариант.
5. Какая первая полезная функция или задача должна быть сделана прямо сейчас?

После пятого ответа:
1. Создай МОЮ отдельную копию GitHub-проекта из шаблона.
2. Не меняй исходный Hardcoding PRO шаблон.
3. Заполни PROJECT.md моими ответами.
4. Обнови TASKS.md.
5. Прочитай AGENTS.md и соблюдай его правила.
6. Для первой задачи создай отдельную feature-ветку.
7. Выполни задачу сам.
8. Запусти проверки.
9. Сделай понятный commit.
10. Push ветки.
11. Создай Pull Request.
12. Проверь GitHub Actions.
13. Если проверки зелёные, merge в main.
14. Проверь, что origin/main содержит результат.
15. Не коммить .env, API-ключи, токены, session-файлы и другие секреты.
16. Не проси меня выполнять Git-команды вручную.

В КОНЦЕ ПОКАЖИ:
- ссылку на мой GitHub-репозиторий;
- ссылку на Pull Request или commit;
- что находится в main;
- какие проверки прошли;
- какая следующая задача записана в TASKS.md.

Не говори «готово», пока не доказал фактический результат через GitHub.

Что должно получиться:

Собственный GitHub-репозиторий создан из шаблона.
PROJECT.md заполнен под реальный проект.
TASKS.md содержит текущую и следующую задачу.
Первая задача прошла через отдельную ветку и Pull Request.
GitHub Actions зелёные.
Результат находится в main.
ИИ дал ссылку на репозиторий и итоговый commit.

Практика 2. Добавь одну функцию через Pull Request

Возьми промпт «Добавить функцию безопасно» ниже. Выбери маленькое улучшение и заставь ИИ провести его через отдельную ветку.

Что сказать ИИ

Вставь в Codex / Claude Code целиком.

Добавь в мой текущий проект одну небольшую полезную функцию через правильный GitHub-процесс.

МОЙ РЕПОЗИТОРИЙ:
[ВСТАВЬ ССЫЛКУ НА СВОЙ GITHUB]

ФУНКЦИЯ:
[ОПИШИ ОДНИМ-ДВУМЯ ПРЕДЛОЖЕНИЯМИ, ЧТО ХОЧЕШЬ ДОБАВИТЬ]

Я новичок. Не проси меня писать Git-команды или код.

Сделай сам:
1. Прочитай README.md, PROJECT.md, TASKS.md, AGENTS.md и последние commits.
2. Синхронизируйся с origin/main.
3. Убедись, что main рабочий и чистый.
4. Создай отдельную feature-ветку под эту функцию.
5. Реализуй только нужное изменение, не переписывая проект с нуля.
6. Добавь или обнови тесты.
7. Запусти все доступные проверки.
8. Сделай понятный commit.
9. Push ветки.
10. Создай Pull Request.
11. В Pull Request коротко опиши: что изменено, зачем и как проверено.
12. Проверь GitHub Actions.
13. Если проверки зелёные, merge в main.
14. После merge проверь origin/main.
15. Обнови TASKS.md.

В КОНЦЕ ДАЙ:
- ссылку на Pull Request;
- какие проверки прошли;
- commit в main;
- простое описание новой функции;
- подтверждение, что main снова является рабочей версией.

Не говори «готово», пока изменение не находится в main после успешных проверок.

Что должно получиться:

Создана отдельная feature-ветка.
Функция реализована и проверена.
Создан Pull Request с понятным описанием.
GitHub Actions зелёные.
Pull Request объединён в main.
ИИ дал ссылку на PR и итоговый commit.

Практика 3. Научись возвращаться назад

На тестовом или безопасном изменении используй промпт отката. Главная цель не сломать проект, а понять, что GitHub хранит путь назад.

Что сказать ИИ

Вставь в Codex / Claude Code целиком.

Проведи безопасную практику отката через GitHub и покажи мне, как вернуть проект к рабочему состоянию, не уничтожая историю.

МОЙ РЕПОЗИТОРИЙ:
[ВСТАВЬ ССЫЛКУ НА СВОЙ GITHUB]

ВАЖНО:
- не делай force push в main;
- не удаляй историю;
- не ломай рабочий проект специально, если для демонстрации можно использовать уже существующее тестовое или неудачное изменение;
- если нет безопасного примера для отката, сначала создай маленькое тестовое изменение в отдельной ветке и объясни, что именно будет откатываться.

Сделай сам:
1. Изучи commits, branches и Pull Requests.
2. Найди последнюю подтверждённую рабочую точку.
3. Определи изменение, которое можно безопасно отменить для практики.
4. Выбери безопасный способ возврата, сохранив историю.
5. Создай отдельную ветку для revert или исправления.
6. Выполни откат.
7. Запусти тесты.
8. Сделай commit.
9. Push.
10. Создай Pull Request.
11. Проверь GitHub Actions.
12. Merge после зелёных проверок.
13. Проверь, что main снова содержит ожидаемое рабочее состояние.

В КОНЦЕ ПОКАЖИ МНЕ:
- какая версия была рабочей точкой;
- что именно было отменено;
- ссылку на Pull Request;
- commit после отката;
- какие проверки прошли;
- почему история проекта при этом не потерялась.

Цель практики: я должен увидеть, что ошибка в проекте не означает потерю проекта.

Что должно получиться:

ИИ нашёл рабочую контрольную точку.
Откат сделан без удаления истории и без force push в main.
Создан Pull Request на возврат рабочего состояния.
Проверки прошли.
Main снова содержит ожидаемую рабочую версию.
ИИ дал ссылку на PR и commit отката.

Практика 4. Открой новый чат и ничего не объясняй

Создай новый чат с ИИ. Дай только ссылку на GitHub и промпт восстановления контекста.

Что сказать ИИ

Вставь в Codex / Claude Code целиком.

Это новый чат. Продолжаем работу над моим проектом, но я НЕ буду пересказывать прошлую переписку.

МОЙ GITHUB:
[ВСТАВЬ ССЫЛКУ НА РЕПОЗИТОРИЙ]

Сначала ничего не меняй.

Сам восстанови контекст только из GitHub:
1. README.md
2. PROJECT.md
3. TASKS.md
4. AGENTS.md
5. последние commits
6. текущий main
7. открытые branches
8. открытые Pull Requests
9. последние GitHub Actions
10. Issues и Releases, если они используются

После этого дай мне короткий отчёт:
- что это за проект;
- что уже реализовано;
- что сейчас является рабочей версией;
- какой commit находится в main;
- какие задачи открыты;
- есть ли незавершённые Pull Requests;
- проходят ли GitHub Actions;
- какой следующий логичный шаг.

Если данных в GitHub недостаточно, скажи КОНКРЕТНО чего не хватает. Не придумывай контекст из воздуха.

После отчёта остановись и жди мою следующую задачу.

Цель практики: доказать, что GitHub хранит контекст проекта даже когда чат с ИИ новый.

Что должно получиться:

Новый ИИ-чат сам понял, что это за проект.
Он назвал текущую рабочую версию и commit в main.
Он перечислил открытые задачи из TASKS.md.
Он увидел Pull Requests и GitHub Actions.
Он предложил логичный следующий шаг.
Ты не пересказывал ему прошлый чат.

Путь вайбкодера с GitHub — От понимания GitHub и шаблонов до AI-workflow, деплоя и реального проекта.

Практика 5. Настрой GitHub Actions

Теперь GitHub будет сам проверять изменения до попадания в рабочую версию.

Что сказать ИИ

Вставь в Codex / Claude Code целиком.

Настрой GitHub Actions для моего проекта и доведи автоматическую проверку до зелёного результата.

МОЙ РЕПОЗИТОРИЙ:
[ВСТАВЬ ССЫЛКУ]

Я новичок. Не проси меня писать workflow YAML вручную.

Сделай сам:
1. Изучи проект и существующие проверки.
2. Определи минимальный полезный набор GitHub Actions.
3. Создай отдельную ветку.
4. Настрой workflow в .github/workflows/.
5. Workflow должен запускаться на Pull Request.
6. Добавь тесты, линтер, сборку или проверку запуска только если они реально применимы к проекту.
7. Если нужен secret, не вставляй его в YAML и не проси значение в чат. Используй GitHub Secrets.
8. Используй минимальные permissions.
9. Commit → push → Pull Request.
10. Дождись Actions.
11. Если запуск красный, сам изучи logs, исправь причину и повтори.
12. Merge только после зелёного результата.
13. После merge проверь Actions ещё раз, если workflow запускается на main.

В конце дай:
- ссылку на Actions run;
- что именно проверяется автоматически;
- ссылку на PR;
- commit в main.

Цель: я должен увидеть настоящий зелёный GitHub Actions run.

Что должно получиться:

В репозитории появился workflow внутри .github/workflows/.
Он запускается автоматически на Pull Request.
GitHub Actions выполнил реальные проверки проекта.
Первый красный запуск, если он был, ИИ сам диагностировал и исправил.
Есть ссылка на зелёный Actions run.
Изменения объединены в main только после успешных проверок.

Практика 6. Подключи секрет безопасно

На этой практике ты увидишь разницу между секретом в чате, локальным .env и специальным хранилищем GitHub Secrets.

Что сказать ИИ

Вставь в Codex / Claude Code целиком.

Помоги мне безопасно подключить один секрет к GitHub Actions и доказать, что он используется без попадания в код.

МОЙ РЕПОЗИТОРИЙ:
[ВСТАВЬ ССЫЛКУ]

СЕКРЕТ:
[НАПРИМЕР BOT_TOKEN ИЛИ TEST_API_KEY]

ВАЖНО:
- не проси значение секрета в обычном чате;
- не добавляй секрет в код, README, workflow YAML или .env.example;
- не печатай секрет в логах.

Сделай сам:
1. Проверь .gitignore и Git-историю.
2. Убедись, что реальный .env не отслеживается.
3. Объясни одним предложением, почему этому workflow вообще нужен этот секрет.
4. Если секрет workflow не нужен, остановись и не добавляй его.
5. Если нужен, используй Repository Secret или более подходящий уровень.
6. Дай мне только название секрета и путь:
   Settings → Secrets and variables → Actions.
7. После того как я безопасно добавлю значение, проверь только наличие секрета, не значение.
8. Подключи secret к тестовому или реальному workflow безопасным способом.
9. Workflow не должен выводить значение секрета.
10. Запусти Actions.
11. Докажи, что workflow зелёный.
12. Проверь, что secret не оказался в diff, commits или logs.

В конце покажи:
- название секрета;
- уровень хранения;
- какой workflow использует его;
- ссылку на зелёный Actions run;
- подтверждение, что значение не попало в Git.

Что должно получиться:

Определено, действительно ли секрет нужен workflow.
Реальное значение не появилось в чате или Git.
Секрет хранится в GitHub Secrets на правильном уровне.
Workflow использует secret без вывода его значения.
GitHub Actions зелёный.
ИИ подтвердил, что secret отсутствует в diff и Git-истории.

Шесть результатов — отметь, что реально сделал0/6

Создан собственный GitHub-репозиторий и первая задача дошла до main.
Одна функция прошла через отдельную ветку и Pull Request.
Ты безопасно вернулся к рабочей версии без уничтожения истории.
Новый ИИ-чат восстановил проект только по ссылке GitHub.
GitHub Actions реально проверяет Pull Request и показывает зелёный run.
Секрет подключён через GitHub Secrets и не попал в чат, diff или историю Git.

7. Готовые промпты для работы через GitHub

Копируй нужный блок. Техническую работу делает агент.

Добавить функцию безопасно

Feature → PR → main.

Реализуй следующую функцию в моём проекте:

[ОПИШИ ФУНКЦИЮ ЧЕЛОВЕЧЕСКИМ ЯЗЫКОМ]

Работай строго через GitHub.

1. Сначала восстанови фактический контекст из README.md, PROJECT.md, TASKS.md, AGENTS.md, последних commits, открытых Pull Requests и GitHub Actions.
2. Синхронизируйся с origin/main.
3. Создай отдельную feature-ветку.
4. Реализуй функцию сам.
5. Добавь или обнови тесты.
6. Запусти локальные проверки.
7. Сделай понятный commit.
8. Push ветки.
9. Создай Pull Request с объяснением: что изменено, зачем и как проверено.
10. Проверь GitHub Actions.
11. Если проверки зелёные, merge в main.
12. После merge проверь origin/main.
13. Обнови TASKS.md.
14. Не говори «готово» без фактического commit/PR/checks/main.

В конце дай мне только результат человеческим языком.

Исправить баг

Не переписывать всё с нуля.

Исправь проблему в моём проекте:

[ОПИШИ, ЧТО НЕ РАБОТАЕТ]

Не начинай переписывать проект.

1. Восстанови состояние из GitHub.
2. Найди последнюю рабочую версию и изменения после неё.
3. Воспроизведи проблему.
4. Найди первопричину.
5. Создай отдельную fix-ветку.
6. Исправь минимально необходимое.
7. Добавь тест, который ловит эту ошибку.
8. Прогони проверки.
9. Commit → push → Pull Request → GitHub Actions.
10. Merge только после успешных проверок.
11. Перепроверь проблему после merge.
12. Обнови TASKS.md.

Не проси меня разбираться в коде. Покажи мне только причину, что исправлено и доказательство проверки.

Проверить Pull Request

Перед merge.

Проведи полноценную проверку текущего Pull Request в моём GitHub-проекте.

Проверь:
- соответствует ли изменение исходной задаче;
- нет ли случайных лишних файлов;
- не попали ли секреты;
- не ломается ли существующий функционал;
- есть ли тесты;
- проходят ли GitHub Actions;
- понятны ли изменения;
- можно ли безопасно объединять в main.

Если найдёшь проблему, исправь её в этой же ветке, снова прогони проверки и обнови Pull Request.

Не merge, пока проверки не зелёные.

В конце скажи простыми словами:
- что меняется;
- что проверено;
- есть ли риски;
- готов ли Pull Request к merge.

Безопасно откатиться

Без force push в main.

Последнее изменение проекта оказалось неудачным. Верни проект к рабочему состоянию безопасно через GitHub.

НЕ удаляй историю и не делай force push в main.

1. Изучи историю commits и Pull Requests.
2. Определи, какое изменение сломало проект.
3. Найди последнюю подтверждённую рабочую точку.
4. Выбери безопасный способ отката, сохранив историю.
5. Создай отдельную ветку для исправления или revert.
6. Запусти тесты.
7. Создай Pull Request на возврат рабочего состояния.
8. Проверь GitHub Actions.
9. Merge после успешных проверок.
10. После merge докажи, что main снова содержит рабочую версию.

В конце покажи:
- что было причиной;
- к какой рабочей точке вернулись;
- какой commit/PR это подтвердил;
- что теперь находится в main.

Продолжить в новом чате

GitHub восстанавливает контекст.

Продолжаем работу над этим проектом:

[ВСТАВЬ ССЫЛКУ НА GITHUB-РЕПОЗИТОРИЙ]

Это новый чат. Не проси меня пересказывать прошлую работу.

Сначала НИЧЕГО НЕ МЕНЯЙ.

Сам восстанови контекст из GitHub:
1. README.md
2. PROJECT.md
3. TASKS.md
4. AGENTS.md
5. последние commits
6. открытые branches
7. открытые Pull Requests
8. последние GitHub Actions
9. Issues, если они используются
10. Releases, если они есть

После этого дай мне короткий статус:
- что это за проект;
- что уже работает;
- какая версия сейчас в main;
- какие задачи открыты;
- есть ли незавершённые Pull Requests;
- проходят ли проверки;
- какой следующий логичный шаг.

Только после этого жди мою задачу.

GitHub является источником правды. Не восстанавливай состояние проекта из догадок или памяти старого чата.

Проверить секреты

Перед публикацией и деплоем.

Проведи проверку безопасности секретов в моём GitHub-проекте.

1. Проверь .gitignore.
2. Найди .env, ключи, токены, пароли, session-файлы, сертификаты и другие чувствительные файлы.
3. Проверь, не отслеживаются ли они Git.
4. Проверь историю Git на явные утечки секретов доступными безопасными средствами.
5. Убедись, что в репозитории хранится только .env.example без реальных значений.
6. Если секрет нужен GitHub Actions, используй GitHub Secrets или другой штатный защищённый механизм.
7. Не печатай значения секретов в отчёте.
8. Если секрет уже был опубликован, не ограничивайся удалением файла: скажи, что его нужно перевыпустить.
9. Исправления делай через отдельную ветку и Pull Request.
10. После изменений проверь GitHub Actions.

В конце дай мне список: безопасно / требует действия / секрет нужно перевыпустить.

Сделать Release

Зафиксировать стабильную версию.

Подготовь новую стабильную версию проекта через GitHub Release.

1. Убедись, что main актуален.
2. Все обязательные GitHub Actions должны быть зелёными.
3. Проверь незавершённые критические задачи и Pull Requests.
4. Определи понятный номер версии на основе истории проекта.
5. Создай tag.
6. Создай GitHub Release.
7. Сформируй короткие release notes человеческим языком: что нового, что исправлено, что важно пользователю.
8. Если проект собирает готовые файлы, приложи только проверенные артефакты.
9. Не публикуй секреты и служебные файлы.

В конце дай ссылку на Release и скажи, какая версия теперь считается стабильной.

Превратить идеи в Issues

Backlog без хаоса.

Преврати мои идеи и проблемы по проекту в понятный GitHub backlog.

Вот мои мысли:
[ВСТАВЬ СПИСОК ИДЕЙ, БАГОВ И ХОТЕЛОК]

Сам:
1. Изучи проект и существующие Issues.
2. Удали смысловые дубли.
3. Раздели идеи на баги, функции, улучшения и технические задачи.
4. Создай небольшие понятные Issues.
5. Для каждого Issue укажи результат, критерий готовности и важные ограничения.
6. Расставь разумный приоритет.
7. Если задача слишком большая, разбей её на подзадачи.
8. Не меняй код.

В конце покажи мне только краткий список созданных задач по приоритету.

Сделать свой шаблон

Для повторных проектов.

Создай из текущего проекта безопасный GitHub Template Repository, чтобы я мог использовать его как основу для будущих проектов.

1. Удали из шаблона данные конкретного клиента и персональные данные.
2. Удали секреты и реальные .env.
3. Оставь .env.example.
4. Сделай понятный README с инструкцией «Use this template».
5. Добавь AGENTS.md с правилами для ИИ.
6. Оставь только универсальную структуру и действительно полезные примеры.
7. Добавь автоматическую проверку GitHub Actions.
8. Убедись, что шаблон запускается или проходит свои проверки.
9. Отметь репозиторий как Template Repository.
10. Создай отдельный тестовый репозиторий из шаблона и проверь, что он действительно стартует независимо.

В конце дай ссылку на шаблон и результат теста.

GitHub Secrets: специальный сейф для ключей

Да, секреты в GitHub хранятся в специальном защищённом месте, а не в коде и не в .env внутри репозитория.

Для обычного репозитория путь: Repository → Settings → Secrets and variables → Actions → New repository secret.

REPOSITORY

Секрет репозитория

Доступен workflow этого конкретного репозитория. Самый понятный вариант для обычного проекта.

ENVIRONMENT

Секрет окружения

Например, отдельные секреты для production и staging. Доступ к ним можно дополнительно защищать правилами окружения и подтверждением деплоя.

ORGANIZATION

Секрет организации

Один секрет можно безопасно дать нескольким выбранным репозиториям организации.

Локальный .env и GitHub Secrets — это разные вещи

Локальный .env

Нужен приложению на твоём компьютере или сервере. Реальные значения лежат локально и исключаются через .gitignore.

GitHub Secrets

Нужны автоматизациям GitHub Actions. Workflow получает секрет через специальный механизм GitHub, а не читает его из файла в репозитории.

Не путай: GitHub Variables подходят для обычных настроек, которые не являются секретными. API-ключи, токены и пароли должны храниться как Secrets, а не Variables.

Что туда обычно кладут

BOT_TOKEN Telegram-бота;
API_KEY ИИ-провайдера;
ключи платёжных систем;
пароли и токены деплоя;
ключ доступа к облаку или VPS, если выбран именно такой способ деплоя;
DATABASE_URL с паролем, если workflow действительно должен его использовать.

Главное правило: workflow получает только те секреты, которые ему реально нужны. Если секрет не нужен автоматической проверке или деплою, не надо добавлять его в GitHub «на всякий случай».

ИИ настроит структуру, значение секрета вводишь безопасно.

Настрой секреты для GitHub Actions в моём проекте безопасно.

МОЙ РЕПОЗИТОРИЙ:
[ВСТАВЬ ССЫЛКУ НА GITHUB]

Я новичок. Не проси меня вставлять реальные ключи и токены в обычный чат.

СНАЧАЛА:
1. Изучи проект и .github/workflows/.
2. Определи, какие секреты действительно нужны GitHub Actions.
3. Не добавляй секреты «на всякий случай».
4. Отдели обычные настройки от секретных:
   - секретные значения → GitHub Secrets;
   - обычные неопасные настройки → GitHub Variables или конфигурация проекта.

ДАЛЬШЕ:
5. Покажи мне только НАЗВАНИЯ нужных секретов, без значений.
6. Для обычного проекта используй Repository Secrets.
7. Если проект имеет production/staging и это реально полезно, предложи Environment Secrets.
8. Если один секрет должен безопасно использоваться несколькими репозиториями организации, только тогда предложи Organization Secret.
9. Реальные значения не записывай в код, README, YAML, .env.example, commit или логи.
10. Убедись, что реальный .env исключён через .gitignore.
11. Если у тебя есть безопасный локальный способ добавить secret через GitHub CLI без вывода значения в чат, подготовь его.
12. Иначе дай мне короткий путь в интерфейсе:
    Repository → Settings → Secrets and variables → Actions → New repository secret.
13. После того как я добавлю секрет, проверь только его НАЛИЧИЕ и имя. Не пытайся вывести значение обратно.
14. Подключи secret к workflow только там, где он реально нужен.
15. Не печатай secret в логах.
16. Запусти GitHub Actions и докажи, что workflow работает.
17. Если секрет уже был случайно закоммичен или опубликован, не считай удаление достаточным. Скажи, что его нужно перевыпустить.

В КОНЦЕ ДАЙ:
- список названий Secrets;
- где они хранятся: repository / environment / organization;
- какие workflows их используют;
- ссылку на успешный GitHub Actions run;
- подтверждение, что реальных секретов в Git-истории не появилось.

Секреты в GitHub — Код хранится в GitHub, реальные ключи — нет. Для автоматизаций используются защищённые GitHub Secrets.

GitHub как машина времени

Если новая функция сломала проект, история позволяет увидеть изменения и безопасно вернуться к рабочей точке, не удаляя всю историю.

9. Что не надо делать

хранить один проект одновременно в пяти разных папках и считать каждую рабочей версией;
просить ИИ менять большой проект прямо в main без проверки;
делать commit с секретами;
использовать force push в рабочий main просто потому, что «так быстрее»;
создавать новый репозиторий каждый раз, когда агент потерял контекст;
мерджить красные GitHub Actions;
делать огромный Pull Request из десяти несвязанных задач;
считать локальный файл источником правды, если проект уже ведётся через GitHub.

10. Когда GitHub для вайбкодера настроен правильно

Definition of Done GitHub-системы0/15

у проекта один понятный GitHub-репозиторий;
README объясняет, что это за проект;
PROJECT.md хранит цель и ключевые ограничения;
TASKS.md показывает, что делаем сейчас и дальше;
AGENTS.md объясняет ИИ правила работы;
секреты не находятся в репозитории;
заметные изменения идут через отдельную ветку;
есть Pull Request и автоматические проверки;
main является рабочей версией;
можно безопасно найти прошлую рабочую точку;
новый ИИ-чат восстанавливает контекст по одной ссылке GitHub;
готовую версию при необходимости можно оформить Release.
На каждой машине, где ИИ работает с GitHub, установлен и проверен GitHub CLI gh;
ИИ умеет через gh создавать PR, смотреть Actions и работать с репозиториями без ручных кликов пользователя;
В main лежит .github/pull_request_template.md, а ИИ использует его для заметных изменений.

Финиш: ты больше не боишься потерять проект. GitHub хранит факты, а ИИ берёт на себя техническую рутину.

GitHub настроен правильно, когда проект переживает новый чат, ошибку и неудачное изменение — а ИИ всё равно может восстановить контекст и безопасно продолжить работу.

Метод Hardcoding PRO для нового GitHub-проекта — Ты описываешь идею, ИИ создаёт GitHub-основу, фиксирует историю и доводит проект до рабочего результата.

Что дальше

Теперь GitHub становится общей основой для всех следующих практик Hardcoding PRO.

Telegram-боты

Каждый бот создаётся из шаблона и дальше живёт в собственном GitHub-репозитории.

Mini Apps и сайты

Тот же процесс: repo → ветка → ИИ → tests → PR → main → deploy.

ИИ-агенты

GitHub хранит код, инструкции, tools и историю изменений агента.

Автоматизации

Сценарии, микросервисы и конфигурации не теряются и развиваются как нормальные проекты.

Hardcoding PRO и GitHub — GitHub + ИИ превращают идеи в проекты, которые можно продолжать, проверять и развивать.

Начни отсюда: два готовых промпта

Создать GitHub-проект с нуля

Перевести существующий проект в GitHub

Главная мысль

Весь практикум

1. Что такое GitHub простыми словами

Хранилище проекта

История

Рабочая среда для ИИ

2. Зачем GitHub именно вайбкодеру

3. Семь слов GitHub, которые нужно понять один раз

GitHub CLI (`gh`): развязываем ИИ руки

На твоём Mac

На сервере

Что ИИ получает через `gh`

Репозитории

Pull Request

Actions

Issues / Projects

Secrets

Releases

GitHub Actions: твой автоматический технарь внутри GitHub

Что такое Actions простыми словами

Где это находится

Что Actions может делать за тебя

Событие

Job

Steps

4. Три способа начать проект

Новый репозиторий

Template Repository

Подключить существующий проект

5. Безопасный workflow, который ИИ должен делать сам

Почему это безопасно

Почему это удобно с ИИ

Pull Request Template: ИИ всегда объясняет изменения одинаково

Что должно быть в каждом PR

Почему это особенно важно с ИИ

Шаблон Hardcoding PRO

Практика: шесть результатов подряд

Практика 1. Создай свой GitHub-проект

Что сказать ИИ

Практика 2. Добавь одну функцию через Pull Request

Что сказать ИИ

Практика 3. Научись возвращаться назад

Что сказать ИИ

Практика 4. Открой новый чат и ничего не объясняй

Что сказать ИИ

Практика 5. Настрой GitHub Actions

Что сказать ИИ

Практика 6. Подключи секрет безопасно

Что сказать ИИ

7. Готовые промпты для работы через GitHub

Добавить функцию безопасно

Исправить баг

Проверить Pull Request

Безопасно откатиться

Продолжить в новом чате

Проверить секреты

Сделать Release

Превратить идеи в Issues

Сделать свой шаблон

GitHub Secrets: специальный сейф для ключей

Секрет репозитория

Секрет окружения

Секрет организации

Локальный .env и GitHub Secrets — это разные вещи

Локальный .env

GitHub Secrets

Что туда обычно кладут

GitHub как машина времени

9. Что не надо делать

10. Когда GitHub для вайбкодера настроен правильно

Что дальше

Telegram-боты

Mini Apps и сайты

ИИ-агенты

Автоматизации

Закрепил результат? Продолжай по карте