Мои Codex skills: как мы собираем дисциплину для ИИ-агента

На одном из вебинаров в закрытом чате «Перезагрузка» я показывал, как у меня настроена работа с Codex: не просто чат, не просто генератор кода, а рабочая система с правилами, skills, проверками и понятными режимами работы.

После вебинара участники чата попросили рассказать об этом подробнее. Сначала я хотел просто дать им инструкцию: какие skills поставить и как попросить Codex работать аккуратнее. Но быстро стало понятно, что одной инструкции мало.

Если человек просто скопирует чужую папку .codex, он получит не систему, а чужую кухню: локальные пути, личные правила, привязки к Notion, Linear, внутренним проектам и привычкам конкретного человека. Поэтому я решил собрать отдельный публичный пакет: без персональных данных, без моих локальных настроек, но с самой полезной инженерной логикой.

Так появился репозиторий:

https://github.com/pimenov/codex-first-skills-pack

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

Skill — это маленькая инструкция для Codex. В ней написано, когда она должна включаться, как действовать, какие проверки сделать и где остановиться.

Например, если я говорю: «команда падает, разбери баг», Codex должен не угадывать фикс, а включить debugging workflow: сохранить ошибку, воспроизвести, локализовать причину, сделать минимальное исправление и проверить результат.

Если я говорю: «проверь по актуальным докам», Codex должен не отвечать по памяти, а открыть текущие официальные источники и только потом предлагать решение.

Если я говорю: «разбей на задачи», Codex должен не писать код сразу, а собрать scope, зависимости, stop-lines и критерии готовности.

То есть skill — это не магия. Это способ дать ИИ-агенту рабочую дисциплину.

Зачем это понадобилось

Главная проблема с сильными ИИ-инструментами не в том, что они мало умеют. Часто наоборот: они слишком быстро начинают что-то делать.

Для маленькой задачи это удобно. Но в реальной работе быстро появляются разные режимы:

• сначала надо понять задачу;
• иногда надо спроектировать контракт;
• иногда проверить текущую документацию;
• иногда разложить работу на шаги;
• иногда отладить ошибку;
• иногда доказать поведение тестом;
• иногда остановиться и спросить: «мы точно не самообманываемся?»

Один и тот же стиль ответа не подходит для всех этих ситуаций. Поэтому мы собрали набор skills, которые помогают Codex выбирать правильный режим работы.

Что входит в пакет

В публичный пакет вошли 11 skills:

• context-engineering — собрать правильный контекст перед действием;
• spec-driven-development — определить, что именно строим;
• planning-and-task-breakdown — разложить работу на задачи;
• incremental-implementation — делать изменения маленькими проверяемыми шагами;
• source-driven-development — сверяться с актуальными официальными docs;
• api-and-interface-design — проектировать API, схемы и контракты;
• test-driven-development — доказывать поведение тестом или focused check;
• debugging-and-error-recovery — разбирать ошибки системно;
• code-review-and-quality — делать review перед тем, как считать работу готовой;
• deprecation-and-migration — безопасно убирать старое;
• doubt-driven-review — оспаривать рискованные решения до того, как они станут дорогими.

Этот набор вдохновлён репозиторием addyosmani/agent-skills, но не является его копией. Мы взяли идею коротких installable skills и переработали её под Codex-style workflow.

Как это работает в жизни

Пользователь не обязан помнить точные названия skills. Достаточно говорить нормальным языком:

• «проверь по актуальным docs»;
• «разбей на задачи»;
• «сделай пакет работы»;
• «команда падает, разбери баг»;
• «сначала докажи тестом»;
• «сделай code review»;
• «проверь, не самообманываемся».

Codex должен сам сопоставить такую фразу с нужным skill, прочитать SKILL.md и работать по описанному процессу.

Это особенно полезно в длинных рабочих сессиях. Вместо того чтобы каждый раз объяснять агенту правила заново, мы задаём ему устойчивые рабочие контуры.

Почему я открыл репозиторий публично

Сначала пакет был ответом участникам чата «Перезагрузка»: вот что можно поставить себе, чтобы попробовать похожий workflow.

Но потом стало понятно, что это может быть полезно шире. Многие уже пользуются Codex, но пока работают с ним как с умным чатиком: попросил, получил, поправил, снова попросил. Skills позволяют сделать следующий шаг: превратить Codex в более предсказуемого инженерного партнёра.

Репозиторий специально очищен от моих персональных настроек. Только reusable skills, README, installer, validator и шаблон для AGENTS.md.

Как попробовать

Самый простой способ — дать репозиторий своему Codex и сказать:

Установи skills из репозитория https://github.com/pimenov/codex-first-skills-pack в мой Codex. Сначала прочитай README, сделай безопасную установку, не перезаписывай существующие skills без моего подтверждения, затем скажи, что установлено и нужно ли перезапустить Codex.

Можно установить всё сразу или выбрать только несколько skills, например source-driven-development, debugging-and-error-recovery, test-driven-development и planning-and-task-breakdown.

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

Skills не делают Codex автономным волшебником. Они не заменяют мышление, ответственность и проверку.

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

Для меня это и есть переход от «чат помогает писать код» к нормальной работе с ИИ-агентом.

По теме

• Статья: Мой первый публичный репозиторий на GitHub — и это Codex-скилл для GPT Pro review
• Блог: Codex Record & Replay: покажите рабочий процесс один раз — и он станет навыком
• База знаний: Skills и Plugins в Codex App: установка, использование и создание своих

Если вы уже работаете с Codex, но пока используете его как умный чатик, набор skills — это следующий шаг к предсказуемому инженерному партнёру.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov