Dobavlenie Navyka V Biblioteku

Add Team Skill

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

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

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

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

Для пакетной пробы в том же ходе вычислите охват и запустите его строки; не завершайте ход строкой запуска или обещанием будущей проверки.

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

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

Обзор

Этот skill ведёт автора через создание или доработку командного skill внутри codex-team-skills.

Главная задача: получить не просто папку с SKILL.md, а воспроизводимый командный skill, который соответствует структуре repo, понятен коллегам, проходит локальные тесты и готов к Pull Request.

Работайте по правилам текущего repo, а не по памяти. Перед изменениями читайте релевантные файлы: README.md, catalog.md, CONTRIBUTING.md, language-policy.md, scripts/new_skill.py, tests/ и похожие skills в plugins/team-skills/skills/.

Быстрый Роутер

• пользователь просит "добавь новый skill" -> создать draft через scripts/new_skill.py, затем заполнить до нужного статуса;
• пользователь дал workflow из диалога -> извлечь повторяемую задачу, триггеры, границы, examples и оформить skill;
• пользователь дал чужой SKILL.md, draft или методику -> сначала найти похожие skills, решить "интегрировать или создать новый", затем сохранить авторство через authors и source_asset;
• пользователь переносит уже работающий личный skill в командную библиотеку -> выбрать канонический контейнер и закрыть судьбу личного предшественника по правилам ниже;
• пользователь просит "team-ready" -> требовать owner, catalog row, 3 good examples, 2 anti-examples, отсутствие шаблонных заглушек, зелёный pytest и прохождение общего Claude sync gate;
• пользователь просит "проверь перед PR" -> провести review структуры, registry, examples, catalog, privacy и тестов;
• пользователь просит проверить первые ответы изменённых skills -> собрать пакетный охват, независимо проверить каждый первый ответ и не открывать commit/PR до актуального PASS во всех строках;
• пользователь просит "почини CI" -> сначала прочитать ошибку тестов/CI, затем править минимально.

Перед Началом

1. Найдите корень repo codex-team-skills.
2. Проверьте рабочее дерево через git status --short --branch.
3. Не перезаписывайте чужие изменения и не удаляйте существующие файлы без явной причины.
4. Push и Pull Request — обычное завершение этого workflow, а не отдельный шаг, который ждёт отдельного запроса на публикацию. Перед push всегда покажите краткий scope изменений.

Канонический Контейнер И Закрытие Переноса

До любой записи выберите один канонический контейнер для итогового skill. Если skill с самого начала предназначен команде, создавайте draft сразу в repo и проверяйте его через поддерживаемый изолированный CODEX_HOME; не устанавливайте промежуточную активную личную копию. Если в командную библиотеку переносится уже работающий личный skill, считайте его личным предшественником: проверьте список доступных skills и доступные пользовательские корни на совпадение имени и назначения. Личные абсолютные пути допустимы только как приватное рабочее evidence и не коммитятся.

Разделяйте готовность изменений в repo и завершение переноса в runtime. Repo-пакет может быть готов, пока перенос ещё ожидает публикации или установки. Пишите перенос завершён только когда командная версия обнаруживается в новой сессии на целевой поверхности, сохраняет ожидаемое поведение на репрезентативной пробе, а каждый найденный предшественник получил одно решение:

• то же или полностью заменённое поведение — после явного разрешения пользователя передайте безопасный вывод личной копии в snos-podsistemy-iz-koda;
• другое нужное поведение — не удаляйте копию; согласуйте отдельное имя или явно сохраните оба назначения;
• различие не доказано — сообщите о коллизии и оставьте статус перенос не завершён.

Не удаляйте и не перезаписывайте личный skill автоматически по одному совпадению имени. Не создавайте для этого постоянный scanner, updater, doctor, отдельный реестр происхождения или сборщик кэша: проверка предшественника является началом и завершением текущего переноса.

Discovery Gate

Перед созданием нового skill или крупной правкой существующего skill проверьте, что задача достаточно определена для repo-grade реализации.

Минимальный brief:

• назначение skill и повторяемая боль;
• естественные триггеры;
• кто будет использовать skill;
• обязательные и опциональные входы;
• ожидаемый результат;
• 2-3 реалистичных примера;
• workflow, tools, connectors, references, scripts или assets;
• ограничения, edge cases и failure modes;
• tone, language и формат ответа;
• validation criteria;
• ownership: кто maintainer, кто автор исходного вклада, нужен ли source_asset.

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

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

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

Если brief уже ясен из файлов, диалога или repo-контекста, не анкетируйте пользователя. Зафиксируйте недостающие предположения в skill.yaml, examples или финальном summary и продолжайте.

Если следующий шаг зависит от отсутствующих данных, спросите только один ближайший blocker question. После ответа пересоберите brief и решите, нужен ли ещё один вопрос.

Если пользователь явно просит rough draft при неполных данных, оставьте статус draft, укажите assumptions и не добавляйте catalog row как team-ready.

Для подробного checklist используйте references/discovery-gate.md.

Выбор Ближайшего Вопроса

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

1. Какую повторяемую задачу закрывает skill?
2. Какими обычными фразами коллеги будут его запускать?
3. Когда этот skill нельзя применять?

После ответа не переходите автоматически к следующему пункту списка: заново проверьте, меняет ли оставшееся неизвестное реализацию. Если пользователь не знает точного ответа, предложите разумный draft и отметьте спорное место в examples или skill.yaml.

Domain/Interface Check

Перед созданием или переводом skill в team-ready проверьте, является ли workflow domain/interface-heavy.

Считайте skill domain/interface-heavy, если его ценность зависит от внешнего сайта, кабинета, маркетплейса, локального рынка, модерации, paid screens, browser/API recovery, selectors, URL patterns, field limits или локальных поисковых слов.

Для такого skill создайте или обновите references/domain-playbook.md. Всегда зафиксируйте два списка:

• Что нельзя потерять: routes, selectors, поля, статусы, лимиты, recovery, no-payment paths, локальные поисковые слова;
• Что надо обезличить: адреса, квартиры, телефоны, email, имена, реальные IDs, аккаунтные ники, личные пути, raw logs, screenshots/private media.

Если workflow не зависит от конкретного интерфейса или рынка, не создавайте playbook ради формы.

Создание Нового Skill

Для нового skill используйте локальный генератор:

python3 scripts/new_skill.py <skill-name> --owner @github-login --summary "Коротко: что делает skill"

Правила имени (полная версия — раздел «Имя Skill» в CONTRIBUTING.md):

• имя латиницей из русских слов, чтобы по одному названию было ясно, что делает навык и в какой момент он нужен. Английские термины не используются: otsev-replik-do-vstrechi, а не remote-authenticity-probe;
• от двух до четырёх слов между дефисами, включая предлоги;
• первое слово — действие или результат; дальше объект и маркер границы (момент, канал или сценарий), отсекающий ближайший соседний skill;
• транслитерация как в принятых именах библиотеки (ч → ch, ш → sh, й → y, ы → y, я → ya, ий → iy, ц → ts); сокращения, нечитаемые в латинице, раскрываются словом;
• только lowercase, цифры и дефисы; имя должно совпадать с папкой;
• имя не совпадает с существующими skills и не путается с соседним по функции;
• не используйте слишком общие имена вроде helper, workflow, assistant.

Если пользователь принёс имя, нарушающее эти правила, предложите два-три варианта по правилам и зафиксируйте выбор до генерации папки; существующие skills не переименовывайте без отдельного решения владельца библиотеки; разовое переименование сентября 2026 описано в docs/skill-renames-2026-09.md.

Если skill уже существует, не запускайте генератор повторно. Откройте существующую папку и дорабатывайте её.

Что Заполнить

Обязательный состав skill:

• SKILL.md — инструкция для Codex;
• skill.yaml — registry-карточка для команды;
• known-exceptions.yaml — список известных сбоев и готовых действий на следующий раз;
• references/domain-playbook.md — только для domain/interface-heavy skills, где нужно сохранить очищенную механику сервиса;
• examples/ — проверяемые хорошие примеры и анти-примеры;
• строка в catalog.md, если статус team-ready или experimental;
• agents/openai.yaml только если нужен UI-чип или полезный default prompt.

