Разбираю, как пересобрать старые промпты, skills и AGENTS.md при переходе на GPT-6 Astra: что удалить, что сделать контекстным и какие правила оставить.

GPT-6 Astra и старые промпты: что удалить из skills и AGENTS.md

Когда выходит новая модель, первая реакция обычно одна и та же: что теперь нужно дописать в промпт?
С GPT-6 у меня постепенно сформировался почти противоположный вопрос:

что из старых инструкций теперь можно удалить?

За последние поколения моделей мои инструкции становились всё подробнее.
Когда модель задавала слишком много вопросов, появлялось правило не останавливаться без необходимости.
Когда меняла лишние файлы, появлялось ограничение scope.
Когда забывала проверить результат, появлялось требование запускать тесты.
Когда не читала важный документ, появлялось правило сначала изучить документацию.
Каждое такое правило когда-то решало реальную проблему.

Но через год инструкция легко превращается в архив ошибок предыдущих моделей.
И с GPT-6 этот накопленный слой становится особенно заметен.
Я для себя называю это долгом инструкций.
Это правила, которые когда-то были полезны, но продолжают действовать после того, как причина их появления уже исчезла.

Коротко: что меняется в промптах GPT-6 Astra

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

Что действительно отражает бизнес-логику и должно остаться.
Что было костылём для предыдущей модели и теперь можно удалить.
Что всё ещё нужно, но только в определённом контексте.

Особенно внимательно я бы пересмотрел skills, AGENTS.md, обязательное чтение документов, approval перед каждым шагом, универсальные требования к тестированию и подробные пошаговые сценарии. OpenAI отдельно рекомендует пересматривать эти инструкции при переходе на GPT-6 Astra. Новая модель сильнее следует инструкциям и чувствительнее к правилам из skills и других файлов.

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

Чем лучше модель следует инструкции, тем дороже плохая инструкция

На первый взгляд здесь есть противоречие. Если GPT-6 лучше выполняет инструкции, разве это не означает, что инструкции можно делать ещё подробнее? Не обязательно.
Представим старое правило:

Перед каждым изменением прочитай architecture.md, database.md и deployment.md.

Когда менее сильная модель выполняла его неидеально, вред мог быть почти незаметен. Более дисциплинированный агент действительно будет читать эти документы перед каждым изменением. Даже если задача - исправить опечатку. В результате:

расходуется контекст;
растёт время;
в задачу попадают нерелевантные правила;
увеличивается вероятность конфликта между инструкциями.

OpenAI приводит практически такой же пример в рекомендациях для GPT-6 Astra. Вместо обязательного чтения всех документов предлагается определять, когда каждый из них нужен:

Используй architecture.md для изменений границ сервисов, database.md для изменений схемы данных, deployment.md при подготовке развёртывания.

Первый вариант заставляет модель выполнять процедуру.
Второй показывает ей путь к источнику правды.
Для меня это одно из главных различий между старым и новым подходом к инструкциям.

Я бы не начинал миграцию с переписывания промпта

При переходе на GPT-6 мне кажется важным сначала ничего не улучшать. Если есть рабочая функция, я бы сохранил:

тот же запрос;
те же инструкции;
те же данные;
те же инструменты;
те же права доступа;
те же критерии результата.

И поменял только модель. Так появляется исходная точка сравнения.
Если одновременно заменить модель, переписать промпт, изменить tools и поменять reasoning, потом невозможно понять, что именно улучшило или ухудшило результат.
Первый прогон нужен не для получения идеальной инструкции GPT-6.
Он нужен для ответа на другой вопрос:

какие старые правила стали лишними, слишком строгими или начали мешать?

Это принципиально другой тип миграции.
Я не переношу старую инструкцию на новую модель.
Я проверяю, какие предположения внутри инструкции всё ещё актуальны.

Откуда появляется долг инструкций

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

Никогда не меняй ничего за пределами явно указанных файлов.

Через месяц возникает задача, где для корректного исправления действительно нужно поменять второй связанный файл. Модель останавливается.
Появляется ещё одно правило:

Можно менять связанные файлы, но только после подтверждения.

