Как переписать skills и AGENTS.md под GPT-6 Astra: чеклист инженера Codex

Эрик Провенчер, разработчик из команды Codex в OpenAI и автор инструмента Repo Prompt, в ночь на 5 сентября опубликовал в X статью «Rethinking skills and prompts for GPT-6 Astra». Тезис простой и неприятный для тех, кто год настраивал кодинг-агентов: инструкции, которые помогали прошлым моделям, с GPT-6 Astra начинают мешать. Раздутые описания skills вытесняют друг друга из контекста, требования «прочитай доки перед каждой правкой» сжигают токены, а строгие запреты, написанные против своевольных предшественников, заставляют новую модель останавливаться там, где вы бы хотели, чтобы она продолжала.

Сама GPT-6 Astra вышла 3 сентября ограниченному кругу организаций, подписчикам Plus, Pro, Business и Enterprise доступ обещали в ближайшие дни, цены и бенчмарки мы разбирали отдельно. Здесь разберём другое: что именно Провенчер советует выкинуть из skill-файлов, AGENTS.md и промптов, чем он это объясняет, где его слова подтверждаются документацией Codex и обновлённым skill-creator, а где это пока наблюдения одного инженера. Заодно посмотрим, как те же правила переносятся на Claude Code, где CLAUDE.md и skills устроены по тому же принципу, и тот же расчёт бюджета работает там точно так же.

Почему инструкции для агента устаревают вместе с моделью

Потому что большинство правил в AGENTS.md и skills написаны против конкретных ошибок конкретной модели, и новая модель этих ошибок может уже не делать. Провенчер формулирует это так: «What used to require a lot of handholding and scaffolding no longer does», то есть ручное ведение и строительные леса, которые были нужны год назад, теперь необязательны. Инструкции, по его классификации, живут в трёх местах: в skill-файлах, в AGENTS.md и в промптах конкретных задач, и пересматривать он предлагает все три.

Здесь стоит сразу отделить проверяемое от заявленного. Что Astra сильнее Sol в агентных задачах, утверждает сама OpenAI по собственным бенчмаркам: 57,7% против 37,3% на Terminal-Bench 4.0, 41,4% против 18,1% на AutomationBench, 72,6% против 65,7% на OSWorld 2.0. Сторонних замеров на момент публикации нет, и в истории с Gemini 3.8 Flash мы уже отмечали, что сравнения с конкурентами остаются словом вендора, пока нет независимых замеров. Что при этом старые инструкции мешают, это наблюдение Провенчера из практики команды Codex, и он сам оговаривается, что речь о накопленных за год привычках, а не о замерах. Но механизм, который он описывает для skills, проверяется по документации, и к нему перейдём.

Что не так со skills, когда их слишком много

Каждый установленный skill стоит контекста ещё до того, как модель его открыла: его имя и описание лежат в списке, по которому модель решает, что подключить. Чем длиннее описания и чем их больше, тем меньше от каждого остаётся в этом списке. Провенчер называет привычку скачивать в проект десятки skills ошибкой:

Many people default to downloading a lot of skills into their projects, but that's a mistake. Each skill comes with a name and description that are loaded into the model's context so it knows when to use them. Many descriptions are far too long, and when you add too many skills, Codex starts shortening their descriptions to fit.

Eric ProvencherCodex DX, OpenAI (перевод: «Многие по умолчанию скачивают в проект кучу skills, и это ошибка. У каждого skill есть имя и описание, которые загружаются в контекст модели, чтобы она знала, когда его применять. Многие описания слишком длинные, и когда skills становится много, Codex начинает укорачивать описания, чтобы уместить их»)

Здесь начинается задокументированное поведение. Документация Codex говорит прямо: начальный список skills, куда входит и путь к файлу каждого skill, занимает не больше 2% окна контекста модели, или 8 000 знаков, если размер окна неизвестен; при переборе Codex сначала укорачивает описания, а при очень большом наборе часть skills вовсе выпадает из списка с предупреждением. В Claude Code механика та же, но бюджет жёстче: 1% окна контекста, а объединённый текст описания одного skill по умолчанию обрезается до 1 536 знаков, это значение настраивается. Обрезка идёт с тех skills, которые вы вызываете реже всего. Проверить, сколько контекста съедает список, в Claude Code можно командой /doctor, а строка Skills в /context показывает размер списка уже после применения бюджета.

