Что получится
У тебя будет спокойная точка входа в проект: понятная папка, чистая Git-картина, зафиксированные решения и минимальный набор проверок. Это скучный шаг, но именно он потом спасает от “почему оно всё поменяло не там”.
Когда это особенно важно
- ты открываешь старый проект и не помнишь его состояние;
- в папке уже есть изменения, которые мог сделать человек;
- нужно добавить новую фичу без случайного рефакторинга;
- проект потом поедет на VPS или в production.
Быстрый порядок
- Убедись, что ты в правильной папке.
- Посмотри, какие файлы уже изменены.
- Найди документы, где записаны решения.
- Запусти базовые проверки.
- Только после этого проси Codex что-то менять.
bash
pwd
git status --short --branch
git log --oneline --max-count=5
Минимальная карта проекта
| Что проверить | Зачем |
|---|---|
| Текущая папка | Не начать работу в соседнем проекте |
git status | Увидеть чужие изменения до правок |
README.md и docs/ | Найти источник решений и этапов |
package.json | Понять стек и команды проверки |
| Последний коммит | Понять, где закончился предыдущий этап |
Как формулировать задачу для Codex
Плохо:
text
Сделай норм.
Лучше:
text
Нужно улучшить страницу гайда: сделать заголовок понятнее, проверить mobile и не трогать чужие изменения.
После правок запусти lint и build.
Проверка после изменений
Минимум для frontend-проекта:
bash
npm run lint
npm run build
Если менялся UI, добавь проверку в браузере: главная, список гайдов, одна страница гайда, мобильная ширина.
Частые ошибки
- начать scaffold поверх папки, где уже есть важные документы;
- принять чужие незакоммиченные изменения за мусор;
- перейти к VPS до локальной сборки;
- попросить агента “улучшить всё” без границ.
Результат
Проект готов к спокойной работе: Codex понимает контекст, ты видишь изменения, а следующий шаг можно проверить командами, а не надеждой.