Pravilo Iz Zhurnala Sboev

Skill Exception Reviewer

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю «Разбор повторяющихся сбоев рабочего рецепта»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

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

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

Обзор

Этот skill превращает сбои skill-а и пользовательский фидбек в проверяемые предложения по улучшению. Он не занимается саморефлексией исполнителя и не переписывает skill автоматически. Его задача - прочитать приватные карточки ошибок и карточки опроса после использования, отделить повторяемые или дорогие сигналы от случайного шума и предложить точечный patch proposal.

Базовый цикл:

exception card -> grouped failure -> known exception -> example/test idea -> human approval -> git commit

Естественные Входы

Запускайте skill по обычным формулировкам:

• "разбери exception log skill";
• "сделай reviewer по сбоям skill";
• "преврати эти карточки ошибок в patch proposal";
• "что добавить в known-exceptions";
• "skill снова повторил ошибку, разбери лог";
• "какое правило нужно добавить в SKILL.md после этого сбоя".

Режимы Охвата

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

• ONE_SKILL — один явно названный skill. Читайте только его стандартные файлы exception-log.jsonl и usage-feedback.jsonl.
• LIBRARY_WIDE — вся библиотека. Используйте только по явной просьбе вроде «проверь все журналы библиотеки». После проверки корня ~/.codex/skill-runs/ перечислите непосредственные каталоги skills и в каждом читайте только два стандартных файла выше.

Если пользователь сказал лишь «журналы» и нельзя понять, нужен один skill или вся библиотека, задайте один короткий вопрос об охвате. Не выбирайте широкий обход по умолчанию.

Приватный журнал — пассивный файл, а не очередь и не автоматизация. Наличие журнала само по себе ничего не запускает. Пока reviewer явно не вызван, состояние его содержимого — NOT_REVIEWED.

Перед выводами покажите карту охвата: выбранный режим, проверенный корень, число найденных каталогов skills, число прочитанных стандартных файлов и статус каждого ожидаемого файла:

• NO_LOG_FILE — файла нет; это не означает, что сбоев не было;
• EMPTY — файл есть, но в нём нет карточек;
• MALFORMED — файл нельзя безопасно разобрать; не пропускайте его молча;
• REVIEWED — карточки прочитаны и учтены.

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

Процесс

1. Зафиксируйте ONE_SKILL или LIBRARY_WIDE и карту охвата.
2. Определите источник:
   • локальный exception-log.jsonl;
   • локальный usage-feedback.jsonl — карточки опроса после использования (liked / improve / outcome);
   • вставленные пользователем очищенные карточки ошибок или фидбека;
   • краткий фрагмент диалога, если raw log недоступен.
3. Проверьте privacy boundary:
   • не переносите raw private logs, PII, приватные пути, токены, клиентские переписки или скриншоты в repo;
   • если вход содержит приватные детали, сначала предложите sanitized summary.
4. Сгруппируйте сигналы:
   • повторяющийся сбой;
   • один дорогой или рискованный сбой;
   • единичный слабый сбой, который пока не должен становиться правилом;
   • пожелание из опроса: повторяющееся или явно дешёвое в реализации идёт в proposal как правка SKILL.md или example (без записи в known-exceptions.yaml — она только для сбоев), единичное вкусовое остаётся в приватном логе. В LIBRARY_WIDE дополнительно отделите общий сбой нескольких skills от локального сбоя одного skill. Общее правило направляйте в подходящий общий документ, проверку, персонализацию или отдельное архитектурное предложение; не копируйте его механически во все skills.
5. Для каждого кандидата сформулируйте:
   • наблюдаемый симптом;
   • root cause;
   • что делать в следующий раз сразу;
   • какой пример или regression test нужен.
6. Выдайте patch proposal, но не применяйте его:
   • запись для known-exceptions.yaml;
   • короткую правку к SKILL.md;
   • patch в references/domain-playbook.md, если сбой связан с интерфейсной механикой, selector, URL pattern, paid/no-payment path, локальным языковым ключом или повторяемым browser/API recovery;
   • good/anti example;
   • regression test idea;
   • human approval question.

Границы

Используйте этот skill только для улучшения существующих skills по следам реальных сбоев. Если пользователь просит создать новый skill из общего диалога, используйте skill mining workflow вместо exception review.

Нельзя:

• запускать review автоматически по факту появления файла;
• обходить всю библиотеку в режиме ONE_SKILL;
• трактовать отсутствие или пустоту журнала как доказательство отсутствия ошибок;
• применять patch без отдельного явного запроса пользователя;
• коммитить raw exception logs;
• превращать единичный слабый сбой в обязательное правило;
• переносить приватный контекст в публичные examples;
• ослаблять privacy tests или обходить gate ради быстрого merge.

Опрос После Использования

Опрос задаётся один раз — после выдачи patch proposal, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании pravilo-iz-zhurnala-sboev было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/pravilo-iz-zhurnala-sboev/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/<skill-name>/exception-log.jsonl.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.

Формат Exception Card

Приватный лог хранится вне repo, обычно:

~/.codex/skill-runs/<skill-name>/exception-log.jsonl

Минимальные поля записи:

run_id
skill_name
trigger
intended_action
actual_action
failure_point
false_assumption
user_correction
next_time_rule
severity

Если поле неизвестно, оставьте unknown, а не выдумывайте.

Формат Usage Feedback Card

Карточки опроса после использования лежат рядом:

~/.codex/skill-runs/<skill-name>/usage-feedback.jsonl

Поля записи: ts, skill, liked, improve, outcome, context, redaction_applied, redaction_types, source. Для reviewer главные поля — improve (кандидаты в правки) и liked (что нельзя сломать при правке).

Patch Proposal

Ответ reviewer-а должен быть структурирован так:

## Охват Журналов

## Сводка Сбоев

## Кандидаты В Правила

## Patch Proposal

### known-exceptions.yaml

### SKILL.md

### references/domain-playbook.md

### examples/

### tests/

## Gate

В Gate всегда укажите: human approval, python3 -m pytest, commit с объяснением, какое исключение стало правилом.

Definition Of Done

Review завершён, если:

• явно указан режим ONE_SKILL или LIBRARY_WIDE, а карта охвата различает NO_LOG_FILE, EMPTY, MALFORMED и REVIEWED;
• raw log не перенесён в repo;
• повторяющиеся или дорогие сигналы отделены от слабых единичных;
• patch proposal содержит для сбоев запись в known-exceptions.yaml, для пожеланий из опроса — правку инструкции или example, плюс playbook patch для интерфейсного сбоя и идею example/test;
• явно сказано, что patch не применён;
• следующий похожий сбой можно будет распознать без нового поиска решения.