# Daydzhest Proverennyh Izmeneniy

> «Дайджест обновлений», «утренний журнал изменений», «сократи письмо без потери связей», «что новое важно мне», «источники рядом с новостями» — из проверенных изменений.

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

---


# Дайджест проверенных изменений

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

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

Применяю экспериментальный навык **«Дайджест проверенных изменений»** (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

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

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

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

## Задача

Этот навык превращает **уже допущенные** изменения в короткий журнал или письмо. Он не доказывает новизну, не добывает источники и не отправляет письмо.

Его правило: сначала реальная новость с условиями и источниками рядом, затем отдельное объяснение «стоит ли вам использовать». Сокращение и верстка не имеют права добавлять факт, причинность или уверенность.

## Нужный Вход

Для каждого пункта нужны:

- `claim_id`, статус `PASS`, тип изменения и точные поля «раньше / сейчас»;
- статус доступности `AVAILABLE`, `ANNOUNCED`, `DOCUMENTED` или `UNKNOWN`, условия доступа и прямые источники, подтверждающие именно этот пункт;
- покрытие проверки: `COMPLETE` или `PARTIAL` с коротким объяснением;
- аналитика только отдельными метками: `POSITION` (чья-то позиция), `INFERENCE` (вывод из фактов), `HYPOTHESIS` (непроверенное объяснение);
- личный контекст пользователя — только если он был явно передан для этой рекомендации;
- для каждого самостоятельного «Теперь можно» — статус `AVAILABLE` и связанный безопасный путь попробовать: условия, шаги, критерий успеха и стоп. Если пути нет, нужна честная пометка, что практика не передана.

Пункты со статусом `BLOCK`, `UNKNOWN` или `DISPUTED` не становятся основной новостью. Их можно показать коротким разделом «Неподтверждённые сигналы» без практики, тренда и рекомендации.

## Редакторский Порядок

1. **Сначала факты.** Для каждой новости покажите: что фактически объявлено или изменено; прежнее и нынешнее состояние; ограничения/условия. Не вставляйте сюда оценку «это выгодно», «это тренд» или предполагаемую причину.
2. **Сохраните отношение.** «Раньше → сейчас» допустимо только для одинакового результата и сопоставимых условий. Если новый путь отличается, пишите «появился ещё один способ» и называйте различие.
3. **Источники держите рядом.** После факта поставьте 1–3 короткие ссылки с понятными названиями. Общий список источников в конце не заменяет локальные ссылки.
4. **Теперь можно — на понятном.** Для каждого такого действия укажите: что именно сделать, что раньше мешало, при каком условии это работает, шаги, критерий успеха и стоп. Этот блок допустим только при `AVAILABLE`. Если раньше уже можно было, замените блок на «Было можно, но теперь по умолчанию / шире / иначе».
5. **Затем решение для человека.** Отдельный блок «Стоит ли вам использовать?» содержит пользу, цену, альтернативы, пример и действие. Он может ссылаться на факт, но не может менять его.
6. **Тренд — только вывод.** Тренд строится минимум из двух подтверждённых изменений и помечается как `INFERENCE`. Один анонс не становится тенденцией.

## Компактный Формат Одной Новости

Используйте этот порядок, не превращая его в одиннадцать одинаковых заголовков:

```text
### [короткое название]
Суть новости: [только подтверждённое изменение + условия].
Раньше → сейчас: [сопоставимое различие].
Источники: [оригинал] · [документация/релиз].

Теперь можно: [один практический результат].
Раньше было нельзя: [только если это доказано; почему].
Попробовать: [где, условия, шаги, критерий успеха, риск/остановка] — [проверена / не проверена].

Стоит ли вам использовать?
[польза, цена, альтернативы, пример, ваше следующее действие — только из переданного контекста].
```

Если практики нет, пишите «Практика: безопасный путь не передан»; не маскируйте отсутствие зелёной кнопкой, ссылкой на другой пункт или общим «разобрать новость».

## Ссылки На Практику И Разбор

- Обычная ссылка на источник доказывает факт; практическая ссылка показывает, как попробовать действие. Это разные роли.
- Одна практическая ссылка обслуживает только ту возможность, с которой она явно связана.
- Ссылка на диалог с ИИ — необязательна. Называйте её «Открыть чат с контекстом» только когда подтверждено, что контекст реально передаётся. Иначе честное название — «Открыть чат».
- Не обещайте открыть нативное приложение, Claude Chat или ChatGPT Chat, пока маршрут не проверен на целевом устройстве. Не передавайте в ссылку личный контекст, которого пользователь не попросил передавать.
- Сломанная дополнительная ссылка удаляется отдельно; подтверждённая новость остаётся.

## Однообразный Рендер

Если вход уже записан в JSON, используйте bundled script:

```bash
python3 scripts/render_digest.py approved-items.json --out-dir output
```

Он создаёт `digest.txt` и `digest.html` из одного входа. Скрипт проверяет, что каждая основная новость имеет `PASS`, HTTPS-источник, `AVAILABLE` для каждого «Теперь можно» и связанный путь либо честную отметку. Необязательный `editorial_budget` не даёт молча выбросить пункты: при конфликте объёма рендер останавливается. Он не проверяет смысл цитаты и не выполняет сетевых действий: это должно быть сделано раньше.

Если скрипт отклоняет вход, исправьте данные или покажите конфликт объёма; не обходите проверку свободным переписыванием готового письма.

## Границы

- Не исследуйте источники, не меняйте статусы `PASS` и не отправляйте Gmail-письма.
- Не утверждайте «изменений нет», если покрытие `PARTIAL` или критический источник недоступен.
- Не выдавайте причину, личную пользу или прогноз за факт: сохраняйте метку и источник вывода.
- Не делайте длинный отчёт из-за полного набора полей. Если редакционный лимит конфликтует с обязательным фактом или условием, назовите конфликт, а не обрежьте его молча.

## Definition Of Done

Дайджест готов, когда каждый главный пункт происходит из `PASS`-утверждения, источник стоит рядом, «раньше → сейчас» не искажает условия, а каждое обещанное действие имеет свой путь попробовать или честную пометку об отсутствии.

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

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

```text
Опрос по skill:
1. Что в работе дайджеста проверенных изменений было полезно?
2. Что стоит доработать в процедуре или формате ответа?
Можно ответить коротко или написать "пропустить".
```

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

```bash
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, факт стал сильнее входного доказательства, практика не соответствовала обещанию или HTML и текст разошлись, запишите приватную карточку в `~/.codex/skill-runs/daydzhest-proverennyh-izmeneniy/exception-log.jsonl`.

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