# Dobavlenie Navyka V Biblioteku > «Добавь новый skill», «сделай из этого skill», «перенеси мой личный skill в командную библиотеку», «оформи workflow как командный skill», «доведи до team-ready», «проверь перед PR», «почини под CI»: файлы, тесты и PR в repo. - Skill: `kir-kopylov/dobavlenie-navyka-v-biblioteku` (Agent Skill, multi-file: 18 files) - Install (CLI): `npx skillmds@latest add kir-kopylov/dobavlenie-navyka-v-biblioteku` - Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/dobavlenie-navyka-v-biblioteku/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: kir-kopylov (https://skillmd.com/u/kir-kopylov) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/kir-kopylov/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 используйте локальный генератор: ```bash python3 scripts/new_skill.py --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 должен содержать минимум: ```yaml --- name: skill-name description: ... --- ``` Описание — главный механизм срабатывания. Включите туда: - что делает skill; - когда использовать; - естественные фразы-триггеры; - важные ограничения, если они помогают роутингу. В body держите только полезную процедуру: - секция `## Запуск Навыка` — первый H2, канонический текст из CONTRIBUTING: немедленный запуск для `team-ready` и `experimental`, явный вызов для `draft`, пометка и owner для `experimental` и `draft`; - обзор; - роутинг запросов; - процесс выполнения; - границы и safety; - definition of done. Не добавляйте длинную справочную документацию внутрь skill, если она не нужна для выполнения задачи. ## skill.yaml Для `team-ready` заполните: ```yaml 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" ``` Если был внешний вклад, добавьте: ```yaml 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 должен содержать: ```markdown ## Вход ## Ожидаемое Поведение ## Нельзя ``` Хороший example доказывает применимость skill на реалистичном запросе. Anti-example показывает границу, где skill должен отказаться, спросить уточнение или выбрать другой workflow. Если skill задаёт структурированный результат, зафиксируйте одну каноническую схему в `SKILL.md` или его шаблоне и используйте её во всех examples и tests. Regression test должен проверить по этой схеме каждый структурированный example, а на отдельной испорченной копии с изменённым полем, типом или формой подтвердить, что проверка падает. Для skill с обычным текстовым ответом искусственную схему не вводите. ## Known Exceptions Для нового или изменяемого skill добавьте рядом с `SKILL.md` файл `known-exceptions.yaml`. Минимальный пустой файл: ```yaml exceptions: [] ``` Если у skill уже есть известные сбои, каждая запись должна содержать: ```yaml exceptions: - symptom: "Что наблюдает Codex или пользователь." root_cause: "Почему skill ошибается." do_next_time: "Что сделать сразу в следующий раз." source_example: "Какой example, test или sanitized packet подтверждает правило." ``` Перед выполнением skill должен читать этот файл как список известных случаев. Сырые `exception-log.jsonl` хранятся только приватно вне repo, например в `~/.codex/skill-runs//`. ## Опрос После Использования Опрос задаётся один раз — после завершения работы над skill — PR открыт или работа явно остановлена, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте. ```text Опрос по skill: 1. Что в этом использовании dobavlenie-navyka-v-biblioteku было полезно? 2. Что стоит доработать в skill или его формате? Можно ответить коротко или написать "пропустить". ``` Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/dobavlenie-navyka-v-biblioteku/usage-feedback.jsonl` — лучше через bundled script: ```bash 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//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. Перед завершением всегда запустите: ```bash 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 `; 6. только после наблюдаемого кода возврата `0` отдельным вызовом выполните `gh pr create --body-file ` или `gh pr edit --body-file `. Проверку и внешнее изменение нельзя объединять в последовательный shell-блок: падение проверки должно физически исключать публикацию; 7. прочитайте сохранённые title и body обратно через `gh pr view` и сравните с проверенными файлами; 8. подтвердите опубликованную голову ветки через `git ls-remote --heads origin ` или `gh pr view --json headRefName,headRefOid`; локальный `git fetch`, настроенный только на `main`, не доказывает состояние PR-ветки; 9. выполните полный `gh pr checks ` без `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 исправлены.