# Proverka Izmeneniya Vozmozhnosti

> «Правда новая возможность?», «сравни с предыдущей версией», «раньше было нельзя», «новый результат или новый способ», «смена default — не новая функция». Вердикт по источникам.

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

---


# Проверка изменения возможности

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

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

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

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

Строка запуска не является самостоятельным ответом. В том же сообщении сразу начните проверку: при достаточных данных назовите сравниваемый пользовательский результат и стороны, а при их отсутствии — перечислите минимально недостающие продукт, прежнюю и текущую версию или дату и первичные источники. Не заканчивайте ответ одной строкой запуска.

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

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

## Задача

Этот навык проверяет **одну атомарную возможность**: может ли определённый пользователь при определённых условиях получить конкретный результат. Он не проверяет «весь релиз» целиком и не пишет дайджест.

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

## Когда Применять

- «Это действительно новая возможность или она уже была?»
- «Сравни API/продукт с предыдущей версией».
- «Правда ли, что раньше было нельзя?»
- «Это новый результат для пользователя или только другой путь?»
- «Проверь, можно ли назвать это удалением или ограничением».

## Вход И Рамка Сравнения

1. Назовите проверяемый результат обычными словами: не «появился параметр», а «пользователь может сделать X и получить Y».
2. Зафиксируйте обе стороны: продукт, версия или дата, тариф/роль/регион, интерфейс и существенные условия. Назовите прямого предшественника; если он неизвестен, объясните, почему сравнение всё ещё сопоставимо. Несопоставимые стороны не образуют переход «было → стало».
3. Соберите для каждой стороны первичное доказательство: URL, точный фрагмент, класс источника и, если страница меняется, дату или версию. Вторичный разбор может только дополнять первичный. Поисковый сниппет не доказательство.
4. Отдельно отметьте доступность: «анонсировано», «документировано», «доступно в проверенных условиях» — это разные состояния. Фиксируйте не только факт доступа, но и его область: кто, где, в каком интерфейсе и на каком тарифе может сделать действие.

Если старая сторона не доказана, не заполняйте её догадкой. Если нынешняя доступность зависит от аккаунта, региона или beta-доступа, это условие остаётся в результате.

## Как Принять Вердикт

Используйте только один из этих типов:

| Вердикт | Когда допустим | Как писать человеку |
|---|---|---|
| `ADDED` | Раньше тот же результат был прямо недоступен, а теперь поддержан | «Теперь можно…» |
| `DEFAULT_CHANGED` | Результат уже был возможен, но изменилось поведение по умолчанию | «Раньше это уже было можно, но теперь происходит по умолчанию» |
| `BEHAVIOR_CHANGED` | Тот же путь даёт иной результат или работает иначе | «Поведение изменилось…» |
| `EXPANDED` | Результат стал доступен большему кругу условий или пользователей | «Теперь доступно шире…» |
| `RESTRICTED` | Прежний результат остаётся, но при более узких условиях | «Теперь ограничено…» |
| `REMOVED` | Прежняя поддержка доказана, а текущая прямо прекращена | «Больше недоступно…» |
| `RENAMED` | Способность та же, изменилось только подтверждённое имя | «Переименовано…» |
| `UNCHANGED` | Обе стороны подтверждают ту же возможность | Не новость |
| `UNKNOWN` | Не хватает сравнимого доказательства | «Не удалось подтвердить изменение» |
| `DISPUTED` | Первичные источники прямо противоречат друг другу | Не публиковать как изменение |

Для фразы «раньше было нельзя» нужно одно из трёх: старый источник прямо говорит «не поддерживается»; старая исчерпывающая схема исключает этот результат; воспроизводимый тест прежней версии показывает отказ. Молчание старой документации ничего из этого не доказывает.

Для `DEFAULT_CHANGED` нужны буквальные старое и новое значения default. Для `BEHAVIOR_CHANGED` нужны два различающихся описания поведения. Для `EXPANDED` и `RESTRICTED` нужны две различающиеся области доступа. Для `RENAMED` нужно доказательство, что старое и новое имя описывают ту же сущность.

## Обязательные Проверки Против Ложной Новизны

- **Новый путь или новый результат.** Если действие раньше было доступно через API, а теперь появилось в чате, сначала сравните доступ, условия и результат. При различии пишите «появился ещё один способ», а не «теперь можно».
- **Default не равен добавлению.** Если прежняя версия уже позволяла выбрать тот же режим, смена автоматического выбора — `DEFAULT_CHANGED`.
- **Анонс не равен доступности.** Не превращайте roadmap, beta-анонс или запись в release notes в утверждение «можно использовать», пока нет доказательства для названных условий.
- **Технический сбой не равен запрету.** Ошибка сети, авторизации, лимита или временного окружения не подтверждает, что способность отсутствует.
- **Переименование не создаёт новую сущность.** Сначала докажите тождество по описанию, условиям и действию; иначе вердикт — `UNKNOWN`.
- **Конфликт первичных источников не сглаживается.** Если первичные источники расходятся, вердикт — `DISPUTED`, пока новый источник не разрешит противоречие.

## Результат

Верните короткую карточку без рекомендации и без маркетингового усиления:

```text
Проверялось: [один пользовательский результат].
Раньше: [состояние + условия].
Сейчас: [состояние + условия].
Вердикт: [один тип].
Корректная формулировка: [что можно написать].
Доказательства: [ссылка — точный фрагмент] / [ссылка — точный фрагмент].
Класс доказательства: [первичный источник / воспроизводимый тест].
Неизвестно: [что не доказано, если есть].
```

При `UNKNOWN`, `DISPUTED` или `UNCHANGED` не создавайте заголовок новости, практику, тренд или личную рекомендацию. При `DEFAULT_CHANGED` не используйте слова «впервые», «теперь можно» и их аналоги.

## Границы

- Не исследуйте весь рынок, не собирайте рассылку и не отправляйте письмо.
- Не подменяйте цитату собственным объяснением причины изменения: причина — отдельная позиция источника или гипотеза.
- Не сравнивайте API, Chat и разные тарифы как равные без явно совпадающих условий.
- Не обещайте отсутствие возможности вне проверенного продукта, версии и условий.

## Definition Of Done

Проверка готова, когда один результат имеет две сравнимые стороны, прямые доказательства, ровно один вердикт и формулировку, не сильнее этих доказательств. Если этого нет, честный результат — `UNKNOWN`.

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

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

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

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/proverka-izmeneniya-vozmozhnosti/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, источник оказался несопоставимым, tool/API/browser упал или вывод был сильнее доказательств, запишите приватную карточку в `~/.codex/skill-runs/proverka-izmeneniya-vozmozhnosti/exception-log.jsonl`.

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