# 10 лучших навыков агента для Codex, чтобы улучшить ваш рабочий процесс
> Откройте для себя лучшие навыки Codex для планирования проектов, отладки неудачных CI-пайплайнов, тестирования приложений, реализации дизайна, развертывания веб-проектов и оптимизации повседневных рабочих процессов разработки.
- Canonical: https://nanoskill.ai/ru/blog/best-agent-skills-for-codex
- Markdown: https://nanoskill.ai/ru/blog/best-agent-skills-for-codex.md
- Author: Jeff Page
- Published: 2026-06-26T09:09:24.794Z
- Updated: 2026-07-25T04:38:34.299Z
- Language: ru
## Введение
Codex уже умеет писать код, объяснять незнакомые репозитории, исправлять ошибки и помогать разработчикам работать быстрее. Но для большинства команд настоящим узким местом является не генерация нескольких строк кода.
Это всё, что окружает код.
Планирование функции перед реализацией. Понимание неудачного запуска CI. Ответ на комментарии к pull-запросу. Тестирование пользовательского потока в реальном браузере. Очистка набора данных. Написание документации. Подготовка проекта к развертыванию.Это повторяющиеся рабочие процессы, которые незаметно съедают часы каждую неделю. Именно здесь навыки агента становятся полезными.
Навыки агента дают Codex повторяемый способ обработки определенного типа задач. Вместо того чтобы снова объяснять одни и те же требования в каждом запросе, вы можете снабдить Codex структурированными инструкциями, вспомогательными ресурсами и рабочими процессами, специфичными для задачи. Результатом является не только более быстрая работа, но и более последовательная работа на этапах планирования, разработки, тестирования, проверки и доставки.
С правильными навыками Codex становится больше, чем просто помощник по кодированию. Он может работать как сосредоточенный товарищ по команде, который знает, как ваша команда планирует функции, проверяет качество, анализирует данные и выпускает проекты.
В этом руководстве мы рассмотрим лучшие навыки агента для Codex в 2026 году, включая навыки для планирования продукта, рабочих процессов GitHub, тестирования в браузере, анализа данных, проверки безопасности, преобразования дизайна в код, развертывания и документации.Цель состоит не в том, чтобы установить каждый навык, который вы сможете найти. Цель — определить те, которые устраняют наиболее часто повторяющиеся трения в вашем рабочем процессе.
## **Краткий обзор: Лучшие навыки агента для Codex**
Вот краткий обзор лучших навыков агента для Codex и рабочих процессов, для которых они наиболее полезны.
### Быстрое сравнение: Лучшие навыки агента для Codex
| Навык | Лучше всего подходит для | Что это помогает Codex делать | Что вам нужно |
| --- | --- | --- | --- |
| Определение цели | Четкие критерии успеха | Превращает расплывчатые запросы в измеримые цели, границы объема и шаги верификации | Задача с неясными требованиями или несколькими возможными исходами |
| gh-исправить-ci | Исправление неудачных проверок CI | Исследует сбои GitHub Actions, просматривает журналы и предлагает целенаправленный план восстановления | Доступ к GitHub CLI и репозиторию, использующему GitHub Actions |
| gh-адресовать-комментарии | Обратная связь по обзору PR | Собирает комментарии рецензирования, суммирует запрошенные изменения и помогает адресовать выбранную обратную связь | Открытый запрос на включение GitHub и доступ к GitHub CLI |
| Драматург | Тестирование в браузере и отладка UI | Открывает реальный браузер, тестирует пользовательские потоки, заполняет формы, нажимает кнопки и делает снимки экрана | Веб-проект плюс рабочая среда Node.js и npm |
| Лучшие практики безопасности | Кодирование с безопасностью по умолчанию | Проверяет код на наличие распространенных рисков безопасности и рекомендует более безопасные шаблоны реализации | Поддерживаемая кодовая база, такая как Python, JavaScript/TypeScript или Go |
| Figma Реализация Дизайна | Рабочие процессы Figma-в-код | Преобразует макеты Figma, компоненты и токены дизайна в руководство по реализации фронтенда | Доступ к Figma MCP и файлу Figma, фрейму или выбранному узлу |
| Jupyter Блокнот | Анализ данных и эксперименты | Создает и структурирует блокноты для исследований, анализа, учебных пособий и воспроизводимых рабочих процессов | Набор данных, эксперимент или рабочий процесс анализа |
| Создатель CLI | Многоразовые внутренние инструменты | Создает долговечные инструменты командной строки для повторяющихся задач, API и внутренней автоматизации | Повторяющийся рабочий процесс, который стоит превратить в общий инструмент |
| Vercel Развертывание | Доставка предпросмотров развертываний | Публикует веб-проект и генерирует доступный URL предпросмотра для тестирования и обратной связи | Развертываемый веб-проект и доступ к Vercel |
| Документация OpenAI | Создание с продуктами OpenAI | Использует официальную документацию OpenAI для API, моделей, SDK, миграций и рабочих процессов Codex | Задача разработки, связанная с OpenAI |
### Быстрый выбор по вариантам использования
- **Начните здесь, если ваши требования расплывчаты:**Определить цель
- **Начните здесь, если рабочие процессы GitHub вас замедляют:**gh-fix-ci или gh-address-comments
- **Начните здесь, если вы создаете веб-продукты:**Playwright и развертывание Vercel
- **Начните здесь, если вы тесно работаете с дизайнерами:**Реализация дизайна с Figma
- **Начните здесь, если вы анализируете исследовательские или бизнес-данные:**Jupyter Ноутбук
- **Начните здесь, если ваша команда повторяет одну и ту же рутинную задачу:**Создатель CLI
- **Начните здесь, если вы создаете функции искусственного интеллекта с OpenAI:**Документация OpenAI
- **Начните здесь, если вы хотите более безопасных привычек разработки:**Лучшие практики безопасности
Оптимальный выбор зависит от того, на каком этапе ваш рабочий процесс замедляется больше всего. Если вы создаете новый продукт, начните с навыков планирования, тестирования и развертывания. Если вы ежедневно работаете в GitHub, отдайте приоритет CI, пул-реквестам и рабочим процессам безопасности. Если ваша работа связана с исследованиями или данными о росте, большей ценности могут принести навыки анализа данных и документирования.
## **Лучшие навыки агента Codex: Подробные обзоры**
### **Наши критерии оценки**
Мы оценили эти навыки Codex на основе пяти практических факторов:
- **Влияние на рабочий процесс:**Устраняет ли этот навык значительное узкое место в реальной работе по разработке?
- **Сложность настройки:**Насколько много требует конфигурации, аутентификации или внешних инструментов?
- **Контроль и безопасность:**Сохраняет ли навык контроль пользователей перед внесением изменений в код или развертывание?
- **Ясность области применения:**Понятно ли, когда следует использовать этот навык, а когда нет?
- **Повторное использование:**Может ли рабочий процесс помочь в нескольких проектах, репозиториях или командах?
Это редакционные оценки, основанные на документированном рабочем процессе каждого навыка, предварительных требованиях и предполагаемых сценариях использования. Они не являются эталонными показателями или гарантиями качества вывода.
### **Определить цель: Лучше всего для четких критериев успеха**
](https://file.nanoskill.ai/define-goal.png)
**Что он делает:**
Навык «Определить цель» помогает Codex превратить общие запросы в конкретное определение успеха до начала реализации. Вместо того чтобы рассматривать запрос, например «улучшить процесс онбординга», как простую задачу кодирования, он побуждает пользователя и агента уточнить, что нужно изменить, что выходит за рамки, как будет проверен результат и какие условия указывают на завершение работы.
**Почему он выделяется:**
Удивительно много задач разработки проваливаются из-за того, что цель никогда не была четко определена. Код может работать, но он может решать не ту проблему, пропускать важный крайний случай или создавать очередной раунд доработок. Навык «Определить цель» дает Codex более прочную отправную точку, переводя разговор от расплывчатой деятельности к измеримым результатам.
Он особенно полезен, когда задача затрагивает множество заинтересованных сторон, неясные требования к продукту, целевые показатели производительности, миграцию или отчеты об ошибках, которые необходимо преобразовать в проверяемые критерии приемки. Определив финишную черту до начала кодирования, команды могут сократить ненужные обсуждения и дать Codex более четкие ориентиры для предстоящей работы.
**Пример задачи:**
«Улучшить процесс онбординга для новых пользователей. Определите измеримую цель, уточните целевое действие пользователя, определите, что входит в объем работ, а что нет, предложите критерии приемки и объясните, как должен быть проверен конечный результат до начала любой реализации.»
**Лучше всего подходит для:**
Продуктовые команды, разработчики и технические руководители, работающие с неоднозначными запросами на функции, исправлением ошибок, задачами миграции или работой, чувствительной к качеству.
### **gh-fix-ci: Лучше всего для исправления неудачных проверок CI**
](https://file.nanoskill.ai/gh-fix-ci-skill.png)
**Что он делает:**
gh-fix-ci помогает Codex расследовать неудачные проверки GitHub Actions в пул-реквесте. Он может проверить состояние рабочего процесса, просмотреть журналы сбоев, определить наиболее вероятную причину проблемы и предложить целенаправленный план исправления до внесения изменений.
**Почему он выделяется:**
Сбои CI являются одним из самых распространенных источников затруднений в современной разработке программного обеспечения. Разработчику может потребоваться переключаться между журналами GitHub, локальными результатами тестов, файлами зависимостей, изменениями в пул-реквесте и конфигурацией рабочего процесса, только чтобы понять, почему сборка не удалась. gh-fix-ci дает Codex структурированный способ собрать этот контекст и сузить круг проблемы.
Этот навык особенно ценен, потому что он отделяет диагностику от реализации. Вместо того чтобы сразу вносить масштабные изменения, Кодекс сначала может объяснить, что именно не удалось, почему это, вероятно, произошло, и что следует проверить дальше. Это делает рабочий процесс более прозрачным и обеспечивает разработчикам более быстрый путь от «красного» статуса CI к подтверждённому исправлению
**Пример задачи:**
«Проверьте неудачные проверки Гитхаб Действия для этого пулл-реквеста. Обобщите вероятную первопричину, определите затронутые файлы или шаги рабочего процесса и предложите минимальный безопасный план исправления, прежде чем вносить какие-либо изменения в код.»
**Лучше всего подходит для:**
Команды, использующие Гитхаб Действия для тестов, сборок, линтинга, проверки типов и валидации пулл-реквестов.
### **gh-адрес-комментарии: лучше всего подходит для обработки отзывов при ревью ПР**
](https://file.nanoskill.ai/gh-address-comments-skill.png)
**Что он делает:**
gh-адрес-комментарии помогает Кодексу собирать и систематизировать отзывы по ревью пулл-реквестов. Он может идентифицировать обсуждения ревью, обобщать, что требуется в каждом комментарии, группировать связанные запросы и помогать пользователям решать, какие комментарии должны привести к изменениям кода.
**Почему он выделяется:**
Ревью кода редко бывает сложным из-за одного комментария. Оно становится трудоёмким, когда отзывы разбросаны по разным рецензентам, файлам, обсуждениям и последующим дискуссиям. Разработчикам часто приходится вручную перечитывать комментарии, решать, какие из них требуют действий, понимать намерения, стоящие за каждым запросом, и отслеживать, что уже было учтено.
Этот навык превращает раздробленный процесс в более управляемый рабочий процесс. Вместо того чтобы считать каждый комментарий рецензента одинаково срочным, Кодекс может помочь обобщить отзывы, выделить пункты, требующие действий, и сделать процесс доработки более осознанным. Это особенно полезно для крупных пулл-реквестов, быстро работающих команд и разработчиков, которые хотят уменьшить переключение контекста, продолжая при этом тщательно реагировать на отзывы рецензентов.
**Пример задачи:**
«Просмотрите все неразрешённые комментарии к текущему пулл-реквесту. Сгруппируйте связанные отзывы, обобщите, чего требует каждый рецензент, определите, какие комментарии требуют изменений кода, и попросите меня подтвердить пункты, которые вы должны учесть, прежде чем редактировать ветку.»
**Лучше всего подходит для:**
Разработчикам, работающим в совместных репозиториях Гитхаб с частыми пулл-реквестами и отзывами от нескольких рецензентов.
### **Плейрайт: лучше всего подходит для тестирования браузера и отладки пользовательского интерфейса**
](https://file.nanoskill.ai/playwright-skill)
**Что он делает:**
Плейрайт даёт Кодексу возможность взаимодействовать с реальным браузером из терминала. Он может открывать страницы, перемещаться по пользовательским сценариям, заполнять формы, нажимать кнопки, проверять состояние страницы, делать скриншоты и помогать воспроизводить проблемы интерфейса, которые трудно понять только из кода.
**Почему он выделяется:**
Функциональность может проходить модульные тесты, но сбоить в реальном пользовательском опыте. Форма может отправляться некорректно, модальное окно не закрываться, кнопка может быть скрыта на маленьких экранах, или страница ломается только после определённой последовательности кликов. Именно такие проблемы становятся очевидными, когда кто-то взаимодействует с продуктом как пользователь.
Плейрайт помогает Кодексу выйти за рамки рассуждений на уровне репозитория и проверить видимое поведение в реальной среде браузера. Это делает его ценным для отладки регрессий пользовательского интерфейса, проверки процессов онбординга, валидации платёжных или регистрационных путей и подтверждения того, что функция работает с точки зрения пользователя, а не только в коде.
**Пример задачи:**
«Запустите локальное приложение и протестируйте процесс регистрации в реальном браузере. Создайте тестовую учётную запись, заполните обязательные поля, убедитесь, что экран подтверждения появляется, и сделайте скриншот и трассировку, если какой-либо шаг не выполнится.»
**Лучше всего подходит для:**
Фронтенд-разработчикам, Саас-командам, процессам контроля качества и всем, кто создаёт продукты на основе браузера.
### **Лучшие практики безопасности: лучше всего подходит для обеспечения безопасности по умолчанию при кодировании**
](https://file.nanoskill.ai/security-best-practices)
**Что он делает:**
Лучшие практики безопасности помогает Кодексу проверять код на наличие распространённых рисков безопасности и рекомендовать более безопасные шаблоны реализации. Это может помочь агенту более тщательно продумывать проверку входных данных, работу с секретами, аутентификацию, разрешения, небезопасные значения по умолчанию и распространённые уязвимости на уровне приложений.
**Почему он выделяется:**
Проблемы безопасности часто начинаются с обычных на первый взгляд решений разработки: отсутствующая проверка авторизации, открытая переменная окружения, слабая проверка ввода, слишком широкое правило разрешений или небезопасная обработка пользовательских данных. Эти проблемы легко упустить из виду, когда команда сосредоточена на быстром выпуске функций.
Этот навык помогает внедрить мышление о безопасности раньше в процессе разработки. Вместо того чтобы рассматривать безопасность как контрольный список на финальном этапе, Codex может использовать более безопасные шаблоны реализации, пока код пишется или проверяется. Это особенно полезно для небольших команд, у которых нет выделенного инженера по безопасности, проверяющего каждый pull request, но которым всё равно нужны более сильные привычки в отношении разработки с безопасностью по умолчанию.
**Пример задачи:**
«Проверьте процесс аутентификации и обновления профиля пользователя в этом приложении на предмет распространённых рисков безопасности. Проверьте проверку ввода, авторизацию, обработку секретов, управление сессиями и небезопасные значения по умолчанию. Рекомендуйте изменения в сторону безопасности по умолчанию с примерами на уровне кода.»
**Лучше всего подходит для:**
Стартапов, full-stack разработчиков, создателей API и команд, работающих над клиентскими приложениями.
### **Figma Implement Design: Лучше всего для рабочих процессов из Figma в код**
](https://file.nanoskill.ai/figma-implement-design)
**Что он делает:**
Figma Implement Design помогает Codex преобразовывать компоненты Figma, экраны, макеты, дизайн-токены и визуальные ссылки в готовый к продакшену фронтенд-код. Он предоставляет агенту структурированный контекст дизайна, чтобы решения по реализации основывались на реальном дизайне, а не на приблизительной визуальной интерпретации.
**Почему он выделяется:**
Передача дизайна — один из крупнейших источников трений между продуктовым дизайном и фронтенд-разработкой. Разработчикам необходимо понимать отступы, типографику, адаптивное поведение, иконографию, компоненты, состояния и существующие соглашения дизайн-системы. Без чёткого контекста реализация может отклоняться от задуманного дизайна или вносить несогласованные UI-паттерны.
Этот навык делает передачу более систематической. Он побуждает Codex по возможности повторно использовать существующие компоненты и дизайн-токены, точнее следовать визуальным паттернам и проверять конечный результат на соответствие исходному дизайну. Для команд, которые ежедневно работают в Figma, это может сократить путь от утверждения дизайна до более отточенной, согласованной реализации.
**Пример задачи:**
«Используйте выбранный фрейм Figma, чтобы реализовать эту страницу панели управления в существующем фронтенд-проекте. По возможности повторно используйте текущую библиотеку компонентов и дизайн-токены, точно соблюдайте макет и типографику, поддерживайте адаптивное поведение и сравните конечную страницу с дизайном Figma.»
**Лучше всего подходит для:**
Продуктовых команд, фронтенд-разработчиков и дизайнеров, работающих с дизайн-системами на основе Figma.
### **Jupyter Notebook: Лучше всего для анализа данных и экспериментов**
](https://file.nanoskill.ai/jupyter-notebook)
**Что он делает:**
Jupyter Notebook помогает Codex создавать, редактировать, организовывать и рефакторить ноутбуки для анализа данных, экспериментов, учебных пособий и воспроизводимых исследовательских рабочих процессов. Он может поддерживать более чёткую структуру ноутбука с читаемыми пояснениями в markdown, логичными ячейками кода и более продуманными шагами анализа.
**Почему он выделяется:**
Ноутбук полезен не просто потому, что он выполняется. Хороший ноутбук также должен быть лёгким для понимания, воспроизведения и расширения другими. На практике многие ноутбуки становятся трудными для восприятия, потому что код, заметки, временные эксперименты и результаты смешиваются без чёткой структуры.
Этот навык помогает Codex создавать ноутбуки, которые являются чем-то большим, чем одноразовые черновики. Он может поддерживать более чистый исследовательский анализ, более понятные эксперименты и лучшие ноутбуки в стиле учебных пособий для обучения или обмена. Это делает его ценным для исследователей, аналитиков, команд роста и всех, кому нужно превратить работу с данными в переиспользуемый артефакт, а не в одноразовый скрипт.
**Пример задачи:**
«Создайте чистый Jupyter ноутбук, который анализирует этот набор данных CSV. Включите очистку данных, описательную статистику, визуализации, ключевые выводы и пояснения в markdown для каждого шага. Структурируйте ноутбук так, чтобы другой исследователь мог запустить его от начала до конца.»
**Лучше всего подходит для:**
Исследователи, аналитики, преподаватели, специалисты по машинному обучению и команды, работающие с экспериментами или структурированными наборами данных.
### **CLI-Создатель: Лучший для переиспользуемых внутренних инструментов**
](https://file.nanoskill.ai/cli-creator)
**Что он делает:**
CLI-Создатель помогает Codex создавать надежные инструменты командной строки для повторяющихся рабочих процессов. Эти инструменты могут поддерживать взаимодействие с API, локальную автоматизацию, внутренние операции, извлечение данных, административные задачи и повторяемые действия, которые в противном случае требовали бы ручной работы в браузере или одноразовых скриптов.
**Почему он выделяется:**
Многие команды многократно выполняют одни и те же задачи: проверка журналов, экспорт данных, загрузка файлов, запросы к внутренним системам, синхронизация информации или запуск безопасных операционных действий. Поначалу эти задачи часто решаются с помощью специальных скриптов или набора недокументированных ручных шагов. Со временем это создает трудности, непоследовательность и ненужную зависимость от отдельных членов команды.
CLI-Создатель помогает превратить повторяющуюся работу в более чистый внутренний продукт. Вместо того чтобы решать одну и ту же проблему каждую неделю, команды могут создать переиспользуемый интерфейс командной строки с более четкими командами, предсказуемым выводом, более безопасной обработкой аутентификации и документацией, которой могут следовать другие. Это один из самых сильных навыков, превращающих Codex из разового помощника в партнера по созданию инструментов.
**Пример задачи:**
«Создайте переиспользуемый инструмент командной строки, который получает записи клиентов из нашего внутреннего API по адресу электронной почты. Включите понятные команды, справочный текст, вывод в JSON, аутентификацию на основе переменных окружения, обработку ошибок и`--пробный-запуск`режим для любой операции записи.»
**Лучше всего подходит для:**
Инженерные команды, платформенные команды, операционные команды и разработчики с повторяющимися внутренними рабочими процессами.
### **Vercel Развертывание: Лучший для поставки предварительных развертываний**
](https://file.nanoskill.ai/vercel-deploy-skill)
**Что он делает:**
Vercel Развертывание помогает Codex опубликовать веб-проект на Vercel и сгенерировать предварительное развертывание, доступное для общего доступа. Это дает пользователям рабочую URL-ссылку, которую можно открыть, просмотреть, протестировать и поделиться ею до того, как проект будет выпущен в производство.
**Почему он выделяется:**
Проект становится легче оценить, как только люди могут взаимодействовать с ним в браузере. Локальная разработка полезна для создания, но предварительные развертывания позволяют коллегам, клиентам, дизайнерам, заинтересованным сторонам и ранним пользователям увидеть результат в контексте.
Этот навык сокращает расстояние между «код работает на моей машине» и «кто-то еще может его протестировать». Это делает его особенно полезным для портфолио, целевых страниц, прототипов, внутренних информационных панелей, MVP и ранних экспериментов с SaaS. Он также поддерживает более безопасный ритм выпуска, сосредотачиваясь на предварительных развертываниях, где команды могут собирать отзывы и выявлять проблемы до перехода к полноценному запуску в производство
**Пример задачи:**
«Разверните текущий веб-проект на Vercel в качестве предварительного развертывания. Убедитесь, что сборка прошла успешно, верните URL предварительного просмотра и не создавайте и не изменяйте производственное развертывание.»
**Лучше всего подходит для:**
Независимые разработчики, студенты, команды стартапов, продуктовые разработчики и все, кому нужны быстрые ссылки для предварительного просмотра, которыми можно поделиться.
### **Документация OpenAI: Лучший для создания с продуктами OpenAI**
](https://file.nanoskill.ai/openai-docs)
**Что он делает:**
Документация OpenAI помогает Codex использовать официальную документацию OpenAI при работе с API OpenAI, моделями, SDK, миграциями, агентами и рабочими процессами, связанными с Codex. Это поощряет решения по реализации, основанные на актуальной документации от первого лица, а не на устаревших учебных пособиях или неофициальных примерах.
**Почему он выделяется:**
Разработка ИИ меняется быстро. Возможности моделей, параметры API, шаблоны SDK, руководства по миграции и рекомендации по продуктам могут развиваться быстрее, чем обновляются многие сторонние учебные пособия. Это создает реальный риск для разработчиков, которые копируют примеры из старых блогов или фрагментов сообщества, не проверяя, является ли информация все еще актуальной.
Этот навык предоставляет Codex более надежный источник достоверной информации при работе с продуктами OpenAI. Он особенно полезен для вопросов реализации, которые зависят от актуальной документации, таких как выбор правильного шаблона API, понимание поддерживаемых функций, обработка изменений при миграции или следование последним руководствам по Codex и рабочим процессам агентов.
**Пример задачи:**
«Используя только официальную документацию OpenAI, порекомендуйте лучший текущий подход к реализации для добавления вопросно-ответной системы на основе документов в это приложение. Сравните соответствующие варианты API, перечислите необходимые шаги настройки, объясните ключевые параметры и предоставьте минимальный пример на TypeScript.»
**Лучше всего подходит для:**
Разработчиков, создающих продукты с использованием API OpenAI, моделей OpenAI, агентов, Codex или функций на базе ИИ.
## **Примеры рабочих процессов навыков Codex**
Навыки агентов легче оценить, когда видно, как они изменяют реальную задачу. Вместо простого перечисления функций следующий пример показывает, что происходит, когда Codex получает расплывчатый запрос на продукт и использует структурированный навык, чтобы превратить его в более четкий и проверяемый результат.
### **Рабочий процесс 1: Превращение «Улучшить онбординг» в измеримую цель продукта**
**Сценарий:**
Команда SaaS замечает, что многие новые пользователи создают учетную запись, но уходят до завершения настройки рабочего пространства. Первоначальный запрос прост: «Улучшить процесс онбординга». Однако в запросе не определены целевой показатель, сроки, объем или четкий способ доказать, что работа увенчалась успехом.
**Используемый навык:**
Определить цель
**Используемый промпт:**
«Улучшите процесс онбординга для новых пользователей. Определите измеримую цель, уточните целевое действие пользователя, определите, что входит и что не входит в объем, предложите критерии приемки и объясните, как следует проверить конечный результат до начала какой-либо реализации».
Вместо того чтобы сразу предлагать изменения пользовательского интерфейса или писать код, Codex сначала переформулировал запрос как цель продукта. Он определил 30-дневную цель, установил базовые показатели, задал измеримые критерии успеха и определил доказательства, необходимые для проверки того, действительно ли работа улучшила опыт онбординга.
](https://file.nanoskill.ai/define-goal-sample1)
Исходный запрос не содержал измеримого определения успеха. После применения навыка «Определить цель» Codex преобразовал его в конкретный результат: увеличить завершение онбординга с 42% как минимум до 55%, сократив при этом среднее время завершения с 6 минут 30 секунд до 5 минут или менее.
В этом ключевая ценность навыка. Он переводит задачу с «сделать что-то лучше» на цель, которую можно протестировать, измерить и проанализировать после выпуска.
Codex также добавил четыре элемента, которые часто отсутствуют в нечетко определенных запросах:
- **Четкие критерии успеха:**что команда должна достичь, прежде чем работа может считаться успешной.
- **Определенный объем:**какая часть процесса онбординга должна быть улучшена в первую очередь.
- **Доказательства проверки:**аналитика после выпуска, необходимая для подтверждения результата.
- **Условия остановки и запроса:**ситуации, в которых Codex должен запрашивать разъяснения, а не делать предположения.
](https://file.nanoskill.ai/define-goal-sample2)
Важная часть этого рабочего процесса заключается в том, что Codex не отметил цель как выполненную. Он правильно определил, что цель остается заблокированной до тех пор, пока не произойдут две вещи: пересмотренный процесс онбординга будет выпущен, и аналитика после выпуска подтвердит целевые показатели с использованием тех же определений базовых событий.
Это различие имеет значение. Навык может определить цель, подготовить план проверки и создать вспомогательные артефакты, но он не должен заявлять об успехе без реальных доказательств.
**Почему этот рабочий процесс важен:**
Навык «Определить цель» наиболее полезен, когда задача начинается с неоднозначного запроса, множества заинтересованных сторон или неясных критериев успеха. Он дает Codex более дисциплинированную отправную точку и помогает командам договориться о том, что на самом деле означает «готово», до начала реализации.
### **Рабочий процесс 2: От неудачной проверки CI к целенаправленному плану исправления**
**Сценарий:**
Pull request не проходит автоматическую проверку тестов после небольшого изменения кода. Разработчик видит, что статус CI красный, но ему всё ещё нужно определить, что именно не удалось, связана ли проблема с кодом или с тестом, и каким должно быть минимальное безопасное исправление.
В этом примере неудачный тест ожидает, что функция add(2, 2) вернёт 5, в то время как фактический результат равен`4`. Важный вопрос не в том, как просто заставить проверку пройти. Вопрос в том, неверна ли реализация, неверно ли ожидание теста, или сбой указывает на более широкую проблему.
**Используемый навык:**
гх-фикс-си
**Пример запроса:**
«Проверь неудачные проверки действий GitHub для пул-реквеста в текущей ветке. Обобщи контекст сбоя, определи вероятную первопричину и предложи минимальный безопасный план исправления. Не редактируй код и не перезапускай рабочие процессы до тех пор, пока я явно не одобрю план.»
Вместо немедленного изменения кода, «гх-фикс-си» структурирует задачу как контролируемый диагностический рабочий процесс. Кодекс сначала проверяет неудачную проверку и её доступный контекст, определяет вероятную причину сбоя и предлагает минимальный план восстановления. Только после того, как пользователь подтвердит план, Кодекс должен внести изменения, запустить соответствующий тест и убедиться, что проверка пул-реквеста возвращает зелёный статус.
](https://file.nanoskill.ai/gh-fix-ci-sample)
_Рисунок 3. Иллюстративный рабочий процесс на основе навыка «гх-фикс-си»: Кодекс переходит от неудачной проверки действий GitHub к целенаправленному, доступному для рецензирования плану исправления._
В этом примере сигнал о сбое ясен. Кодекс использовал бы этот контекст сбоя, чтобы различить неправильную реализацию и неправильный тест. Здесь функция add, возвращающая 4, верна. Первопричиной является ожидание теста, которое неверно ожидает результат 5.
Полученный план исправления намеренно минимален:
1. Изменить ожидаемое значение в тесте с 5 на 4.
2. Запустить соответствующий тест локально.
3. Отправить одобренное изменение и повторно проверить статус пул-реквеста.
Самым важным шагом является**этап одобрения**. «гх-фикс-си» не предназначен для того, чтобы рассматривать каждую неудачную проверку как разрешение автоматически редактировать код. Он отделяет диагностику от реализации: Кодекс объясняет вероятную проблему, представляет целенаправленный план исправления и ждёт явного одобрения пользователя перед изменением ветки.
После одобрения ожидаемое конечное состояние очевидно: исправленный тест проходит локально, и проверка пул-реквеста возвращает зелёный статус.
Этот рабочий процесс полезен, потому что делает исправление CI более прозрачным и менее реактивным. Вместо того чтобы просить Кодекс «исправить ошибку» и надеяться на лучшее, разработчики могут изучить анализ сбоя, подтвердить предложенный объём изменений и сохранить чёткую запись того, как проблема была решена.
**Почему этот рабочий процесс важен:**
«гх-фикс-си» наиболее ценен для команд, которые используют действия GitHub как часть своего рабочего процесса с пул-реквестами. Это помогает Кодексу превратить неудачную проверку в структурированную последовательность диагностики, одобрения, внедрения и проверки, а не в попытку «чёрного ящика» заставить статус CI пройти.
### **Рабочий процесс 3: Тестирование и проверка неработающего процесса регистрации в браузере**
**Сценарий:**
Страница регистрации может выглядеть правильно при код-ревью, но всё равно давать сбой в самый важный момент: когда реальный пользователь пытается завершить процесс. Форма может принимать ввод, кнопка может выглядеть кликабельной, и фронтенд может не показывать явной ошибки — однако ожидаемое состояние подтверждения может так и не появиться после отправки.
В этом иллюстративном сценарии пользователь открывает страницу регистрации рабочего пространства, вводит полное имя, рабочий email и название рабочего пространства, затем нажимает**Создать рабочее пространство**. Ожидаемый результат — видимое сообщение с подтверждением:**«Рабочее пространство создано.»**Вместо этого процесс, кажется, отправляется, но не отображает никакого состояния подтверждения.
**Используемый рабочий процесс:**
Тестирование в браузере с использованием Playwright
**Пример запроса:**
«Откройте процесс регистрации рабочего пространства в браузере, заполните форму действительными данными, нажмите «Создать рабочее пространство» и убедитесь, что появляется видимое сообщение с подтверждением. Если процесс не удаётся, зафиксируйте соответствующие доказательства из браузера, определите вероятную причину и предложите минимальное безопасное исправление, прежде чем редактировать код.»
В отличие от проверки только кода, тестирование в браузере проверяет то, что на самом деле видит пользователь. Процесс начинается с воспроизведения пути от загрузки страницы до отправки формы, затем сравнивает видимый результат с ожидаемым результатом, ориентированным на пользователя.
](https://file.nanoskill.ai/playwright-sample)
_Рисунок 4. Иллюстративный процесс на основе Playwright: Codex переходит от неработающего процесса регистрации к доказательствам из браузера, одобрению и проверенному результату пользовательского сценария._
Первоначальный сбой — это не расплывчатое сообщение «что-то пошло не так». Тест в браузере имеет четкое, ориентированное на пользователя ожидание: после того как пользователь отправляет действительные регистрационные данные, страница должна отобразить сообщение с подтверждением**«Рабочее пространство создано».**
Вместо этого наблюдается результат, при котором после отправки не появляется состояние подтверждения. Это дает Codex конкретное условие сбоя для исследования, а не общую инструкцию «исправить страницу регистрации».
Это различие важно. Проблема не обязательно в том, что поля формы сломаны или данные пользователя недействительны. Вместо этого процесс предполагает, что приложение принимает корректные данные, но не отображает состояние успеха после отправки.
С этого момента Codex может структурировать расследование в контролируемую последовательность: проверить состояние браузера, проанализировать доказательства сбоя, определить вероятное отсутствующее поведение интерфейса и предложить минимальный план исправления. В данном случае предлагаемое исправление намеренно узкое: отобразить видимое**«Рабочее пространство создано»**состояние подтверждения после успешной отправки формы, оставляя существующий макет страницы и поведение валидации без изменений.
](https://file.nanoskill.ai/playwright-sample2)
_Рисунок 5. Шестиэтапный процесс тестирования в браузере: открыть сценарий, воспроизвести проблему, проверить доказательства в браузере, предложить исправление, получить одобрение и проверить ожидаемое конечное состояние._
Ключевым шагом является этап одобрения. Тестирование в браузере не должно автоматически превращаться в неконтролируемое редактирование кода. Codex может выявить сбой и порекомендовать минимальное изменение, но должен ждать одобрения пользователя, прежде чем изменять реализацию.
После применения одобренного исправления ожидаемое конечное состояние ясно: процесс регистрации отображает сообщение с подтверждением, а тест в браузере возвращает успешный результат. Это создает более надежный цикл разработки, чем просто просить агента «исправить страницу регистрации» без доказательств того, что пошло не так, или подтверждения того, что пользовательский сценарий теперь работает.
Этот пример является иллюстративным процессом, основанным на тестировании в браузере в стиле Playwright. Он не представляет собой рабочее приложение или завершенный реальный тестовый запуск.
**Почему этот процесс важен:**
Процессы на основе Playwright особенно ценны для frontend-команд, SaaS-продуктов и любых проектов, где видимый пользовательский опыт так же важен, как и сам код. Они помогают Codex проверять реальные взаимодействия — такие как клики, отправка форм, навигация и состояния подтверждения — вместо того чтобы полагаться только на статический анализ кода. Результатом является процесс, который связывает решения по реализации с тем, что пользователи на самом деле видят и делают в браузере.
## **Часто задаваемые вопросы о навыках Codex**
### **Что такое навыки Codex?**
Навыки Codex — это повторно используемые процессы, которые помогают Codex более последовательно выполнять определенный тип задач. Навык может включать инструкции, необязательные скрипты, справочные материалы и ресурсы, которые направляют Codex через повторяемый процесс.
Например, один навык может помочь Codex расследовать неудачные CI-проверки, а другой — превратить расплывчатый запрос на продукт в измеримую цель. Вместо того чтобы повторять один и тот же длинный запрос в каждом новом разговоре, вы можете использовать навык, чтобы сохранить рабочий процесс, предпочтительный формат вывода и важные правила.
### **Как установить навык Codex?**
Для курируемых навыков откройте Codex и используйте встроенный установщик.
Например, вы можете ввести:
**$установщик-навыков gh-исправить-ci**
После этого Codex может установить выбранный навык в вашу локальную среду. Если навык не появляется сразу после установки, перезапустите Codex и попробуйте вызвать его снова.
Вы также можете попросить установщик помочь вам найти подходящие навыки. Например:
**$установщик-навыков**
**Порекомендуйте навыки для тестирования в браузере и рабочих процессов GitHub.**
После установки вы можете явно вызвать навык, введя его имя со знаком доллара, например,**$gh-исправить-ci**или**$определить-цель**.
### **Могу ли я создать собственный навык Codex?**
Да. На самом деле, пользовательские навыки часто ценнее большой коллекции универсальных навыков.
Полезный пользовательский навык обычно начинается с повторяющегося рабочего процесса. Это может быть контрольный список выпуска, формат код-ревью, рутинная проверка качества в браузере, процесс документирования или задача внутренней отчетности.
Codex включает рабочий процесс Создателя навыков, который помогает превратить полезную ветку обсуждения, документ, скрипт, контрольный список или пример вывода в многоразовый навык. Пользовательский навык обычно начинается с обязательного`НАВЫК.md`файла и может включать необязательные ссылки, скрипты или шаблоны.
Лучшее время для создания навыка — после того, как вы один раз выполнили задачу и точно знаете, как должен выглядеть хороший результат.
### **В чем разница между навыком Codex и АГЕНТЫ.md?**
Файл`АГЕНТЫ.md`содержит постоянные руководства проекта. Он говорит Codex, как вести себя при работе в определенном репозитории или папке.
Например, файл`АГЕНТЫ.md`может содержать:
- Запустите тестовый набор перед открытием пул-реквеста.
- Не добавляйте новые зависимости без одобрения.
- Следуйте существующей библиотеке компонентов.
- Документируйте изменения публичного API.
Навык — это другое. Это многоразовый рабочий процесс для определенного типа задач.
Например:
- Используйте gh-исправить-ci, когда проверка действий GitHub не удается.
- Используйте навык тестирования в браузере при проверке потока регистрации.
- Используйте навык документирования при подготовке заметок о выпуске.
Простой способ запомнить разницу:
### **АГЕНТЫ.md определяет постоянные правила. Навыки определяют повторяемые задачи.**
### **Какой навык Codex стоит попробовать новичкам в первую очередь?**
Начните с навыка, который решает наиболее часто повторяющуюся проблему в вашем текущем рабочем процессе.
Если ваши задачи часто начинаются с неясных требований, начните с**Определить цель**. Он помогает превращать общие запросы в измеримые результаты, границы объема и критерии проверки.
Если вы проводите много времени в пул-реквестах GitHub, попробуйте**gh-исправить-ci**или**gh-обработать-комментарии**.
Если вы создаете веб-продукты, рабочие процессы тестирования в браузере, такие как**Playwright**полезны, потому что помогают проверить, что пользователи на самом деле видят и делают.
Если вы работаете с API или моделями OpenAI,**Документация OpenAI**может помочь Codex полагаться на актуальную официальную документацию, а не на устаревшие примеры.
Лучший первый навык обычно не самый продвинутый. Это тот, который устраняет повторяющийся источник трения в вашей работе.
### **Безопасно ли устанавливать навыки Codex?**
К навыкам следует относиться как к любому другому многоразовому средству автоматизации или инструменту разработчика: устанавливайте их из надежных источников, проверяйте, для чего они предназначены, и понимайте, какой доступ им требуется.
Прежде чем использовать навык в реальном проекте, проверьте, может ли он:
- Выполнять команды в вашем локальном окружении
- Получать доступ к внешним инструментам или подключенным сервисам
- Изменять файлы
- Создавать коммиты или пул-реквесты
- Запускать развертывания
- Читать документацию проекта или конфигурацию, связанную с секретами
Для экспериментов с низким риском начните в отдельной демонстрационной папке или тестовом репозитории. Когда навык предлагает существенное изменение, просмотрите план, прежде чем одобрять редактирование файлов, изменения кода, коммиты или развертывания.