Потом подтверждения начинают мешать работе.
Добавляется исключение.
Через несколько таких итераций простое требование:

не расширяй scope без необходимости

может превратиться в полстраницы условий.

То же происходит с тестами, вопросами, планами, документацией, использованием инструментов и согласованиями.
В результате проект постепенно начинает описывать не желаемое поведение системы.
Он описывает историю борьбы с предыдущими моделями.

Я бы разделил все старые инструкции на три корзины

При переходе на GPT-6 мне кажется полезным не переписывать файл целиком, а пройти каждое правило отдельно.

1. Оставить

Это правила, которые отражают реальное устройство работы. Например:

не публиковать без подтверждения;
не менять бизнес-логику вне задачи;
использовать конкретный файл как source of truth;
не удалять данные без backup;
соблюдать определённую schema;
считать задачу завершённой только после конкретной проверки.

Такие правила нужны независимо от того, насколько умной стала модель. Это не компенсация слабости модели. Это бизнес-логика или граница ответственности.

2. Удалить

Сюда я бы отправлял правила, которые существуют только из-за старого поведения модели. Например:

всегда сначала составь подробный план;
обязательно прочитай весь репозиторий;
всегда задай пользователю вопросы;
запускай абсолютно все тесты после любого изменения;
перед каждым промежуточным действием проси разрешение;
следуй одному пошаговому алгоритму независимо от задачи.

Если GPT-6 и без такого правила стабильно делает правильную вещь, правило больше не помогает. Оно становится налогом на каждый следующий запуск.

3. Сделать контекстным

Самая интересная категория. Правило всё ещё нужно, но не всегда. Например:

Перед работой прочитай database.md.

Можно превратить в:

При изменении схемы данных используй database.md как источник правды.

Или:

Всегда запускай migration tests.

в:

При изменении миграции запусти migration tests и проверь обратимость.

Инструкция остаётся. Но активируется только там, где имеет смысл.

Progressive disclosure вместо огромного skill

OpenAI отдельно рекомендует для GPT-6 Astra progressive disclosure - постепенную загрузку инструкций. Для меня это один из самых полезных принципов всего обновления.
Представим skill на несколько тысяч строк. В нём есть:

работа с базой;
миграции;
deployment;
rollback;
безопасность;
API;
тестирование;
оформление результата.

Но конкретная задача касается только изменения API. Зачем модели остальные разделы?
Вместо огромного универсального файла корневая инструкция может работать как маршрутизатор:

Если меняется schema базы данных:
используй database-migrations.md.

Если меняется публичный API:
используй api-compatibility.md.

Если готовится production deployment:
используй deployment.md.

Если задача затрагивает security boundary:
используй security-review.md.

Детальная инструкция появляется в контексте только тогда, когда она нужна. Такой подход даёт сразу несколько преимуществ:

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

OpenAI также рекомендует делать описание skill коротким и точным, потому что слишком широкое описание может заставлять модель подключать skill к задачам, для которых он вообще не нужен. Это довольно существенный сдвиг. Skill перестаёт быть большой энциклопедией “как модель должна работать”. Он становится специализированным инструментом с ясным триггером.

`AGENTS.md` тоже нужно регулярно чистить

Особенно внимательно я бы относился к глобальным файлам вроде AGENTS.md.
Они опаснее обычного промпта по одной причине: они действуют почти всегда.
Локальное неудачное правило в одном запросе ломает одну задачу.

Неудачное правило в AGENTS.md постепенно влияет на весь репозиторий.
Например:

Перед любым изменением:
1. изучи полную архитектуру проекта;
2. прочитай документацию базы;
3. составь подробный план;
4. покажи его пользователю;
5. дождись подтверждения;
6. после изменений запусти все тесты.

Когда-то такая инструкция могла серьёзно повышать надёжность агента. С более самостоятельной моделью она может превратиться в постоянный тормоз. Для небольшой локальной задачи большая часть этих действий просто не нужна. OpenAI прямо рекомендует регулярно пересматривать каждую инструкцию в AGENTS.md и спрашивать, действительно ли она ещё нужна.
Я бы добавил второй вопрос:

должна ли эта инструкция вообще быть глобальной?

