# Otsenka Podskazki Krupnee

> «Правильно ли сработал krupnee_lift», «разбери trace, диалог, feedback rows, GitHub Issue», «eval cases, telemetry krupnee», «lift предложен рано». Offline, не runtime.

- Skill: `kir-kopylov/otsenka-podskazki-krupnee` (Agent Skill, multi-file: 17 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/otsenka-podskazki-krupnee`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/otsenka-podskazki-krupnee/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/otsenka-podskazki-krupnee

---


# Krupnee Review

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

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

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

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

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

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

## Обзор

Этот skill нужен не для вмешательства в живую работу пользователя, а для offline/manual аудита применения `krupnee_lift`. Он может быть длинным, аналитическим и проверочным, потому что не должен попадать в короткий runtime.

Review не является автоматическим наблюдателем. Он работает только на материале, который явно передали в запросе: фрагмент диалога, sanitized trace, dissatisfaction feedback packet, строка из `Team Codex Skill Feedback Inbox`, GitHub Issue body или eval fixture.

## Процесс

1. Проверь `trace_source`: откуда взят материал для review.
2. Если материала нет, запроси один минимальный источник: фрагмент диалога, trace, feedback packet или eval case.
3. Определи, был ли один общий объект, цель, артефакт или рабочий эпизод.
4. Отдели единичную просьбу от серии связанных микрошагов.
5. Восстанови `krupnee_buffer` по короткому окну сообщений.
6. Проверь scoring и ожидаемый режим вмешательства.
7. Сравни ожидаемое поведение с фактическим ответом агента.
8. Если материал пришёл из feedback inbox, проверь `dissatisfaction_signal`, `expected_behavior`, `actual_behavior`, `suspected_issue` и `review_packet`.
9. Выдай review output: verdict, причину, telemetry, optional eval case, optional patch proposal и указание, нужен ли changelog.

## References

- `references/review-intake-contract.md` - trace sources, review triggers, access policy и output contract.
- `references/review-prompt.md` - полный audit prompt и failure labels.
- `references/telemetry-schema.md` - минимальный trace применения.
- `references/eval-cases.md` - eval-набор для проверки поведения.
- `references/version-history.md` - история версии 0.2.0.

## Границы

Не используй review вместо runtime. Если пользователь просит просто выполнить маленькую задачу, нужен `podskazka-krupnee-posle-povtorov` или обычное выполнение, а не аналитический аудит.

Не делай вид, что review может сам посмотреть чужие диалоги, командную telemetry или историю срабатываний. Без явно переданного материала review должен остановиться на запросе источника. Не добавляй в review raw-приватный контекст; достаточно коротких labels и обезличенных фрагментов.

Не меняй runtime, examples или changelog автоматически без подтверждения maintainer. Review может предложить patch proposal, но repo-правка - отдельное действие.

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

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

```text
Опрос по skill:
1. Что в этом использовании otsenka-podskazki-krupnee было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".
```

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/otsenka-podskazki-krupnee/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/<skill-name>/exception-log.jsonl`.

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