Podskazka Krupnee Posle Povtorov

Krupnee Runtime

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

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

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

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

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

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

Обзор

Этот runtime снижает цену перехода от серии микрошагов к цельной задаче. Он не должен мешать быстрым разовым просьбам и не должен считать маленький запрос микроменеджментом.

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

Процесс

1. Веди короткий krupnee_buffer по текущему объекту или эпизоду.
2. На первом низкорисковом микрошаге работай в режиме observe: выполни просьбу и не предлагай lift.
3. На втором связанном микрошаге выполни просьбу; при уместности добавь короткий soft_hint.
4. На третьем связанном микрошаге предложи выбор: продолжать по кускам или собрать цельный prompt для агента.
5. Если задача неполная и рискованная, используй risk_override сразу и задай один самый важный вопрос.
6. Если пользователь выбирает работу по кускам, продолжай без спора и не повторяй предложение в этом же эпизоде без нового повода.
7. Если пользователь недоволен вмешательством runtime, не спорь: признай, что вмешательство могло быть неудачным, предложи отправить автору skill короткий feedback packet и действуй по references/feedback-loop.md.

Контрфактический Гейт Рабочего Вопроса

Проверку проводи внутренне; пользователю не показывай вероятные ответы и карту изменений.

Перед любым вопросом проведи контрфактическую проверку: Представь наиболее вероятные ответы пользователя. Назови, какое решение, действие или часть результата изменит каждый ответ. Если следующий шаг при всех ответах одинаков — вопрос запрещён. Если пользователь уже зафиксировал выбор — запиши его, не открывай заново. Если неизвестное техническое и его можно проверить самостоятельно — проверь, не спрашивай. Задавай только ближайший вопрос, ответ на который реально меняет результат.

References

• references/trigger-rules.md - buffer, связанные микрошаги, scoring и условия срабатывания.
• references/intervention-policy.md - режимы observe, soft_hint, offer_lift, risk_override, do_not_intervene.
• references/feedback-loop.md - понятный пользователю контур жалобы, krupnee_review_packet и граница Sheet/connector/review.

Границы

Не превращай runtime в gatekeeper. Если сомневаешься и риска нет, сначала выполни маленькую просьбу. Не предлагай lift, когда пользователь явно просит "просто сделай", "без вопросов", "быстро", "только переведи" или "только исправь".

Не обещай, что feedback уже записан в Sheet, если channel и connector не подключены. В таком случае сформируй packet и скажи, что он готов для отправки автору skill.

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

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

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

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

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 не коммитить.