Если правило относится только к миграциям базы, его место, скорее всего, не в общем AGENTS.md.

Один источник правды для одного поведения

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

в system prompt;
в AGENTS.md;
в skill;
в project instructions;
в task prompt.

Причём немного по-разному. В одном месте:

спрашивай перед любым изменением.

В другом:

самостоятельно выполняй обратимые действия.

В третьем:

всегда сначала согласуй план.

Модель получает три настоящие инструкции. И должна решить, какая важнее. GPT-6 лучше следует длинным инструкциям, но это не отменяет конфликт между самими инструкциями.
Поэтому я бы стремился к простой архитектуре:

одно поведение - один основной источник правды.

Остальные уровни либо ссылаются на него, либо уточняют его в своём узком контексте.

Не все старые approval gates нужны Astra

Отдельная категория долга - подтверждения пользователя. Если старый агент слишком легко совершал действия, естественная реакция:

перед любым действием спроси разрешение.

Безопасно. Но человек постепенно превращается в кнопку Continue. Агент:

прочитал файл;
спросил;
изменил локальный файл;
спросил;
запустил тест;
спросил;
исправил ошибку;
снова спросил.

OpenAI отмечает, что GPT-6 Astra лучше учитывает границы и при слишком строгих инструкциях может остановиться там, где пользователь ожидал продолжения. Поэтому я бы описывал не количество согласований, а тип действия. Например:

Можно выполнять самостоятельно:
- чтение;
- анализ;
- поиск;
- локальные обратимые изменения в рамках задачи;
- запуск безопасных локальных проверок;
- исправление вызванных текущей задачей ошибок.

Требуется подтверждение:
- публикация;
- отправка внешнего сообщения;
- финансовое действие;
- удаление данных;
- изменение production;
- трудно обратимое действие;
- расширение согласованного scope.

Это уже не микроменеджмент агента.
Это модель полномочий.
И она сохраняет смысл при смене модели.

С тестами происходит похожая история

Раньше полезной инструкцией было:

обязательно проверь результат.
Это правило я бы оставил.
А вот:
после любого изменения запускай весь набор тестов

уже не выглядит универсально правильным.

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

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

Требование проверить результат осталось.
Обязательный ритуал исчез.
Интересно, что именно тема GPT-6 Astra testing оказалась одним из немногих поисковых сигналов в дополнительном исследовании этой статьи. Это хорошо совпадает с практической проблемой: вопрос уже не только в том, нужно ли агенту проверять себя, а в том, как не превратить проверку в постоянный избыточный workflow.

Completion criteria становятся важнее подробного маршрута

Есть интересный обратный эффект. Часть старых инструкций можно удалить. Но некоторые вещи, наоборот, стоит определить точнее. В частности - что считать завершённой работой. OpenAI отмечает, что Astra может дойти до первого рабочего варианта и вернуться за обратной связью раньше, чем пользователь считает задачу законченной. Для длинной автономной работы полезно заранее определить, где именно находится конец.
Не:

Исправь авторизацию.

А:

Задача завершена, когда:
- причина ошибки найдена;
- исправление внесено;
- исходный сценарий больше не воспроизводится;
- связанные проверки проходят;
- новые ошибки из-за изменения не появились;
- подготовлен итоговый результат.

Это хороший пример того, как инструкция одновременно становится менее процедурной и более точной.
Я не рассказываю модели, какие десять шагов сделать.
Я определяю состояние системы, в котором работа считается выполненной.
Если нужен более общий разбор этой логики для пользовательских запросов, я уже подробно писал как ставить задачи GPT-5.6 без лишнего микроменеджмента.

Guidance для Astra нельзя автоматически превращать в правила для Luna и Sol

Это тоже важное ограничение. Официальная guidance OpenAI предлагает рекомендации для семейства GPT-6, но уточняет, что описанные поведенческие особенности наблюдались прежде всего у Astra и их нужно проверять на выбранной модели и конкретной нагрузке.

В отдельном материале про skills OpenAI прямо предупреждает: guidance, которая помогает Sol или Luna, может переограничить GPT-6 Astra. Отсюда для меня следует довольно неприятный, но полезный вывод.

