Пусть Codex перепишет ваш скилл по вашим же сессиям

Скилл для ИИ-агента может выглядеть идеально на бумаге и при этом не совпадать с тем, как вы реально работаете.

Какие-то шаги вы постоянно пропускаете. Какие-то повторяете. Часть работы доделываете вручную. Меняете порядок, добавляете проверки, возвращаетесь после неудачных попыток. А скилл продолжает описывать процесс, которого в действительности уже нет.

В Codex Desktop это можно проверить по истории прошлых задач.

Я называю такой приём бэктестом скилла, хотя технически это скорее ретроспективный аудит: Codex находит релевантные задачи, читает их историю и сравнивает реальный ход работы с тем, что предписывает SKILL.md.

Готовый промпт:

Прочитай [название скилла или полный путь к SKILL.md] и проведи его ретроспективный аудит по моим прошлым задачам в Codex Desktop.

Работай только в read-only режиме. Не меняй скилл, файлы, Git и внешние системы.

Используй встроенный список задач Codex и чтение их истории. Не ограничивайся текущим чатом, названиями, preview или memory: memory можно использовать только для поиска кандидатов, но выводы делай по истории самих задач.

Сначала:

1. Найди задачи на тему этого скилла.
2. Покажи список найденных кандидатов: название, дату, краткую причину релевантности.
3. Отдельно укажи, какие задачи вошли в выборку, какие исключены и почему.
4. Если доступ к истории ограничен или релевантных задач мало — скажи об этом прямо и не додумывай отсутствующие данные.

После согласования выборки прочитай выбранные задачи полностью, включая старые ходы, если история разбита на страницы.

Разложи скилл на проверяемый контракт:

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

Для каждой задачи сравни контракт с фактической работой и отметь:

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

Не считай любое отклонение дефектом скилла. Проверь, к чему оно привело:

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

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

Финальный результат выведи в пяти разделах:

- оставить;
- изменить;
- добавить;
- убрать;
- недостаточно данных.

Для каждой рекомендации укажи:

- конкретное правило или фрагмент скилла;
- задачи, на которых основан вывод;
- наблюдаемое evidence;
- ожидаемый эффект;
- уверенность: высокая / средняя / низкая;
- предлагаемую формулировку правки.

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

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

И важное ограничение: Codex видит только то, что зафиксировано внутри его задач. Ручные действия, разговоры и решения вне Codex в такой аудит не попадут.

Запускать его лучше не по календарю, а после 5–10 новых релевантных задач, заметного изменения процесса или повторяющихся переделок. Тогда скилл действительно развивается вместе с вашей работой, а не переписывается из-за одной случайной аномалии.

По теме

Скиллы для ИИ-агентов легко устаревают и начинают жить отдельно от того, как вы работаете на самом деле. Ретроспективный аудит помогает это заметить вовремя.

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

Пусть Codex перепишет ваш скилл по вашим же сессиям

По теме

Если хотите разобрать свою задачу — напишите мне Если хотите разобрать свою задачу — напишите мне.

Если хотите разобрать свою задачу — напишите мне