Otbor Navykov Iz Chata

Поиск Навыков В Чате

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

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

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

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

В том же ходе дайте доказанный статус доступной дельты либо UNKNOWN; не завершайте ход строкой запуска или обещанием будущей проверки.

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

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

Обзор

Skill отвечает только на вопрос: какие повторяемые навыки можно обоснованно выделить из доступного материала и какие из них стоит прорабатывать первыми. Совпадение входа не означает совпадение функции: razbor-chata-na-artefakty фиксирует статусы тезисов, otbor-navykov-iz-chata ищет несколько кандидатов, а kontrakt-navyka-do-sborki проектирует контракт уже выбранного кандидата.

Результат — ранжированный список, а не пересказ чата и не пакет файлов нового skill.

Естественные Входы

• «Изучи этот чат и предложи, какие навыки можно создать».
• «Что из этой работы стоит формализовать?»
• «Найди повторяющиеся процессы и расставь кандидатов по приоритету».
• «Какие навыки здесь реальные, а какие выглядят навыками только по названию?»

Процесс

1. До анализа прочитайте соседний known-exceptions.yaml и примените подходящее do_next_time, если симптом совпал.
2. Зафиксируйте доступный материал: текущий чат, экспорт, файлы, журналы или отчёты. Недоступные и сжатые участки назовите границей доказательств; не восстанавливайте их по догадке.
3. Найдите повторяемые сигналы: намерения пользователя, ручную работу, исправления, сбои, восстановление, ограничения, проверки и желаемые форматы результата. Отделите единичный эпизод от повторяемой операции.
4. Классифицируйте каждый кандидат: communication-style, procedural-workflow, local-tooling, domain-knowledge или unsafe-or-not-skill. Стиль ответа не выдавайте за рабочий процесс без отдельного основания.
5. Пропустите кандидата через гейт допуска. Нужны повторяемая боль, стабильный результат, естественный триггер, чёткая граница, проверяемость и преимущество перед обычным разовым промптом. Если этого нет, отклоните кандидата и назовите причину.
6. До рекомендации нового skill найдите в доступном каталоге и списке skills ближайшие существующие назначения. Читайте только релевантные описания и сравнивайте выполняемую операцию, результат, естественные триггеры, границу и проверки — не имя папки и не общий вход. Для каждого возможного изменения сформулируйте точную поведенческую дельту: что должно наблюдаемо появиться или измениться. Предварительно выберите один вердикт: new skill, patch existing skill, shared reference/test или no library change.
7. Сразу после формулировки дельты выполните read-only гейт по references/implementation-state.md. Заявление в чате или отчёте считайте указателем для проверки, а не доказательством. Считайте delta_match на целостном снимке одного слоя; не объединяйте признаки из main, PR, commit и worktree в искусственный EXACT. Для COMMITTED недостаточно найти исторический commit: докажите, что реализующий commit достижим из tip текущей активной ветки доставки и что итоговый снимок этого tip всё ещё содержит дельту. Закрытый незамерженный PR сам по себе не доказывает активную доставку. Если текущий tip или решающий статус доставки недоступен, используйте UNKNOWN; если все решающие текущие слои проверены и дельты в них нет, используйте PROPOSED_ONLY + NONE. Зафиксируйте implementation_state, delta_match, runtime_state и краткое проверяемое основание. Не изменяйте рабочее дерево, ветки, PR или установленный plugin ради этой проверки.
8. Примените состояние к вердикту. MERGED + EXACT означает no library change только когда актуальный main сам содержит всю дельту, и не попадает в рекомендацию V1. Если целый head открытого PR содержит всю дельту, используйте PR_OPEN + EXACT, даже когда часть требований уже есть в main. Только доказанные на актуальном снимке соответствующего слоя состояния WORKTREE_ONLY, COMMITTED и PR_OPEN вынесите в раздел «Уже реализуется» с действием продолжить существующую доставку; исторический или отменённый commit туда не переносите. Если ни один слой не даёт EXACT, разделите совпавшие части по их собственным состояниям доставки; при PARTIAL остаток сформулируйте как новую самостоятельную дельту и повторите для него read-only гейт с шага 7. Совпавшую часть с актуальным статусом WORKTREE_ONLY, COMMITTED или PR_OPEN сразу перенесите в «Уже реализуется»; остаток может попасть в V1 только после собственной классификации PROPOSED_ONLY + NONE. Продолжайте цикл для каждого следующего PARTIAL. Если остаток не стал меньше, не удалено ни одного наблюдаемого требования или прежний остаток повторился, остановите цикл с implementation_state: UNKNOWN и delta_match: UNKNOWN; в V1 его не включайте.
9. Для прошедшего кандидата запишите только имя папки, тип, назначение одной фразой, естественные триггеры, повторяемое свидетельство, границу, признаки проверяемости, вердикт, три поля состояния, основание и остаточную дельту. Возможные scripts, references или assets отмечайте лишь как фактор приоритета; не проектируйте полный workflow.
10. Оцените по references/scoring.md только ещё не реализованный кандидат или его остаточную дельту. Обычно покажите 3–8 прошедших или отклонённых кандидатов и рекомендуйте не более 1–3 для следующего этапа. Пороговые значения модели не меняйте из-за стадии доставки.
11. Соберите результат по references/output-template.md и остановитесь. После выбора одного кандидата передайте его в kontrakt-navyka-do-sborki; не дописывайте его полный контракт внутри этого skill.