Универсальный prompt framework не должен содержать большое количество правил, компенсирующих особенности конкретной модели.
Общими лучше оставить:

цель;
источники правды;
бизнес-ограничения;
scope;
права;
критерии завершения;
способ проверки;
формат результата.

А модельные костыли должны оставаться отдельными и измеряемыми. Если Luna действительно нуждается в дополнительном scaffolding для конкретной функции, его можно добавить. Но переносить этот scaffolding в глобальную инструкцию всей системы уже опасно. Если вопрос в том, какую из Astra, Sol или Luna вообще использовать для функции, я отдельно разобрал их цены, доступность и экономику выбора.

Как выглядит аудит одного старого правила

Представим инструкцию:

Перед каждым изменением обязательно составь подробный план и дождись подтверждения пользователя.

Я бы прогнал её через пять вопросов.

Почему это правило появилось?

Например: старая модель несколько раз начала менять код до того, как поняла задачу.

Существует ли проблема на GPT-6?

Проверяем на реальных задачах. Не предполагаем.

Нужно ли правило всегда?

Возможно, только для сложных или трудно обратимых изменений.

Можно ли заменить его границей?

Например:

Для сложного или трудно обратимого изменения сначала зафиксируй план. Локальные обратимые исправления выполняй без промежуточного согласования.

Как проверить результат?

Сравнить:

число ненужных остановок;
нарушения scope;
долю завершённых задач;
время;
ручные вмешательства.

После этого правило либо остаётся, либо становится контекстным, либо удаляется. Такой аудит для меня намного полезнее, чем просто попросить GPT-6 “оптимизировать промпт”.

Практический порядок миграции

Я бы проходил рабочие процессы последовательно.

Шаг 1. Зафиксировать исходное состояние

Сохранить текущие:

model ID;
prompt;
skills;
AGENTS.md;
tools;
permissions;
reasoning settings;
eval cases.

Шаг 2. Поменять только модель

Не изменять инструкцию одновременно с моделью.

Шаг 3. Прогнать обычные и проблемные задачи

Особенно полезны старые случаи, из-за которых когда-то появились дополнительные правила.

Шаг 4. Найти новое поведение

Например:

лишнее чтение;
лишнее тестирование;
преждевременная остановка;
лишние вопросы;
ненужный approval;
неправильный skill;
конфликт инструкций.

Шаг 5. Сначала попробовать удалить правило

Это важная часть. Раньше при новой ошибке я мог добавить ещё одну инструкцию.
Теперь первым вопросом становится:

какое старое правило заставило модель так себя вести?

Шаг 6. Если правило нужно - сузить его

Сделать контекстным.
Не:

всегда читай deployment.md.

А:

используй deployment.md при подготовке production deployment.

Шаг 7. Проверить систему инструкций на конфликты

Особенно:

system instructions;
AGENTS.md;
skills;
project files;
task prompt.

Шаг 8. Повторить eval

На том же наборе задач.
И измерить не красоту ответа, а работу:

completion rate;
число остановок;
число ручных вмешательств;
ошибки;
нарушения scope;
время;
стоимость.

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

Какой prompt framework у меня остаётся после чистки

После удаления большей части процедурного микроменеджмента структура становится довольно компактной:

Цель:
<какой готовый результат нужен>

Источники правды:
<какие данные и документы имеют приоритет>

Scope:
<что входит в задачу>
<что не менять без необходимости>

Самостоятельность:
<какие действия можно выполнять без подтверждения>

Approval:
<какие действия требуют человека>

Критерии готовности:
<в каком состоянии задача считается законченной>

Проверка:
<как подтвердить результат>

Формат результата:
<что должен получить пользователь>

Большая часть этой структуры не специфична для GPT-6.
Именно поэтому она мне нравится. Она описывает саму работу. А не поведение конкретного поколения модели. В статье GPT-6 Astra против GPT-5.6 я уже разбирал, как такие границы меняются при миграции сложных многошаговых задач. Здесь для меня важнее другой уровень - архитектура всех инструкций вокруг модели.

Некоторые проблемы вообще не надо исправлять промптом

