# Pravilo Iz Zhurnala Sboev > «Разбери exception log», «журналы библиотеки», «что добавить в known-exceptions», «навык снова повторил ошибку»: reviewer сбоев — карточки ошибок в patch proposal. - Skill: `kir-kopylov/pravilo-iz-zhurnala-sboev` (Agent Skill, multi-file: 11 files) - Install (CLI): `npx skillmds@latest add kir-kopylov/pravilo-iz-zhurnala-sboev` - Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/pravilo-iz-zhurnala-sboev/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: kir-kopylov (https://skillmd.com/u/kir-kopylov) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/kir-kopylov/pravilo-iz-zhurnala-sboev --- # Skill Exception Reviewer ## Запуск Навыка При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции: Применяю **«Разбор повторяющихся сбоев рабочего рецепта»**: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания. Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык. Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык. Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения. ## Обзор Этот skill превращает сбои skill-а и пользовательский фидбек в проверяемые предложения по улучшению. Он не занимается саморефлексией исполнителя и не переписывает skill автоматически. Его задача - прочитать приватные карточки ошибок и карточки опроса после использования, отделить повторяемые или дорогие сигналы от случайного шума и предложить точечный patch proposal. Базовый цикл: ```text 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, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте. ```text Опрос по skill: 1. Что в этом использовании pravilo-iz-zhurnala-sboev было полезно? 2. Что стоит доработать в skill или его формате? Можно ответить коротко или написать "пропустить". ``` Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/pravilo-iz-zhurnala-sboev/usage-feedback.jsonl` — лучше через bundled script: ```bash 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//exception-log.jsonl`. Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить. ## Формат Exception Card Приватный лог хранится вне repo, обычно: ```text ~/.codex/skill-runs//exception-log.jsonl ``` Минимальные поля записи: ```text run_id skill_name trigger intended_action actual_action failure_point false_assumption user_correction next_time_rule severity ``` Если поле неизвестно, оставьте `unknown`, а не выдумывайте. ## Формат Usage Feedback Card Карточки опроса после использования лежат рядом: ```text ~/.codex/skill-runs//usage-feedback.jsonl ``` Поля записи: `ts`, `skill`, `liked`, `improve`, `outcome`, `context`, `redaction_applied`, `redaction_types`, `source`. Для reviewer главные поля — `improve` (кандидаты в правки) и `liked` (что нельзя сломать при правке). ## Patch Proposal Ответ reviewer-а должен быть структурирован так: ```markdown ## Охват Журналов ## Сводка Сбоев ## Кандидаты В Правила ## 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 не применён; - следующий похожий сбой можно будет распознать без нового поиска решения.