Агентские скиллы: как применить их в разработке

Привет, меня зовут Дима Васильев, я бэкенд-разработчик в Doubletapp. В этом тексте коротко расскажу, как эффективно управлять кодовыми ассистентами с помощью агентских скиллов.

Ассистенты уже умеют читать репозиторий, править файлы и запускать команды, но им часто не хватает контекста команды: как оформлять задачи, какие проверки запускать, как работать со стендами и где нужно подтверждение. Для этого и нужны агентские скиллы. 

Скилл — это инструкция для ИИ-помощника: когда её применять, по каким шагам действовать, какие шаблоны и команды использовать. В открытой спецификации Agent Skills скилл обычно оформляется как папка с SKILL.md; рядом могут лежать скрипты, справки и шаблоны.

Подход уже поддерживают разные кодовые ассистенты. GitHub Copilot работает с agent skills в режиме агента, Copilot CLI и облачном агенте. Codex поддерживает скиллы в командной строке, расширении и приложении. Claude Code тоже работает со скиллами через SKILL.md. Поэтому речь не про один инструмент, а про общий способ описывать повторяемые действия команды рядом с кодом.

Кейс 1. Описание проделанной работы

Разработчик закончил задачу, а дальше её должны подхватить тестировщики, аналитики или другие разработчики. Часто в задаче остаётся короткое «сделал», хотя нужно больше контекста.

Можно сделать скилл «описать изменения». Он смотрит на изменения в коде, коммиты и описание задачи, а потом формирует выжимку: что изменилось, какие модули затронуты, как проверить результат, есть ли риски, миграции, настройки или флаги.

Такой скилл помогает не забывать важные детали и делает передачу задачи более предсказуемой.

Кейс 2. Онбординг новых разработчиков

Проектные скиллы полезны для онбординга. В них можно описать, как поднять окружение, как запускать тесты, как оформлять ветки и коммиты, где смотреть логи и какие архитектурные правила нельзя нарушать.

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

Кейс 3. Надстройка над Terraform

Другой пример — сложные инструменты. Допустим, команде нужен Terraform для стендов, но не все хорошо с ним знакомы. Реальных знаний Terraform скилл не заменит: всё равно важно понимать состояние, план изменений, ресурсы и последствия удаления инфраструктуры.

Но для повседневной работы можно сделать понятные действия поверх Terraform:

• Init stand — подготовить стенд;

• Update stand — применить изменения;

• Destroy stand — удалить стенд.

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

Главное здесь — не просто удобство, а безопасность. В скилле можно прописать: перед применением изменений показать план, перед удалением стенда запросить отдельное подтверждение, не выполнять опасные команды молча и не использовать непроверенные переменные окружения. Так команда получает понятный интерфейс к сложному инструменту, но сохраняет контроль.

Что это даёт

Главная польза скиллов в том, что командные знания становятся частью проекта. Их можно обсуждать и улучшать так же, как код. Это мост между «ИИ просто помогает писать код» и «ИИ помогает соблюдать процессы команды»: оформление задач, проверки, инфраструктура, отчёты, онбординг и документация.

Где посмотреть готовые примеры

Сторонние скиллы стоит читать как чужой код: внутри могут быть скрипты и команды. Особенно внимательно стоит смотреть на скиллы, которые запускают команды.

Полезные материалы и репозитории:

• Agent Skills specification

• OpenAI skills

• Anthropic skills

• GitHub Awesome Copilot

• HashiCorp agent skills

Для начала достаточно взять один небольшой процесс, описать его в SKILL.md и положить рядом с кодом.

Временные ссылки: как мы убираем секреты из рабочих чатов

В рабочих чатах постоянно всплывает чувствительная информация: API-ключи, временные пароли, доступы к тестовым аккаунтам, документы, архивы, конфиги. Обычно это выглядит безобидно: «скинь токен», «вот пароль от стенда», «держи файл». Но у такого подхода есть проблема — всё это остаётся в истории переписки.

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

Чтобы снизить этот риск, мы сделали внутри DTIS (кастомная CRM-система от Doubletapp) сервис «Временные ссылки».

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

Это не замена полноценным vault-системам и менеджерам секретов. Но сервис хорошо закрывает частый рабочий сценарий: быстро передать чувствительную информацию коллеге, подрядчику или клиенту, не оставляя её навсегда в мессенджере.

Как это выглядит в интерфейсе

В DTIS появился отдельный пункт меню «Временные ссылки». Он ведёт на страницу управления временными ссылками.

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

Ниже отображается список ранее созданных актуальных ссылок. Для удобства есть поиск по названию. У каждой ссылки можно посмотреть срок действия, скопировать её или вручную отозвать, если она была отправлена не туда или больше не нужна.

Просроченные ссылки в списке не хранятся. Пользователь видит только то, что ещё действительно актуально.

Режимы доступа

Мы оставили два основных сценария.

Первый — только пользователи DTIS. Это режим по умолчанию. Он подходит для внутренней передачи данных между сотрудниками, когда ссылку может открыть только авторизованный пользователь.

Второй — доступ для всех, у кого есть ссылка. Он нужен для ситуаций, когда данные нужно передать внешнему пользователю: клиенту, подрядчику или партнёру.

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

Почему сделали внутри, а не взяли внешний сервис

Для таких данных важно контролировать весь контур: где они хранятся, кто имеет доступ, как удаляются и какие правила применяются. Внешние сервисы могут быть удобными, но для передачи рабочих секретов это лишний риск: зависимость от сторонней инфраструктуры, возможные утечки, изменения условий и отсутствие нужной интеграции с нашей моделью доступа.

Готовыми внешними сервисами для такой задачи мы пользоваться не хотели. При этом подходящего self-hosted решения, которое можно было бы быстро и аккуратно встроить в DTIS, авторизацию и внутренние процессы, мы для себя не нашли. Поэтому решили сделать небольшой собственный инструмент под наши сценарии.

Что получилось

Теперь вместо сообщения «вот пароль от стенда» в рабочем чате появляется временная ссылка. Она живёт ограниченное время, может быть доступна только авторизованным сотрудникам и при необходимости отзывается вручную.

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

Подробнее о том, как и почему мы решили сделать собственную CRM-систему, в рамках которой работает наш сервис временных ссылок, можно прочитать в статье нашего CTO.