Codex Plugins и Skills: как собрать собственного AI-разработчика
Как разделить project instructions, повторяемые workflows, integrations и permissions, чтобы агент работал по правилам команды.

Plugins появились раньше июня — обновление 2 июня показало, зачем они нужны

В официальном changelog Codex поддержка plugins появилась 25 марта 2026 года. OpenAI описала их как installable bundles, которые упаковывают Skills, app integrations и конфигурацию MCP server для повторяемых workflows. 2 июня вышел уже конкретный пример такой архитектуры — Sites plugin для создания, публикации и инспекции сайтов из Codex.

Эта хронология важна. Plugin — не ещё один переключатель модели и не магазин декоративных расширений. Он превращает разрозненные инструкции и интеграции в устанавливаемый набор возможностей. Команда получает способ распространять не только доступ к инструменту, но и собственный порядок работы с ним.

Поэтому июньский вопрос для меня звучит не «какой plugin установить», а иначе:

Как собрать из модели, проектных правил, Skills и ограниченных tools разработчика, который выполняет знакомый процесс воспроизводимо?

Модель здесь больше похожа на runtime

Сильная модель знает Laravel, Symfony, Doctrine, PHPUnit и SQL. Но она не знает, что в конкретной команде Controller остаётся тонким, изменение публичного API требует compatibility review, а тесты и Pint запускаются только внутри Docker-сервиса webserver.

Назвать модель «PHP-разработчиком» поэтому недостаточно. Полезнее такая схема:

Model                  = базовая способность рассуждать
AGENTS.md              = контракт конкретного repository
Skill                  = процедура для повторяемой задачи
Plugin                 = устанавливаемый пакет процедур и integrations
Permissions            = граница допустимых действий
Task                   = текущая бизнес-цель

Одна и та же модель с разным окружением может стать Laravel implementer, read-only reviewer или агентом для расследования production incidents. Специализация возникает не в тексте prompt, а в доступном контексте и рабочем контракте.

Task, AGENTS.md и Skill отвечают на разные вопросы

Большой prompt обычно смешивает цель, архитектуру проекта и процесс выполнения. Его трудно обновлять, а главное — приходится повторять в каждом thread. Я делю инструкции на три слоя:

TASK
Добавь блокировку API-токена без изменения response format.

AGENTS.md
Где лежат resources, как устроен auth,
какие команды запускать и что запрещено проектом.

SKILL
Как исследовать, реализовать и проверить
изменение такого типа.

Codex читает AGENTS.md до начала работы и собирает цепочку global и project-specific guidance. Поэтому туда хорошо ложатся инварианты repository: структура, Docker-команды, security rules и definition of done.

Skill нужен там, где повторяется последовательность действий. По документации OpenAI, он может объединять workflow instructions с templates, examples, schemas и другими supporting resources. Это не большой system prompt, а небольшой playbook с ясным условием применения и проверяемым результатом.

Хороший Skill описывает поведение, а не список технологий

Файл под названием php-developer с перечнем «PHP, Laravel, PostgreSQL, Redis» почти ничего не меняет. Модель и так знает эти слова. Полезный Skill для bug investigation задаёт цикл:

1. Прочитать symptom и constraints.
2. Найти существующий flow и похожие tests.
3. Воспроизвести bug до правки.
4. Зафиксировать root-cause hypothesis.
5. Сделать минимальный fix.
6. Повторить reproduction.
7. Запустить узкие и связанные проверки.
8. Просмотреть итоговый diff.
9. Сообщить evidence и оставшиеся риски.

Для новой feature будет другой Skill. Для migration — третий. Я бы не объединял их в одну энциклопедию: trigger становится расплывчатым, контекст растёт, а обновление одной процедуры требует пересматривать всё.

Технология входит в workflow только там, где влияет на действие. Например: сначала запустить targeted PHPUnit test, затем PHPStan на затронутой области; Rector использовать лишь для migration deprecated API и после него обязательно проверить diff. Это уже операционный контракт, а не пожелание «пиши качественный код».

Plugin начинается с маленького устанавливаемого пакета

В Codex plugin — папка с обязательным manifest и опциональными Skills, app mappings, MCP configuration и assets. Минимальный skills-only вариант может выглядеть так:

