Как устроен AIM Loadout. Часть 1: откуда взялся инвентарь

Я пишу код с несколькими AI-инструментами: Claude Code в терминале, Cursor в редакторе, иногда Codex CLI в скриптах. Дальше я буду называть их AI-средами. В каждой из них можно использовать навыки — инструкции для агента, записанные в Markdown. Через них я объясняю, как выполнять знакомые мне задачи.

Допустим, я написал навык и установил его в Claude Code. Чтобы пользоваться им в Cursor, нужно перенести его туда. Для Codex CLI нужна ещё одна копия. Пока инструкция не меняется, это разовая работа. Но стоит уточнить формулировку или добавить пример — обновить придётся каждую копию.

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

Одно место для правок

Мне хотелось редактировать навык один раз и затем передавать результат во все нужные среды. Для этого требовалось общее место хранения: отсюда берётся актуальная версия, здесь же она меняется. Я назвал его инвентарём.

Сначала появилась простая реализация на bash. Скрипт читал конфиг с путями к AI-средам и копировал навыки из папки skills/ по этим адресам. Основную работу делали два вложенных цикла:

for skill_file in "${SKILLS_DIR}"/*.md; do
  for target_path in "${TARGET_PATHS[@]}"; do
    cp "${skill_file}" "${target_path}/$(basename "${skill_file}")"
  done
done

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

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

Мне подошла метафора снаряжения: навыки — то, что разработчик собирает под свои задачи и берёт с собой в работу. Так появилась связь с названием Loadout. Инвентарь принадлежит разработчику; выбор очередного инструмента не должен заставлять его собирать свой набор заново.

Что меняется, когда машин две

Скрипт помогал поддерживать несколько сред на одном компьютере. Но рабочая машина и домашняя — уже два отдельных места хранения. Если поправить навык на одной, на другой останется старая версия. А при настройке нового компьютера весь набор нужно откуда-то получить.

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

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

Схема работы получилась такой: на одном компьютере я меняю навык и публикую готовую версию в удалённый репозиторий. На другом — получаю опубликованные изменения и применяю их в установленные там AI-среды. Набор сред может различаться: например, на рабочей машине есть Claude Code и Cursor, а на домашней — только Claude Code.

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

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

Проверить навык до публикации

Синхронизация была главной операцией ещё в bash-скрипте: взять содержимое инвентаря и разложить по средам. В схеме с Git команда aiman sync также получает опубликованное состояние из удалённого репозитория. На другой машине это позволяет забрать готовые изменения и сразу применить их локально.

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

Поэтому позже появилась отдельная команда aiman apply. Она применяет текущее содержимое локального инвентаря без операций с Git. Можно править файл, запускать apply и проверять результат в AI-среде столько раз, сколько нужно. Чтобы среда подхватила обновлённый навык, может потребоваться новая сессия агента.

Когда навык готов, aiman push проверяет инвентарь, создаёт коммит и отправляет изменения в удалённый репозиторий. После этого на другой машине можно выполнить aiman sync и получить опубликованную версию.

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

Откуда взять первый набор

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

Когда я впервые запустил aiman init с пустым репозиторием, именно это и сбило меня с толку. Инвентарь остался пустым, хотя навыки в Claude Code и Cursor были на месте. AIM подготовил хранилище, но не собрал в него существующий набор.

Почему автоматический сбор при init оказался спорной идеей и как дать пользователю перенести свои навыки под собственным контролем — об этом во второй части.