Вторая проблема, по Провенчеру, хуже первой: описания начинают конкурировать. Он пишет, что они «могут противоречить друг другу или иметь слишком много энергии «выбери меня»», и модель подключает инструкции, которые задаче не помогают. Его пример из статьи: skill для миграций базы данных с описанием, которое обещает помочь со всем, что связано с базами, будет срабатывать на любую задачу, где встречается база данных, а не только на миграцию. Иллюстрации из оригинала доступны только с логином в X, поэтому ниже пример составлен по смыслу статьи, это не копия её картинки:

			# Плохо: skill будет подключаться на любой вопрос про базу данных
---
name: db-migrations
description: Use for anything related to databases, SQL, migrations, schemas, queries, indexes, performance tuning and data modelling.
---

# Лучше: описание называет одну задачу и границу применения
---
name: db-migrations
description: Create and review database migrations for this repo. Not for ad-hoc queries or schema questions.
---
		

Три правки, которые Провенчер перечисляет для skills, совпадают с принципами обновлённого skill-creator в репозитории Codex. Важная оговорка по датам: этот файл менялся 13 августа, за три недели до релиза Astra, и в статье сказано лишь «we recently updated its guidance», так что называть его «переписанным под Astra» нельзя. Сами правила такие:

1. Описание как можно короче, но так, чтобы было ясно, когда skill применять. В skill-creator этот принцип назван «Keep discovery cheap and precise»: описывать реальную возможность и условия применения, добавлять исключения только там, где они предотвращают ложное срабатывание, избегать исчерпывающих списков возможностей и «catchalls».
2. Прогрессивное раскрытие. Для skill с несколькими сценариями корневой SKILL.md должен быть минимальным маршрутизатором, который отправляет к вспомогательным документам и скриптам. В skill-creator это три стадии: имя и описание видны при выборе, тело SKILL.md загружается при применении, а references и scripts читаются только когда нужны конкретной задаче.
3. Меньше рецептов. Многие skills написаны как подробные маршруты по шагам. Модели, по словам автора, стали лучше понимать нюансы и неоднозначность, поэтому избыточная конкретика теперь вредит там, где раньше помогала. Принцип skill-creator «Match specificity to the risk» говорит то же: фиксированные последовательности и абсолютные формулировки оставлять для операций, где отклонение приведёт к конкретной проблеме.

Как это выглядит в структуре папки, skill-creator показывает на примере skill для развёртывания в облаке: общий выбор провайдера остаётся в корневом файле, а детали каждого провайдера лежат отдельно, и при выборе AWS модель читает только один из трёх файлов:

			cloud-deploy/
|-- SKILL.md
`-- references/
    |-- aws.md
    |-- gcp.md
    `-- azure.md
		

Последний аргумент Провенчера про skills касается командной работы. Skills, закоммиченные в репозиторий, читают агенты других участников, и они могут работать на других моделях: «Guidance that helps Sol or Luna may overconstrain GPT-6 Astra». Отсюда практический вывод: прежде чем вычищать инструкции, решите, для каких моделей они останутся. Если половина команды сидит на GPT-5.6 Sol или на моделях Claude, скаффолдинг ещё пригодится.

Что убрать из AGENTS.md в первую очередь

Первыми кандидатами на вылет Провенчер называет два правила: требование прочитать стопку документации или карту репозитория перед каждой правкой и требование запускать тесты. AGENTS.md действует при любой работе модели в репозитории, поэтому он предлагает пройтись по каждой строке и спросить, нужна ли она всё ещё задаче. Для исправления опечатки обязательный обзор всего проекта избыточен, а Astra, по его словам, сама понимает, что ей нужно прочитать.

Prompting the model to read files before every edit, is a great way to burn context and slow work down.

