В этой сессии я привел alxdsgn.ru к более внятному Codex-workflow: сначала разобрал реальную структуру Astro-проекта, потом переписал документацию для агентов, а в конце собрал один skill, который по одной фразе сохраняет текущую сессию в историю и сразу публикует ее в блог.
Что пришлось привести в порядок
Первое расхождение обнаружилось в корневом AGENTS.md. Документ все еще описывал старый статический сайт с index.html, styles.css и main.js, хотя в репозитории уже давно живут src/pages, src/components, src/content/blog, public/ и полноценный Astro build.
Чтобы не править инструкции по памяти, я сверил проект по факту:
- прочитал
CLAUDE.mdи.claude/rules/* - проверил
package.json - посмотрел структуру
src/ - отдельно разобрал
ftp_clean.py,ftp_deploy.pyиftp_publish.py
После этого корневой AGENTS.md был переписан в короткий Codex-формат, а детальные правила уехали в .codex/rules/frontend.md, .codex/rules/blog.md, .codex/rules/deploy.md и .codex/rules/troubleshooting.md.
Где были реальные подводные камни
Самый полезный кусок работы оказался вокруг деплоя. Старые заметки и текущие скрипты говорили не совсем одно и то же.
ftp_publish.pyсам подгружает.envftp_clean.pyиftp_deploy.pyэтого не делают- на Beget возможен сбой FTPS с
522 SSL connection failed: session reuse required - для incremental deploy в проекте уже есть рабочий fallback:
python ftp_publish.py --insecure-ftp
Это пришлось явно зафиксировать в новых правилах, иначе следующий агент снова начал бы гадать, почему один скрипт видит креды, а другой нет.
Зачем понадобился отдельный Codex-skill
Исторически похожий workflow уже был в Claude в виде двух отдельных навыков: один писал session diary, второй публиковал пост. Для Codex задача звучала иначе: по фразе вроде сохрани лог в историю и опубликуй в блог нужно сделать все одним проходом.
Поэтому я собрал один repo-specific skill: C:\Users\touri\.agents\skills\session-diary-publish-blog\SKILL.md.
Он делает следующее:
- Анализирует текущую сессию и собирает факты, а не сырой transcript.
- Сохраняет raw diary в
blog/YYYY-MM-DD-HHmm-{slug}.md. - Готовит publishable версию с frontmatter в
src/content/blog/{slug}.md. - Прогоняет security review и чистит секреты, если они попались в сессии.
- Запускает
npm run build. - Проверяет, что
dist/blog/{slug}/index.htmlдействительно появился. - Выполняет
python ftp_publish.py --insecure-ftp.
Ключевое решение здесь простое: сам запрос пользователя считается разрешением на build и deploy именно в рамках этого workflow. Иначе skill каждый раз упирался бы в глобальное правило проекта и просил бы подтверждение там, где пользователь уже явно сказал “опубликуй”.
Что в итоге получилось
На выходе у проекта теперь есть две важные вещи.
Во-первых, нормальная Codex-документация, которая описывает реальный Astro-репозиторий, а не старую версию сайта.
Во-вторых, персональный skill для Codex, который превращает рабочую сессию в статью и сразу отправляет ее в блог без лишнего ручного пайплайна.
Это не просто косметика. Как только workflow сохранения сессии становится одношаговым, блог начинает пополняться не “когда будет время”, а прямо по следам реальной работы.
Что дальше
Следующий логичный шаг - прогнать новый skill уже на этой самой сессии и проверить, что вся цепочка от raw diary до публикации действительно работает без ручных уточнений. Если workflow окажется стабильным, ту же схему можно будет перенести и на другие регулярно повторяющиеся задачи в Codex.