kir-kopylov Skill Methodologist
Запуск Навыка
При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:
Применяю «Проектирование навыка из рабочего процесса»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.
Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.
Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.
Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.
Обзор
Этот skill помогает превратить повторяемую работу в контракт будущего skill. Методология предоставлена Дмитрием Гвоздецким и адаптирована для командного repo codex-team-skills; текущий maintainer и авторство указаны в skill.yaml.
Задача не в том, чтобы сохранить весь чат или сразу создать Pull Request. Задача - извлечь повторяемый рабочий механизм: входы, результат, правила, анти-правила, алгоритм, проверки, формат ответа и решение, нужны ли scripts, references или assets.
Расширенная методология лежит в references/skill-methodology.md. Читайте ее, когда вход большой, спорный или когда нужно объяснить, почему отдельный skill нужен или не нужен.
Быстрый Роутинг
- пользователь просит "сделай из этого контракт skill", "спроектируй контракт skill", "из этого чата сделать skill", "нужен ли тут skill" -> используйте этот skill;
- пользователь просит извлечь уроки из длинного провального чата, инцидента или repair-цикла -> используйте режим incident-to-library decision:
new skill / patch existing skill / shared reference / script / no library change; - пользователь просит создать файлы в repo, добавить examples, catalog, tests или PR -> передайте задачу в
dobavlenie-navyka-v-biblioteku; - пользователь просит разобрать идею без намерения создать повторяемый skill -> используйте
razbor-svoey-syroy-idei; - задача разовая, творческая или меняется каждый раз -> не проектируйте skill, предложите обычный ответ или простой prompt.
Процесс
Если исходный материал содержит исследование, смену курса или прямые поправки пользователя, сначала составьте внутреннюю карту требований:
действует— последнее явно подтверждённое требование;отменено позднейшим уточнением— прежняя формулировка, которую пользователь сузил или отверг;исследовательская идея— обсуждавшийся вариант, который не стал частью требуемого поведения.
Позднее прямое ограничение пользователя имеет приоритет над ранней исследовательской веткой. В контракт переносите только то, что действует. Отменённое нельзя возвращать как компромисс, обязательный режим или новый уточняющий вопрос. Показывайте эту карту пользователю только тогда, когда без неё невозможно объяснить существенный конфликт требований.
- Определите повторяемую задачу. Если повторяемости нет, прямо скажите, что отдельный skill не нужен.
- Проверьте признаки пригодности: похожие входы, стабильный результат, фиксированные правила, прошлые ошибки, нужные проверки, артефакты или детерминированные шаги.
- Сформулируйте назначение одной фразой: кому skill помогает, что делает, из каких входов, по каким правилам и какой результат выдает.
- Выделите входы: обязательные, опциональные, допустимые форматы, что делать при неполных данных.
- Опишите результат: основной артефакт, обязательные секции/колонки, дополнительные материалы и формат ответа.
- Извлеките правила: предметные правила, правила качества и анти-правила, которые предотвращают повтор прошлых ошибок.
- Соберите алгоритм: проверить входы -> нормализовать данные -> применить правила -> проанализировать или посчитать -> проверить результат -> собрать результат -> отметить неопределенность -> дать короткий вывод.
- Решите, нужны ли scripts, references или assets. Script нужен, если ошибка парсинга, расчета или сверки существенно повредит результат.
- Опишите проверки: какие условия должны быть подтверждены перед финальным ответом и что делать при провале проверки.
- Для инцидента или длинного провального чата сначала выберите форму переноса урока:
new skill,patch existing skill,shared reference,scriptилиno library change. Отдельный skill выбирайте только если есть стабильная повторяемая задача; completion gate, anti-repeat ledger и failure-patterns чаще являются патчем или reference. - Верните контракт skill или incident-to-library verdict, а не patch для repo.
Формат Ответа
По умолчанию верните компактный контракт skill:
Название skill:
...
Назначение одной фразой:
...
Когда использовать:
...
Входы:
- Обязательные:
- Опциональные:
- Если не хватает:
Результат:
- Основной:
- Обязательные блоки:
- Дополнительные блоки:
Правила:
1.
2.
3.
Анти-правила:
1.
2.
3.
Алгоритм:
1.
2.
3.
Проверки:
1.
2.
3.
Нужны ли scripts/references/assets:
...
Incident-to-library decision:
- new skill / patch existing skill / shared reference / script / no library change
- почему:
- что не переносить в repo:
Когда не использовать:
...
Если пользователь просит сразу оформить skill для repo, после контракта явно укажите, что следующий шаг - dobavlenie-navyka-v-biblioteku.
Границы
Не создавайте новый skill из разовой просьбы, общей идеи, художественной задачи или ситуации без стабильного повторяемого результата.
Не копируйте сырой чат как инструкцию. Извлекайте только повторяемые правила, ограничения, проверки и формат результата.
Не объединяйте раннюю исследовательскую идею с более поздним прямым ограничением пользователя. Последняя явная формулировка вида «только X» исключает отвергнутые режимы из назначения, алгоритма, примеров и проверок.
Не превращайте каждый инцидент в новый skill. Если урок является стопором, проверкой, форматом журнала или списком типовых провалов, отдайте предпочтение патчу существующего skill, shared reference или script. Для repair-инцидентов используйте как пример reference ../sloy-obryva-seti-windows/references/repair-state-bundle.md.
Не придумывайте отсутствующие предметные правила. Если правило критично, но не задано, отметьте его как вопрос или [requires recheck].
Не подменяйте процесс repo. Этот skill проектирует контракт; dobavlenie-navyka-v-biblioteku создает структуру repo, examples, catalog, tests и Pull Request.
Опрос После Использования
Опрос задаётся один раз — после выдачи спроектированного контракта skill, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.
Опрос по skill:
1. Что в этом использовании kontrakt-navyka-do-sborki было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".
Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/kontrakt-navyka-do-sborki/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 без нового поиска. Если там exceptions: [], продолжайте обычный процесс.
Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/<skill-name>/exception-log.jsonl.
Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.
Definition Of Done
Пользователь получает понятный контракт будущего skill и может решить: отвечать обычным prompt, собирать материалы дальше или передать контракт в dobavlenie-navyka-v-biblioteku для упаковки в командный repo.