Eric ProvencherCodex DX, OpenAI (перевод: «Заставлять модель читать файлы перед каждой правкой, это отличный способ сжечь контекст и замедлить работу»)

Ссылки на документацию при этом он не отменяет, но требует, чтобы они были контекстными: указывать на конкретный документ там, где он относится к задаче, и держать сами документы в актуальном состоянии. Устаревший документ, который модель обязана прочитать, хуже отсутствующего.

С тестами история симметричная. Прошлые модели надо было подталкивать проверять свою работу, и в AGENTS.md у многих осталось «всегда запускай тесты после изменений». Astra, утверждает Провенчер, делает это сама, и то же правило теперь приводит к лишним прогонам. Одновременно он оговаривается, что модель работает основательно, но осторожничает в том, как далеко довести задачу, и иногда её нужно подтолкнуть. Инструмент для этого тот же AGENTS.md, только формулировка меняется с запрета на разрешение для конкретного безопасного сценария. Пример из статьи, который можно взять как образец строки для своего файла:

			The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.
		

Обратите внимание на конструкцию: в одной фразе сказано, почему действие безопасно (одноразовые фикстуры, нет доступа к проду), что именно разрешено (запускать, чинить падения от текущего изменения, перезапускать затронутые тесты) и от чего модель освобождается (спрашивать разрешение на каждом шаге). Граница описана через разрешение для конкретного сценария, и это совпадает с принципом skill-creator «Match specificity to the risk».

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

Ответ Провенчера: перепишите запреты, написанные против прошлых моделей, и заранее определите, что считается готовой задачей. Если предыдущая модель что-то делала без спроса, вы наверняка добавили в инструкции жёсткие формулировки «сначала спроси». Astra, по его словам, относится к таким границам всерьёз и остановится там, где вы на самом деле были бы рады продолжению.

GPT-6 Astra has much better judgment, and you should treat it as such. It also takes your boundaries seriously and may stop work where you'd actually be happy for it to continue.

Eric ProvencherCodex DX, OpenAI (перевод: «У GPT-6 Astra заметно лучше суждение, и относиться к ней стоит соответственно. Она также всерьёз воспринимает ваши границы и может остановить работу там, где вы были бы рады, чтобы она продолжила»)

Со стороны это выглядит как смена одного типа ошибок на другой: раньше агент делал лишнее, теперь недоделывает. Провенчер описывает это без прикрас в разделе про настойчивость:

If you're used to GPT-5.6 Sol taking a request and continuing for long stretches, GPT-6 Astra can feel more tentative about when to stop. It may reach a first implementation and come back for your review while there's still work to do.

Eric ProvencherCodex DX, OpenAI (перевод: «Если вы привыкли, что GPT-5.6 Sol берёт запрос и долго работает без остановки, GPT-6 Astra может показаться более нерешительной в том, когда остановиться. Она может дойти до первой реализации и вернуться к вам за ревью, хотя работа ещё не закончена»)

Лечение он предлагает на уровне промпта задачи. Если задача включает запуск реализации, проверку результата и исправление того, что упало, всё это надо перечислить в запросе как часть определения «готово». Требование «остановись на ревью после первой реализации» тянет модель к ранней остановке, и автор советует проверить, действительно ли это решение, которое вам нужно принимать вручную. Если хочется, чтобы модель исследовала дальше первого прохода, надо сказать, что исследовать и где остановиться. Это согласуется с тем, что OpenAI писала в анонсе: Astra задаёт вопрос, когда недостающая информация меняет результат, и заполняет пробелы сама в остальных случаях. Мы приводили это описание в новости о выходе модели, и оно тоже пока не подтверждено сторонними тестами.

GPT-6 Astra и GPT-5.6 Sol на агентных бенчмарках из анонса OpenAI, проценты выполненных задач. Разрыв на этих наборах и есть аргумент, почему инструкции под Sol могут переограничивать Astra. График: Tproger по данным OpenAI, 3 сентября 2026

