В первом посте я рассказал, зачем вообще написал UniKit AI и какие проблемы классического AI-кодинга он закрывает.

Сейчас разбираем практику: как устроен полный цикл работы над фичей - от исследования до готового кода.

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

Сначала общий обзор, потом пройдёмся по каждому шагу с примерами:

/unikit - первоначальная настройка проекта, генерация архитектурных документов и правил

/unikit-explore - исследование фичи, когда непонятно с чего начинать

/unikit-plan - создание плана по артефакту исследования или из промта

/unikit-improve - улучшение плана через повторный анализ

/unikit-implement - выполнение плана целиком или по фазам

/unikit-review - ревью кода по правилам проекта

/unikit-verify - ревью результата по целям плана

/unikit-fix - исправление ошибок из ревью и генерация патчей

/unikit-evolve - превращение накопленных патчей в постоянные правила

/unikit-commit - автоматическое создание коммита

/unikit-roadmap - разбивка большого ГД-документа на модули

Это похоже на spec-kit, но короче и проще. Обнаружил проблему на этапе implement - не обязательно переделывать всю цепочку документов. Можно переработать только план через /unikit-improve или вернуться к исследованию, поправить его и пересобрать план.

Допустим, нужен контроллер персонажа. Запускаем скилл:

/unikit-explore требуется создать простой контроллер персонажа - ходьба, прыжок, приседание. А так же бег с использованием стамины

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

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

Когда исследование готово, сохраняем его и запускаем:

/unikit-plan создай план по последнему исследованию

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

Дело в природе LLM. Чем крупнее задача, тем сложнее модели написать по ней детализированный план. Она всегда будет упрощать и стараться сделать всё малой кровью. Отсюда простое правило: большие задачи дробим на маленькие. Нельзя просить сразу "сделать всю игру" - разбиваем на логические модули, модули на подмодули и так далее.

Кстати, если есть здоровенный ГД-документ, для разбивки можно использовать скилл /unikit-roadmap.

Но даже после всех разбиений задача "написать продвинутый контроллер персонажа" для LLM всё равно слишком крупная. С одного промта нормальный контроллер не получится, даже если скормить агенту реальный код крутого контроллера для примера - модель где-то упростит, где-то упустит деталь.

Решений два, и их надо применять вместе:

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

Второе - /unikit-improve, причём запускать его минимум 2-3 раза. Скилл заново читает все правила проекта, фреймворков и модулей, перечитывает исследование, анализирует текущий код и ищет проблемные точки в плане и недостающие задачи. На выходе даёт список найденных проблем с возможностью применить их все или выбрать из списка.

Зачем запускать несколько раз? После первого улучшения план меняется - и при повторной проверке скилл смотрит на него под новым углом и находит ещё что-то. Плюс агент никогда не смотрит прям на все свои правила. В каких то запусках он посмотрит на одни правила, потом на другие. Довести план до идеала, где агент совсем ничего не найдёт, практически нереально. Но три прогона обычно достаточно, чтобы план стал пригоден к реальному исполнению. И иногда делаю 5-7 прогонов.

Запуск плана на исполнение:

/unikit-implement выполни Фаза 1-3

Можно указать конкретные фазы, можно весь план сразу. Если в проекте подключён MCP-сервер движка, агент во время работы будет сам читать логи компиляции, ловить ошибки и править свои же решения на лету. Это избавляет от ручного цикла "агент написал - ты запустил - принёс логи обратно".

И ещё одна вещь, которую я полюбил сильнее, чем ожидал, - автокоммиты. Планировщик предусматривает чекпоинты между фазами. После каждой фазы агент спрашивает: идти дальше или сначала закоммитить? Если коммитим, запускается /unikit-commit - агент сам группирует изменения по логическим блокам и пишет к ним сообщение. Я практически перестал лазить в различные GUI-клиенты для git, 90% коммитов за меня делает агент, причём описывает изменения точнее, чем я бы делал сам на спешке. Прям кайфую от этой автоматизации.

Отдельно про тесты. В AI-разработке без тестов вообще никак - вероятность сломать существующую логику при добавлении нового функционала через агента очень высокая И тесты - это один из ключевых инструментов возврата контроля разработчику над проектом.

/unikit-plan знает про пайплайн тестирования для каждого из трёх поддерживаемых движков. При создании плана он всегда спросит: покрывать функционал тестами или нет. 

Дальше через MCP-сервер движка агент сам эти тесты запускает во время выполнения плана, проверяет их. И при добавлении нового функционала гоняет вообще все тесты, чтобы убедиться, что не сломал ничего из старого.

После выполнения плана запускаем:

Скилл проходит по созданному коду и проверяет его на соответствие правилам проекта и исходному плану.

Если что-то нашёл - фиксим:

/unikit-fix исправь проблемы из текущей сессии

Тут начинается магия. Кроме собственно исправлений в коде, /unikit-fix создаёт файл патча с описанием проблемы и её решения. Эти патчи - топливо для самообучения системы. Другие скиллы при написании планов и их выполнении автоматически подхватывают последние 10 патчей и учитывают их в работе. Это означает, что одну и ту же ошибку агент в идеале совершает один раз. Но это в идеале. На практике агент никогда не следует правилам на 100%, и именно поэтому /unikit-improve и /unikit-review остаются обязательными этапами пайплайна.

Когда накопилось больше 10 патчей, имеет смысл запустить:

Скилл превратит накопленные патчи в полноценные правила и добавит их в правила проекта в файл .unikit/RULES.md.

Иногда не хочется ждать, пока агент наступит на грабли, чтобы /unikit-evolve создал новое правило.

Проще сразу записать его руками.

Новое правило можно сохранить так:

/unikit-rules если делается подписка на события или реактивные свойства, то ВСЕГДА должна быть отписка. Для MonoBehaviour подписки/отписки лучше делать в OnEnable/OnDisable или Awake/OnDestroy. А в чистых классах - через конструктор + IDisposable или Initialize()/IDisposable

Правило запишется в .unikit/RULES.md и будет учитываться фреймворком во всех его циклах работы. /unikit-evolve пишет правила в тот же файл, просто на основе патчей из фиксов. Так же скилл проверяет новое правило на пересечения и противоречия с другими правилами. И если они есть, то предлагает варианты решения таких коллизий.

На первых порах советую внимательно читать код, который пишет агент. У UniKit AI есть своя база правил, но на старте она не идеальна и требует доработки под ваш стиль. Архитектурные косяки, ошибки производительности, банальный говнокод - всё это нужно ловить на первых этапах руками и конвертировать либо в патчи (через /unikit-fix), либо напрямую в правила (через /unikit-rules). С каждой итерацией агент будет работать лучше именно на вашем проекте.

После всего этого финальный коммит через /unikit-commit - и едем к следующей фиче.

В следующем посте разберём одну из самых нетривиальных частей фреймворка - динамическую память правил.

Расскажу, как устроена индексная подгрузка (почему правила НЕ грузятся все скопом, как в классическом CLAUDE.md), чем core-правила отличаются от stack-правил, как работает удалённый регистр на GitHub и как переносить свою базу знаний между проектами.