SKILL.md

Frontmatter должен содержать минимум:

---
name: skill-name
description: ...
---

Описание — главный механизм срабатывания. Включите туда:

• что делает skill;
• когда использовать;
• естественные фразы-триггеры;
• важные ограничения, если они помогают роутингу.

В body держите только полезную процедуру:

• секция ## Запуск Навыка — первый H2, канонический текст из CONTRIBUTING: немедленный запуск для team-ready и experimental, явный вызов для draft, пометка и owner для experimental и draft;
• обзор;
• роутинг запросов;
• процесс выполнения;
• границы и safety;
• definition of done.

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

skill.yaml

Для team-ready заполните:

owner: "@github-login"
status: "team-ready"
summary: "Короткое практическое описание."
use_cases:
  - "Повторяемый сценарий."
do_not_use_for:
  - "Граница применения."
natural_triggers:
  - "естественная фраза"
example_files:
  - "examples/good-01.md"
  - "examples/good-02.md"
  - "examples/good-03.md"
  - "examples/anti-01.md"
  - "examples/anti-02.md"
last_reviewed: "YYYY-MM-DD"

Если был внешний вклад, добавьте:

authors:
  - "Имя автора исходной методики, если отличается от maintainer-а"
source_asset: "Короткое описание исходного вклада без приватных путей и raw-контекста."

owner — подтвержденный GitHub-style maintainer, отвечающий за поддержку и review. Не придумывайте handle коллеги. Если исходный workflow, методику или draft дал другой человек, сохраните его имя в authors, а источник вклада опишите в source_asset.

Статусы:

• draft — можно merge как черновик после базовой структуры;
• experimental — рабочий рецепт без гарантий: нужен owner, catalog entry, отсутствие шаблонных заглушек и гейт с пометкой «экспериментальный» и owner-ом; полный набор examples ещё не обязателен;
• team-ready — нужен owner, catalog entry, 3 good examples, 2 anti-examples, отсутствие шаблонных заглушек, зелёные тесты и успешный Claude folder-sync через scripts/pull-skills.sh; при повышении из experimental уберите пометку из гейта;
• internal-only — нужен внутренний контекст или особые ограничения;
• deprecated — нужны replacement или deprecation_reason.

Examples

Для team-ready нужно минимум 5 examples:

• 3 good examples;
• 2 anti-examples.

Каждый example должен содержать:

## Вход

## Ожидаемое Поведение

## Нельзя

Хороший example доказывает применимость skill на реалистичном запросе. Anti-example показывает границу, где skill должен отказаться, спросить уточнение или выбрать другой workflow.

Если skill задаёт структурированный результат, зафиксируйте одну каноническую схему в SKILL.md или его шаблоне и используйте её во всех examples и tests. Regression test должен проверить по этой схеме каждый структурированный example, а на отдельной испорченной копии с изменённым полем, типом или формой подтвердить, что проверка падает. Для skill с обычным текстовым ответом искусственную схему не вводите.

Known Exceptions

Для нового или изменяемого skill добавьте рядом с SKILL.md файл known-exceptions.yaml.

Минимальный пустой файл:

exceptions: []

Если у skill уже есть известные сбои, каждая запись должна содержать:

exceptions:
  - symptom: "Что наблюдает Codex или пользователь."
    root_cause: "Почему skill ошибается."
    do_next_time: "Что сделать сразу в следующий раз."
    source_example: "Какой example, test или sanitized packet подтверждает правило."

Перед выполнением skill должен читать этот файл как список известных случаев. Сырые exception-log.jsonl хранятся только приватно вне repo, например в ~/.codex/skill-runs/<skill-name>/.

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

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

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

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/dobavlenie-navyka-v-biblioteku/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 не коммитить.

Catalog

Если skill переводится в team-ready, добавьте строку в catalog.md.

Строка должна помогать человеку:

• найти задачу;
• понять имя skill;
• увидеть статус;
• скопировать первую фразу для Codex;
• понять, когда использовать и когда не использовать.