Роутинг Соседних Задач

• Если пользователь уже выбрал один skill и просит входы, алгоритм, анти-правила и проверки, используйте kontrakt-navyka-do-sborki.
• Если критично доказательно отделить принятые, отвергнутые, открытые и оставшиеся без реакции тезисы, предложите razbor-chata-na-artefakty как отдельный предварительный этап. Не запускайте его по умолчанию.
• Если пользователь просит создать папку skill, examples, registry, тесты или PR, используйте dobavlenie-navyka-v-biblioteku после выбора и проектирования кандидата.
• Если нужен только пересказ, решения встречи или список задач, не используйте этот skill.

Вопросы Пользователю

Спрашивайте только тогда, когда неизвестное меняет состав или порядок кандидатов. Не спрашивайте про место установки, структуру полного контракта или детали реализации во время поиска. Технически проверяемые сведения сначала ищите в доступных файлах и текущем чате.

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

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

После каждого ответа заново определите, нужен ли ещё один вопрос. Не выдавайте заранее подготовленный пакет вопросов.

Границы

• Не создавайте, не устанавливайте и не редактируйте другие skills.
• Не превращайте одну удачную идею, стилевую привычку или разовую просьбу в отдельный skill без доказанной повторяемости.
• Не переносите в публичный результат приватные сообщения, личные пути, имена, контакты, токены и сырые журналы.
• Не подменяйте нехватку материала длинным списком правдоподобных кандидатов.
• Не зашивайте в обязательное поведение результаты одного исторического чата или предметной области.
• Не превращайте разные внутренние стратегии одного workflow с теми же входом, результатом и точкой остановки в отдельные skills. Это патч, reference или tests существующего skill, а не новые строки каталога.
• Не называйте предложение реализованным по словам из чата, наличию исторического commit или закрытого незамерженного PR и не называйте изменение новым без проверки решающих доступных слоёв.
• Не смешивайте состояние repo и runtime: MERGED не доказывает установку, а INSTALLED не доказывает активность текущей сессии или наличие изменения в актуальном main.

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

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

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

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

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

Критерий Готовности

• Названы доступные источники и границы доказательств.
• Каждый рекомендованный кандидат опирается на повторяемое свидетельство и имеет границу применения.
• Стилевые предпочтения отделены от рабочих процессов.
• Ложные, разовые и небезопасные кандидаты явно отклонены.
• Для каждого возможного изменения указаны implementation_state, delta_match, runtime_state и проверяемое основание.
• Уже реализованная часть не рекомендована повторно; при PARTIAL каждый остаток заново сформулирован, независимо классифицирован и только после PROPOSED_ONLY + NONE допущен к рейтингу.
• Цикл PARTIAL завершился доказанным состоянием либо безопасным UNKNOWN, а не повторением той же дельты.
• Рекомендовано не более трёх кандидатов.
• Ни один выбранный кандидат не превращён здесь в полный контракт или пакет файлов.