Как готовить AI-скиллы: от теории к практике
Подписчик спрашивает: «Насколько скиллы вообще полезны? Kimi и так неплохо шерстит по коду и понимает кодстайл. Не понимаю, как их готовить».
Ну и да, он прав — для кодстайла скилл не нужен. Закинул правила в AGENTS.md, и агент сам разберётся.
Скилл — это другое. Это когда тебе надо, чтобы агент шёл по твоему пайплайну, а не придумывал свой. Без скилла он пойдёт по пути наименьшего сопротивления. И придёт не туда.
Открываю .kimi/skills/ и разбираю три примера из реальных проектов 👾
Пример 1: precommit-code-review (code review перед коммитом) Скилл — это не эссе «пожалуйста, проверь код хорошо». Это триггер + конечный автомат.
Триггер: Запускать перед каждым git commit.
Workflow: Модель получает line-level diff и проверяет его не на опечатки, а на архитектурные правила проекта:
⏺Соблюдена ли гексагональная архитектура?
⏺Не нарушена ли политика Projection-Only Reads?
⏺Соответствует ли код Type-Safe Commits?
⏺Написаны ли тесты на TUnit под .NET 10?
⏺Общее ревью, с подтверждением находок, само собой.
Без этого скилла агент может пропустить коммит, где другой агент нарушил типы между бекендом и мордой.
Пример 2: bugfix-tdd (Смирительная рубашка для баг-фиксов) А вот это мой любимец. Этот скилл включается по триггеру «Bug fixes». И здесь мы отрубаем самодеятельность, заставляя идти по фазам.
⏺Правило 1: Evidence-first. Нельзя чинить баг, не написав воспроизводящий тест. Антипаттерн «fix first, test later» запрещен.
⏺Правило 2: Трассировка. Имя теста должно быть в формате BUG###_NewMaster_ShouldGenerateSlots.
⏺Правило 3: Фазы (🔴🌱🌀).
🔴 Red: Агент пишет тест и ОБЯЗАН убедиться, что он упал с ожидаемой ошибкой. Коммитить в красной зоне запрещено.
🌱 Green: Агент пишет минимальный код для починки. Никакого рефакторинга! Это спасает от любимой ИИ-болезни — scope creep (когда вместо фикса null-check модель переписывает полмодуля).
🌀 Refactor: Только когда тесты позеленели, можно наводить красоту.
На выходе агент выдает четкий репорт: что упало -> какой был минимальный фикс -> что отрефакторено.
Пример 3: review-mr (Автоматизация ревью в GitLab) Этот скилл выводит агента за пределы вашего редактора и делает его полноценным ассистентом ревьюера.
Триггер: Команда «Проведи ревью MR #123».
Workflow:
⏺Шаг 1: Контекст. Агент идет по API в GitLab, вытягивает описание MR и полный diff изменений.
⏺Шаг 2: Перевод на человеческий. Агент генерирует понятное описание сделанной работы: что вообще делает этот пулл-реквест. Это дико упрощает чтение кода и контекста автору ревью.
⏺Шаг 3: Анализ и ОСТАНОВКА. Прогоняет код по нашим правилам (см. Пример 1), собирает замечания и… 🛑 СТОП. Выдает находки и саммари мне на валидацию.
⏺Шаг 4: Интеграция. Только после моего аппрува агент использует API GitLab, чтобы раскидать проверенные замечания как inline-комментарии прямо к конкретным строкам кода в веб-интерфейсе.
Почему Kimi без скиллов так не сделает? LLM авторегрессионна. Она стремится к завершению задачи в один проход.
Без скилла TDD Kimi прочитает тикет с багом, молча нашлепает логику, прикрутит сверху тест с именем Test1 и скажет «LGTM!». А без скилла для GitLab вы каждый раз будете обьяснять агенту как взять diff и описание к MR. Со скиллом рутина будет автоматизирована.
Скилл — это не про кодстайл. Скилл — это пошаговый воркфлоу для агента.
Берете свой процесс -> определяете триггер -> разбиваете на фазы -> заворачиваете в промпт.
Всё, вы великолепны, ваш агент работает по уставу. 🍀