Если skill остаётся draft, не обещайте его команде как готовый.

Проба Первого Ответа

Для нового или существенно изменённого skill до commit выполните независимую пробу поведения:

1. Возьмите дословную естественную фразу запуска из запроса пользователя или подтверждённого примера.
2. До запуска зафиксируйте от одного до трёх наблюдаемых признаков правильного первого ответа и запрещённое поведение. Это критерии оценки, а не подсказка проверяемому агенту.
3. Откройте свежий контекст. Передайте проверяемому агенту только целевой skill и фразу запуска; не показывайте ему критерии, предполагаемый ответ, найденную ошибку или предлагаемое исправление.
4. Сохраните и оцените только первый ответ:
   • BEHAVIOR_PROBE_PASS — наблюдаемые признаки выполнены, запрещённого поведения нет;
   • BEHAVIOR_PROBE_FAIL — ответ нарушил хотя бы один заранее заданный критерий; исправьте skill и повторите пробу в новом контексте;
   • BEHAVIOR_PROBE_BLOCKED — независимый свежий запуск недоступен или его происхождение нельзя подтвердить.
5. При BEHAVIOR_PROBE_FAIL или BEHAVIOR_PROBE_BLOCKED не делайте commit, push или Pull Request с изменениями проверяемого skill. Структурный pytest не исполняет модель и не заменяет наблюдаемый первый ответ.

Результат относится только к выполненной пробе и не гарантирует все будущие ответы. Сырой пользовательский запрос и сырой вывод модели не коммитите; сохраняйте в repo только обезличенный example, критерий или regression test.

Пакетная Проба Изменённых Skills

Если PR добавляет или существенно меняет несколько skills, выполните описанную выше одиночную пробу для каждого из них как один пакет. В обычный охват входят все новые или существенно изменённые skills; полную библиотеку проверяйте только при общей поведенческой миграции или по прямой просьбе.

Изменение known-exceptions.yaml считается поведенческим изменением самого skill, даже если остальные его файлы не менялись: этот источник читается до работы и может изменить первый ответ через подходящий do_next_time.

Каждый skill запускайте в отдельном свежем контексте. После FAIL или BLOCKED продолжайте остальные строки, чтобы собрать все дефекты за проход, но не делайте commit, push или PR, пока каждая строка охвата не получила актуальный BEHAVIOR_PROBE_PASS.

До запуска каждой строки получите полный diff её target и общих launch-paths относительно базы. Стройте его из fail-closed объединения committed, staged и unstaged tracked-файлов с untracked-файлами, сравнивая слои независимо, а не только из одного git diff или staging. До diff разрешите checked_base как полный exact commit OID через option-safe проверку. Каждый изменённый путь должен либо войти точным путём в scope_reason, либо получить отдельное доказательство отсутствия влияния; неучтённый или неизвестный путь даёт BLOCKED. Изменённые skill.yaml, agents/openai.yaml, общий launch-contract и используемый reference/script/asset исключать нельзя.

Полностью разложите глобальный снимок: каждый путь назначьте одной или нескольким строкам либо включите в batch_excluded_source с отдельным доказательством. Пропуск, пересечение или неизвестное назначение даёт BLOCKED. Приватный batch_scope_fingerprint должен связывать базу, режим, список строк, содержимое каждого пути и его назначение либо доказательство; перед финальным гейтом он пересчитывается заново.

Для кандидата commit/PR выполните окончательный точечный staging до живых проб и свяжите пакет с head_oid, заранее выбранным CREATE/AMEND, точным ожидаемым списком parents, index_tree_oid = tested_tree, отсутствием unmerged и entries HEAD/index/worktree каждого пути. Любое последующее изменение index, HEAD или worktree аннулирует PASS. После commit обновить эту привязку без новой пробы можно только по exact receipt: фактические parents равны заранее сохранённым для выбранного перехода, commit tree равен tested_tree, index равен тому же tree, postcommit HEAD/index entries равны precommit index entries и полный status чист.