php-backend/
├── .codex-plugin/
│   └── plugin.json
└── skills/
    ├── investigate-backend-bug/
    │   └── SKILL.md
    ├── implement-laravel-change/
    │   └── SKILL.md
    └── review-php-diff/
        └── SKILL.md

Manifest не должен притворяться архитектурой:

{
  "name": "php-backend",
  "version": "1.0.0",
  "description": "Повторяемые backend workflows для PHP-команды",
  "skills": "./skills/"
}

Plugin имеет смысл, когда Skill уже выдержал несколько реальных задач и его пора устанавливать целиком или передавать коллегам. Пока процедура меняется после каждого запуска, проще держать её как project-local Skill. Упаковка не исправляет слабую инструкцию — она лишь увеличивает радиус её распространения.

Connected tools должны сужать ручной перенос, а не расширять власть агента

Следующий шаг — подключить GitHub или GitLab, Sentry и issue tracker. Тогда investigation может начинаться с исходной задачи и события ошибки, а завершаться проверяемым branch или draft PR. Plugin удобен тем, что собирает Skills и connectors в один распространяемый пакет.

Но наличие connector не означает, что агенту нужен полный доступ. Для bugfix-профиля я бы начинал так:

Git repository   read + branch
Sentry           read-only
Issue tracker    read + comment
Staging DB       selected read-only data
Production DB    no access
Deploy           no access

Permission boundary является частью роли наравне с инструкциями. Reviewer не должен менять код, а implementer — закрывать incident или делать production deploy только потому, что интеграция технически это умеет. Сначала capability отвечает на одну рабочую потребность; дополнительные действия появляются после отдельного security review.

Роль лучше собирать из Skills, чем зашивать роль в один prompt

Для крупной задачи можно использовать одну модель в трёх режимах:

Researcher
read-only → architecture map + unknowns

Implementer
approved plan → minimal diff + tests

Reviewer
independent context → regressions + evidence gaps

Каждая роль получает узкий Skill и соответствующие permissions. Это снижает импровизацию: reviewer всегда читает requirement, полный diff и связанные tests, а researcher не начинает «попутно улучшать» найденный legacy-код.

В статье о Cursor Plugins и компонентах agent environment я разбирал карту Rules, Skills, Subagents, MCP и Hooks. В Codex полезен следующий шаг: один и тот же Skill можно использовать самостоятельно или вложить в plugin, а затем выдать конкретному исполнителю. Получается переносимая процедура, а не уникальный prompt для каждого агента.

Skills нужно версионировать и проверять как код

Ошибочное правило в одном чате портит одну задачу. Ошибочный Skill масштабирует дефект на всех, кто установил plugin. Если инструкция требует всегда отключать cache при stale permissions или писать migration без проверки rollback, автоматизация будет воспроизводить плохую практику аккуратно и быстро.

Поэтому для team Skill нужны owner, review и небольшой eval-набор. Например, backend workflow можно прогнать на трёх известных задачах:

• bug с cache invalidation;
• новый endpoint с authorization;
• Doctrine migration с backward compatibility constraint.

Измерять стоит task completion, лишние файлы в diff, выбранные tests, число human interventions и review time. Это тот же проектный benchmark, который я предлагал для GPT-5.5 в Codex, только объектом оценки становится уже не модель, а роль вместе с её инструкциями и tools.

Начинать нужно с одного надоевшего workflow

Я бы не садился проектировать «собственного AI-разработчика» целиком. Первый кандидат проще: процедура, которую команда повторяет каждую неделю и всё равно объясняет в review.

Практический порядок такой: выбрать один bugfix или endpoint workflow, вынести постоянные правила в AGENTS.md, описать узкий Skill, прогнать его на трёх реальных задачах и только после стабилизации собрать plugin. Connector добавлять тогда, когда копирование issue или Sentry event действительно стало повторяющейся потерей времени.

В результате prompt сокращается до бизнес-цели, но контекст не исчезает. Он переезжает в версионируемые слои:

Model
  + repository contract
  + focused workflows
  + bounded tools
  + permissions
  + evaluation
  = specialized agent

Главный сдвиг Plugins и Skills именно в этом. Команда начинает хранить рядом с кодом не абстрактное «умение писать PHP», а проверенный способ исследовать, менять и проверять свой проект. Модель остаётся runtime. Собственным AI-разработчиком её делает инженерная культура, превращённая в исполняемый и проверяемый контракт.