Смена правил работающей задачи
Запуск Навыка
При явном вызове или однозначном смысловом совпадении применяйте навык сразу.
Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:
Применяю экспериментальный навык «Смена правил работающей задачи» (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.
Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.
Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.
Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.
Обзор
Перенесите принятое пользователем изменение в те источники одной задачи, которые действительно управляют её дальнейшим выполнением. Результат — согласованные действующие правила и проверенный сохранённый следующий шаг. Исправление документа само по себе не доказывает изменение продолжения.
Используйте существующие файлы, журнал и средства управления задачей. Не создавайте собственный механизм исполнения, новый реестр правил или дублирующую автоматизацию.
Естественные Входы
- «Убери это правило из текущей работы и продолжения».
- «Примени новое условие ко всей действующей задаче».
- «Мы поменяли договорённость; обнови сохранённый следующий шаг».
Процесс
1. Установите изменение и его область
Прочитайте known-exceptions.yaml, последние прямые указания пользователя и действующий контракт задачи. Кратко зафиксируйте: какое правило отменяется или меняется, чем заменяется и к какой задаче относится. Предложение, вопрос «стоит ли» и пример не являются принятым изменением. Не переспрашивайте уже сделанный выбор. При неоднозначности уточните только решение, которое нельзя восстановить из доступных источников.
2. Найдите действующие источники
Начните с указанных файлов и переходите по их ссылкам в пределах задачи. Прочитайте управляющую инструкцию, сохранённое состояние, затронутые очереди или черновики и настройки существующего продолжения, если они есть. Отделите действующий источник от справочного примера, архива и журнала прошлых событий. Не требуйте отсутствующих компонентов ради этого списка.
Для каждого найденного источника установите его роль, владельца изменений и способ повторного чтения. Последние прямые указания пользователя определяют изменение в пределах его полномочий; справочник и история не могут восстановить отменённое требование. Не меняйте общую персонализацию или соседние задачи.
3. Исключите исполнение старого шага во время правки
До завершения сверки не выполняйте затронутый следующий шаг. Если файлы или продолжение меняет другой активный исполнитель, согласуйте применение с ним доступным средством координации; не перезаписывайте его состояние по старому снимку. Если владение или безопасный порядок установить нельзя, назовите точное препятствие. Не останавливайте все задачи и не меняйте расписание автоматически.
4. Примените изменение
- Исправьте управляющее правило и противоречащие ему действующие примеры. Сохраняйте остальные ограничения и разрешения.
- Пересмотрите зависимые сохранённые действия, условия переходов и неотправленные черновики. Уберите ожидание отменённого условия; новую проверку примените и к ранее подготовленному действию. Уже отправленные вопросы и полученные ответы остаются историей.
- Обновите существующее продолжение штатным средством по его точному ID. Сохраните прежние расписание, получателя, настройки уведомлений и состояние запуска, если пользователь их не менял. Не создавайте замену существующей автоматизации. Если продолжения нет, не создавайте его ради изменения правила.
- Если в задаче уже ведётся журнал, добавьте запись о смене правила и затронутых источниках; прежние события не удаляйте и не переписывайте. Не заводите новый журнал только для этого навыка.
Перед каждой записью проверьте, что источник не изменился после чтения. При расхождении перечитайте его и пересчитайте только затронутую правку. Используйте имеющиеся проверку версии и механизм записи; не изобретайте параллельную схему состояния.
5. Проверьте сохранённый результат
Заново прочитайте изменённые файлы и сохранённые настройки продолжения через соответствующее средство. Проверьте смысл правил и зависимых действий, а не только наличие или отсутствие прежних слов. Старое упоминание в истории допустимо, исполнимая ссылка на него — нет.
Без сообщения третьему лицу и другого внешнего действия разберите ближайший сохранённый шаг: какие сведения он использует, что теперь допускает или требует и почему отменённое условие больше не блокирует переход. Для новой обязательной проверки покажите, где шаг остановится без её результата. Если есть штатная безопасная проверка без исполнения, используйте её. Это проверка сохранённой логики, а не доказательство будущего поведения исполнителя.
Если одна запись не сохранилась или её нельзя прочитать обратно, не объявляйте изменение полностью применённым. Назовите уже изменённые источники, несогласованную часть и одно действие для завершения. До согласования не выполняйте зависимый шаг; не откатывайте чужие изменения и не обходите недоступное разрешение.
6. Передайте результат
Коротко сообщите «было → стало», где правило теперь сохранено, что подтвердило повторное чтение и какой следующий шаг записан. Отдельно укажите непроверенное исполнение. Применение правила не означает завершение исходной задачи и не даёт права её возобновлять, если она остановлена.
Границы
- Для одиночной правки одного документа без зависимого состояния выполните обычное редактирование; этот процесс не нужен.
- Для выбора нового правила сначала нужно решение пользователя; для восстановления состояния без правок подходит
shag-posle-prervannoy-tseli, для исходного контракта —kontrakt-tseli-do-starta. - Не превращайте отменённый вопрос в равнозначную переформулировку или скрытое условие продолжения. Не добавляйте новых обязательных этапов сверх принятого изменения.
- Не отправляйте пробных сообщений, не совершайте покупок и не запускайте задачу ради доказательства правки. Не отменяйте сохраняющиеся паузы, лимиты и запреты.
- В недоступный источник нельзя считать изменение доставленным только потому, что локальный файл или инструкция уже исправлены.
Опрос После Использования
После выдачи проверенного результата изменения или явного стопа предложите обратную связь. Опрос задаётся один раз — после сдачи финального результата или явного стопа, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.
Опрос по навыку:
1. Что в работе этого навыка было полезно?
2. Что стоит доработать в процедуре или формате ответа?
Можно ответить коротко или написать "пропустить".
Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/smena-pravil-aktivnoy-zadachi/usage-feedback.jsonl — лучше через bundled script:
python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."
Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.
Логирование Сбоев
Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.
Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/smena-pravil-aktivnoy-zadachi/exception-log.jsonl.
Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.