Скепсис здесь уместен в обе стороны. Что Astra «осторожнее» Sol и «сама запускает тесты», мы знаем со слов инженера OpenAI, а не из воспроизводимого замера. Но и обратное утверждение, что старые инструкции безвредны, ничем не подтверждено: стоимость списка skills в контексте посчитана в документации обоих инструментов, и она не зависит от того, какая модель под капотом.

Как провести аудит своих инструкций по шагам

Ниже чек-лист, собранный из статьи Провенчера и принципов skill-creator. Он одинаково применим к Codex CLI (на 5 сентября 2026 актуальна версия 0.153.4, skills лежат в .agents/skills репозитория или в ~/.agents/skills пользователя) и к Claude Code (.claude/skills в проекте и ~/.claude/skills у пользователя, инструкции репозитория в CLAUDE.md).

1. Посчитайте, сколько стоит список skills. В Claude Code выполните /doctor: он оценит контекст, который занимает список, и назовёт самых тяжёлых. В Codex бюджет списка 2% окна, при переполнении описания укорачиваются и появляется предупреждение о выпавших skills.
2. Удалите skills, которыми не пользуетесь. В Codex skill можно выключить, не удаляя, через [[skills.config]] в ~/.codex/config.toml с enabled = false и path к его SKILL.md, после правки конфига Codex нужно перезапустить; в Claude Code низкоприоритетные skills можно оставить в списке без описания через skillOverrides со значением name-only.
3. Сократите каждое описание до одной задачи и одной границы. Образец из skill-creator: «Create or edit Word documents when formatting, tracked changes, or comments require document-specific handling». Ключевой сценарий ставьте в начало фразы: так советуют обе документации: Codex прямо говорит выносить вперёд ключевой сценарий и триггерные слова, Claude Code советует ставить ключевой сценарий первым из-за капа в 1 536 знаков.
4. Разнесите тяжёлые skills на маршрутизатор и references. Если в SKILL.md несколько сценариев, оставьте в нём общее назначение и критерии выбора, а детали каждого сценария вынесите в отдельный файл, на который есть ссылка с пояснением, когда его читать.
5. Пройдите AGENTS.md или CLAUDE.md построчно. Правила «прочитай X перед любой правкой» замените контекстными ссылками на конкретные документы. Правила «всегда запускай тесты» замените разрешением на конкретный безопасный сценарий по образцу выше.
6. Перепишите запреты в разрешения. Найдите формулировки «никогда не делай без подтверждения», добавленные из-за прошлых моделей, и решите, нужны ли они. Там, где нужны, опишите границу через причину и ограниченную область.
7. Определяйте «готово» в промпте задачи. Перечислите, что входит в завершение: запустить, проверить результат, починить упавшее. Если нужен ранний стоп для ревью, скажите это явно и убедитесь, что это осознанный выбор.
8. Проверьте skills после правки. В комплекте skill-creator есть валидатор: scripts/quick_validate.py <path/to/skill-folder> проверяет frontmatter, имена и незаполненные заготовки, но не качество решений, поэтому описания на дискриминирующую силу придётся проверять глазами.

Кому это не подходит. Если ваша команда или CI работают на GPT-5.6 Sol, Luna или моделях других вендоров, часть скаффолдинга всё ещё делает свою работу, и вычищать её из общего репозитория стоит только после проверки на этих моделях. Провенчер сам оставляет эту оговорку и предлагает думать о том, кто будет читать инструкции после вас. Сама статья заканчивается предложением попросить Astra провести такой аудит по её тезисам; это удобно, но результат аудита, сделанного моделью на собственных инструкциях, стоит просмотреть самостоятельно, прежде чем коммитить.

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

Источники: Eric Provencher. Rethinking skills and prompts for GPT-6 Astra (X, 4 сентября 2026), Профиль Эрика Провенчера в X, skill-creator/SKILL.md в репозитории openai/codex, PR #38384 «Refine skill creation guidance and validation», openai/codex, 13 августа 2026, Документация Codex: Build skills, Документация Claude Code: Extend Claude with skills, Tproger: OpenAI начала выпуск GPT-6 Astra, цены, бенчмарки и кибер-ограничения

Изображение на обложке: Иллюстрация: Eric Provencher, X