При миграции есть ещё один источник лишних инструкций. Попытка управлять через текст тем, что является параметром системы. Например, reasoning.effort - параметр API, а не заклинание внутри prompt. GPT-6 Astra не поддерживает effort none, тогда как Sol и Luna поддерживают.
То есть фраза:

думай минимально

не заменяет правильную конфигурацию модели.

Точно так же доступ к инструменту должен определяться системой инструментов.
Права - permission layer.
Изменяемые факты - файлами, retrieval или API.
Инструкция должна объяснять, как этим пользоваться.
Не пытаться сама заменить всю инфраструктуру.

Для себя я разделяю это так:

prompt определяет конкретную работу;

instructions определяют устойчивые правила поведения;

skills подключают специализированные workflow;

configuration определяет режим модели;

tools и permissions определяют реальные возможности.

Чем меньше эти уровни дублируют друг друга, тем проще потом менять модель.

Главный вывод

Раньше развитие промптинга часто выглядело как накопление.
Модель ошиблась - добавить правило.
Не закончила - добавить правило.
Спросила лишнее - добавить правило.
Изменила слишком много - добавить правило.

В какой-то момент получается длинная инструкция, каждая строка которой имеет историческое объяснение. Но это ещё не означает, что каждая строка нужна сегодня. GPT-6 для меня стал хорошим поводом поменять направление.
Не:
новая модель -> добавить новые инструкции

А:
новая модель -> перепроверить старые предположения -> удалить лишнее -> сделать оставшиеся границы точнее

Чем лучше модель следует инструкциям, тем выше стоимость плохой инструкции. Поэтому качество agent system теперь всё сильнее зависит не от того, насколько длинный у неё промпт. А от того, насколько чисто устроена сама архитектура правил.
И мой первый вопрос при следующей миграции модели теперь будет не:

что нужно дописать?

А:

какой долг инструкций здесь можно наконец удалить?

FAQ

Нужно ли переписывать старые промпты под GPT-6 Astra?

Не обязательно. Сначала полезно прогнать существующую рабочую инструкцию без изменений, поменяв только модель. Так можно увидеть, какие проблемы действительно появились из-за GPT-6 Astra, а какие старые правила уже просто не нужны.

Почему старые инструкции могут мешать GPT-6 Astra?

GPT-6 Astra сильнее следует инструкциям и чувствительнее к правилам в skills, AGENTS.md и других файлах. Поэтому старое требование читать лишнюю документацию, спрашивать подтверждение перед каждым действием или всегда запускать все тесты может начать выполняться слишком буквально.

Что стоит удалить из `AGENTS.md`?

В первую очередь я бы проверял глобальные правила, которые заставляют агента всегда:

читать весь проект;
показывать подробный план;
останавливаться ради подтверждения обратимых действий;
запускать полный набор проверок;
следовать одной процедуре независимо от типа задачи.

Удалять их автоматически не нужно. Нужно проверить, какую реальную проблему каждое правило сегодня решает.

Как должны измениться skills для GPT-6 Astra?

Описание skill лучше делать коротким и точным. Если skill содержит несколько больших workflow, корневой файл можно превратить в маршрутизатор, который подключает специализированные инструкции только тогда, когда они нужны. OpenAI называет такой подход progressive disclosure.

Что такое progressive disclosure?

Это постепенная загрузка инструкций. Вместо того чтобы всегда помещать в контекст всю документацию, модель получает минимальную корневую инструкцию и открывает дополнительные правила только для текущего workflow. Это уменьшает расход контекста и количество конфликтующих инструкций.

Нужны ли одинаковые инструкции для Astra, Sol и Luna?

Не обязательно. Общими имеет смысл делать бизнес-правила, scope, права, источники правды и критерии готовности. Дополнительный scaffolding под особенности конкретной модели лучше добавлять только после собственного теста.

Источники и границы выводов

Материал подготовлен по состоянию на 24 сентября 2026 года.
Основные источники:

Рекомендации OpenAI по GPT-6 описывают поведение, наблюдаемое прежде всего у Astra. Их нужно проверять на выбранной модели и собственной нагрузке.

Последние публикации

Обсудить цифрового сотрудника для вашей бизнес-задачи