Затем выведите полный required_source из точных путей причины включения и маршрута запроса. PASS допустим только после доказательства, что каждый обязательный путь фактически вошёл в loaded_source. known-exceptions.yaml обязателен для каждой строки независимо от того, изменялся ли он; используемый reference/script/asset и каждый путь из причины включения также обязательны. Неполное покрытие даёт BEHAVIOR_PROBE_BLOCKED.

Привяжите строку приватным source_scope_fingerprint к проекции HEAD/index/worktree и содержимому всех изменённых путей, включая доказанно исключённые, их Git modes, доказательствам и маркерам удаления. Изменение index bytes, executable mode, excluded-файла или основания его исключения после пробы аннулирует PASS, даже если набор имён и bytes не изменились. Symlink нельзя загружать или передавать target-агенту. Точный producer, каноническая запись и правила свежести находятся в reference.

Пробу, способную менять Git, файлы или внешнюю систему, запускайте только в одноразовой изолированной копии; невозможность изоляции означает BLOCKED. Если в охват входит сам dobavlenie-navyka-v-biblioteku, его строку запускайте на ограниченном двухуровневом fixture по правилам reference; присвойте внешней строке обычный статус и продолжите внешний пакет.

Сырые фразы, критерии и ответы храните только приватно. Состав строки, обезличенная привязка PASS к проверенной базе и точному состоянию target, классы сбоев, правила устаревания и допустимый публичный summary описаны в references/behavior-probe-batch.md.

Проверки

Preflight Среды

До запуска тестов установите, чем именно они будут выполнены:

1. Прочитайте pyproject.toml и проверьте test extras и addopts; не предполагайте, что системный Python уже содержит pytest-cov и остальные зависимости.
2. Если в repo есть рабочая .venv, используйте её Python. Иначе создайте отдельную временную venv и установите в неё .[test]; не доустанавливайте пакеты в глобальный Python пользователя.
3. Перед local native marketplace smoke отдельно выполните codex --version. ENOENT, сломанный wrapper или отсутствие нужной версии означают LOCAL_NATIVE_SMOKE_BLOCKED, а не провал самого skill и не доказательство будущего результата CI.
4. Если smoke или тест создаёт clone из локального checkout, используйте git clone --no-hardlinks. Не полагайтесь на hardlinks между sandbox, volume или временными каталогами.

Локальная блокировка и CI — разные свидетельства. Зелёный CI можно утверждать только по фактическому результату текущего PR; недоступный локальный smoke нельзя выдавать ни за зелёный, ни за красный CI.

Перед завершением всегда запустите:

python3 -m pytest

Если тесты падают:

1. прочитайте конкретный тест и сообщение ошибки;
2. исправьте причину, а не обходите проверку;
3. повторите python3 -m pytest;
4. в финальном ответе назовите результат.

Типовые причины падений:

• шаблонная заглушка осталась в team-ready;
• skill не добавлен в catalog.md;
• example указан в skill.yaml, но файла нет;
• example не содержит нужные секции;
• текст пользовательских файлов не на русском;
• есть токены, приватные пути, pasteboard/download paths или raw PII.
• Codex marketplace smoke не видит обновлённый plugin или Claude sync smoke не копирует repo-managed skills через scripts/pull-skills.sh.
• domain/interface-heavy skill потерял selectors, URL patterns, статусы, лимиты или recovery вместо очищения частных значений.

Pull Request

Push и Pull Request — это обычное завершение workflow добавления или обновления skill, а не действие, которое требует отдельного разрешения пользователя каждый раз. Как только commit готов и локальные проверки прошли:

1. покажите краткий scope изменений;
2. проверьте git status;
3. сделайте commit с осмысленным сообщением;
4. push в branch (не в main);
5. подготовьте title и body PR в отдельных временных файлах, соберите временный event JSON и отдельным вызовом выполните python3 scripts/check_pr_governance.py metadata --event-path <file>;
6. только после наблюдаемого кода возврата 0 отдельным вызовом выполните gh pr create --body-file <file> или gh pr edit --body-file <file>. Проверку и внешнее изменение нельзя объединять в последовательный shell-блок: падение проверки должно физически исключать публикацию;
7. прочитайте сохранённые title и body обратно через gh pr view и сравните с проверенными файлами;
8. подтвердите опубликованную голову ветки через git ls-remote --heads origin <branch> или gh pr view --json headRefName,headRefOid; локальный git fetch, настроенный только на main, не доказывает состояние PR-ветки;
9. выполните полный gh pr checks <number> без tail, выборочного grep или другого усечения и убедитесь, что CI запустился или уже зелёный;
10. после открытия и после каждого обновления PR прочитайте conversation comments, reviews и unresolved review threads, включая отзыв chatgpt-codex-connector;
11. обработайте каждый комментарий бота без дополнительного запроса пользователя:

