kir-kopylov Проверка изменения возможности
Запуск Навыка
При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:
Применяю экспериментальный навык «Проверка изменения возможности» (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.
Не включайте в строку внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.
Строка запуска не является самостоятельным ответом. В том же сообщении сразу начните проверку: при достаточных данных назовите сравниваемый пользовательский результат и стороны, а при их отсутствии — перечислите минимально недостающие продукт, прежнюю и текущую версию или дату и первичные источники. Не заканчивайте ответ одной строкой запуска.
Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.
Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.
Задача
Этот навык проверяет одну атомарную возможность: может ли определённый пользователь при определённых условиях получить конкретный результат. Он не проверяет «весь релиз» целиком и не пишет дайджест.
Его цель — не дать красивой формулировке стать ложной новостью. Новый экран, команда, модель, название или настройка могут быть новым способом сделать старое; смена значения по умолчанию может быть важной, но не является добавлением возможности.
Когда Применять
- «Это действительно новая возможность или она уже была?»
- «Сравни API/продукт с предыдущей версией».
- «Правда ли, что раньше было нельзя?»
- «Это новый результат для пользователя или только другой путь?»
- «Проверь, можно ли назвать это удалением или ограничением».
Вход И Рамка Сравнения
- Назовите проверяемый результат обычными словами: не «появился параметр», а «пользователь может сделать X и получить Y».
- Зафиксируйте обе стороны: продукт, версия или дата, тариф/роль/регион, интерфейс и существенные условия. Назовите прямого предшественника; если он неизвестен, объясните, почему сравнение всё ещё сопоставимо. Несопоставимые стороны не образуют переход «было → стало».
- Соберите для каждой стороны первичное доказательство: URL, точный фрагмент, класс источника и, если страница меняется, дату или версию. Вторичный разбор может только дополнять первичный. Поисковый сниппет не доказательство.
- Отдельно отметьте доступность: «анонсировано», «документировано», «доступно в проверенных условиях» — это разные состояния. Фиксируйте не только факт доступа, но и его область: кто, где, в каком интерфейсе и на каком тарифе может сделать действие.
Если старая сторона не доказана, не заполняйте её догадкой. Если нынешняя доступность зависит от аккаунта, региона или 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, пока новый источник не разрешит противоречие.
Результат
Верните короткую карточку без рекомендации и без маркетингового усиления:
Проверялось: [один пользовательский результат].
Раньше: [состояние + условия].
Сейчас: [состояние + условия].
Вердикт: [один тип].
Корректная формулировка: [что можно написать].
Доказательства: [ссылка — точный фрагмент] / [ссылка — точный фрагмент].
Класс доказательства: [первичный источник / воспроизводимый тест].
Неизвестно: [что не доказано, если есть].
При UNKNOWN, DISPUTED или UNCHANGED не создавайте заголовок новости, практику, тренд или личную рекомендацию. При DEFAULT_CHANGED не используйте слова «впервые», «теперь можно» и их аналоги.
Границы
- Не исследуйте весь рынок, не собирайте рассылку и не отправляйте письмо.
- Не подменяйте цитату собственным объяснением причины изменения: причина — отдельная позиция источника или гипотеза.
- Не сравнивайте API, Chat и разные тарифы как равные без явно совпадающих условий.
- Не обещайте отсутствие возможности вне проверенного продукта, версии и условий.
Definition Of Done
Проверка готова, когда один результат имеет две сравнимые стороны, прямые доказательства, ровно один вердикт и формулировку, не сильнее этих доказательств. Если этого нет, честный результат — UNKNOWN.
Опрос После Использования
Опрос задаётся один раз — после карточки проверки или честного стопа, не посреди сравнения. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.
Опрос по skill:
1. Что в работе проверки изменения возможности было полезно?
2. Что стоит доработать в процедуре или формате ответа?
Можно ответить коротко или написать "пропустить".
Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/proverka-izmeneniya-vozmozhnosti/usage-feedback.jsonl — лучше через bundled script:
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 не коммитить.