• если согласны — исправьте, прогоните проверки, запушьте фикс, ответьте в треде со ссылкой на commit и resolve тред;
• если не согласны — ответьте в треде по-русски с проверяемым обоснованием;
• спрашивайте пользователя только при конфликте с его целью, необратимом действии или существенном расширении scope;

12. после последнего push повторно проверьте CI и review-треды. Не называйте PR готовым, пока остаётся необработанный или обоснованный actionable comment.

Передавайте многострочный PR-текст и ответы через файл или stdin. Не вставляйте их в shell-строку с обратными кавычками, $() или секретами.

Если title или body изменены после выполнения PR-governance job, старый зелёный job не подтверждает новые метаданные. Сначала снова проверьте текущие метаданные локальным governance script. Для утверждения именно о CI нужен новый pull_request event с уже исправленными метаданными; простой rerun старого job может использовать прежний event payload. Не создавайте бессодержательный commit только ради этого — честно разделите локальную проверку текущего текста и устаревший CI-сигнал до следующего содержательного push или иного штатного нового события.

PR должен отвечать на четыре вопроса:

• какую боль решает skill;
• для кого он нужен;
• когда его нельзя применять;
• какие examples доказывают пользу.

Definition Of Done

Skill готов, если:

• folder name, SKILL.md frontmatter name и registry согласованы;
• имя папки латиницей из русских слов, от двух до четырёх, с действием, объектом и маркером границы; по нему без открытия SKILL.md понятно, что делает навык и в какой момент он нужен;
• первый H2 в SKILL.md — ## Запуск Навыка с каноническим текстом: немедленный запуск для team-ready и experimental, явный вызов для draft, пометка и owner для experimental и draft;
• description содержит естественные триггеры;
• skill.yaml заполнен без пустых полей;
• каждый skill имеет known-exceptions.yaml;
• domain/interface-heavy skill имеет references/domain-playbook.md или явное объяснение, почему playbook не нужен;
• если был чужой draft или доменная методика, authors и source_asset сохраняют вклад без приватных путей и raw-контекста;
• для team-ready есть 3 good examples и 2 anti-examples;
• все examples указаны в example_files и существуют;
• catalog.md содержит строку для team-ready и experimental;
• нет шаблонных заглушек, секретов, приватных путей и сырого приватного контекста;
• Claude sync gate проходит: repo-managed skills копируются через scripts/pull-skills.sh, local-only skills не удаляются;
• если skill изначально предназначался команде, не создана промежуточная активная личная копия;
• если был личный предшественник, финал отдельно называет готовность repo и состояние переноса; неразрешённая коллизия не выдаётся за завершённый перенос;
• test dependencies проверены в repo .venv или отдельной временной venv без изменения глобального Python; локальный native smoke имеет наблюдаемый результат либо честный LOCAL_NATIVE_SMOKE_BLOCKED;
• python3 -m pytest проходит локально;
• для каждого нового или существенно изменённого skill наблюдаемая проба первого ответа в свежем контексте получила актуальный BEHAVIOR_PROBE_PASS; если таких skills несколько, пакет охватывает каждый из них, а структурный pytest не выдан за наблюдаемую пробу;
• PR title/body прошли governance до внешнего изменения отдельным вызовом, опубликованный текст прочитан обратно, remote head подтверждён и полный список checks просмотрен без усечения;
• при публикации PR создан, CI зелёный или явно ожидает выполнения, все уже появившиеся комментарии автоматического review прочитаны и обработаны, а обоснованные actionable comments исправлены.