Loadouts в AIM: свой набор навыков для каждой задачи

В моём инвентаре есть навыки, которые нужны почти везде: commit-message помогает писать сообщения коммитов, write-as-alexey — тексты в моём стиле. Рядом лежат специализированные: daily-dashboard-report и write-spec для работы, release-news и editorial-partner для домашних пет-проектов.

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

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

Один инвентарь, два набора

Для моего случая достаточно двух loadouts:

Работа — не волк, а work	Пет-проекты — pet-projects
commit-message	commit-message
write-as-alexey	write-as-alexey
daily-dashboard-report	release-news
write-spec	editorial-partner

Общие навыки входят в оба набора. Дублировать их файлы не нужно: loadout содержит ссылки на элементы инвентаря. Если изменить commit-message, оба набора будут ссылаться на обновлённый навык.

Рабочий набор можно описать в файле loadouts/work.yaml:

name: work
description: Общие навыки и инструменты для рабочих задач
items:
  - skill:commit-message
  - skill:write-as-alexey
  - skill:daily-dashboard-report
  - skill:write-spec

По тому же принципу в loadouts/pet-projects.yaml описывается домашний набор. Навыки, на которые ссылаются эти файлы, должны уже находиться в инвентаре. В наборы можно включать и MCP-серверы; здесь для наглядности я ограничусь навыками.

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

Что именно закрепляет --pin

На рабочем компьютере я могу применить и закрепить рабочий набор:

aiman apply --loadout work --pin

На домашнем — набор для пет-проектов:

aiman apply --loadout pet-projects --pin

Каждая команда делает две вещи: применяет выбранный набор в локальные AI-среды и запоминает его для следующих запусков sync. Пин хранится локально у пользователя и не передаётся через Git. Рабочая машина не перепишет домашний выбор при синхронизации.

При этом aiman sync продолжает получать весь инвентарь. Пин определяет, какая его часть будет применена в среды. Поэтому дома у меня остаются файлы рабочих навыков, даже если агенту сейчас доступен набор для пет-проектов.

Например, дома я могу поправить daily-dashboard-report прямо в инвентаре и опубликовать изменение через aiman push. Рабочая машина получит его при следующем sync и обновит навык в своих средах. Домашний sync тоже получит изменённый файл, но устанавливать рабочий навык в среды не будет: он не входит в домашний loadout.

Пин фиксирует выбор набора. Содержимое навыков и состав самого loadout при этом могут обновляться через Git.

Как набор освобождает место для другой задачи

Чтобы переключение имело смысл, недостаточно просто добавить навыки нового набора. Иначе после перехода с работы на пет-проекты в среде останутся и рабочий отчёт, и постановка задач, и редакторские инструменты.

Поэтому при применении loadout AIM устанавливает нужные элементы и удаляет из сред те, которые есть в инвентаре, но не входят в выбранный набор. В нашем примере commit-message и write-as-alexey остаются. Рабочие daily-dashboard-report и write-spec уступают место release-news и editorial-partner. Сами файлы в инвентаре сохраняются.

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

Перед переключением можно посмотреть план:

aiman apply --loadout work --dry-run

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

Срочная рабочая задача из дома

Допустим, дома закреплён pet-projects, но вечером понадобилось заняться рабочей задачей. Для временного перехода достаточно:

aiman apply --loadout work

Без --pin команда применит рабочий набор один раз и сохранит прежний домашний пин. После перехода в сессию с обновлёнными навыками можно заняться задачей. Закончив, я верну домашний набор:

aiman apply --loadout pet-projects

Здесь важно помнить о синхронизации: если во время временного перехода выполнить aiman sync, он применит закреплённый pet-projects. Когда рабочий режим нужен надолго и должен переживать синхронизации, его можно временно закрепить через --pin, а после работы снова закрепить домашний набор.

Для сохранения узкого набора при локальных проверках тоже нужно явно указывать --loadout. Обычный aiman apply применяет весь инвентарь, даже если пин установлен.

Та же логика подходит для разных классов задач на одной машине. Можно завести набор для дизайна и другой — для написания сценариев, включив общие навыки в оба. При смене задачи выбирается подходящий loadout; если этот выбор должен сохраняться при sync, он закрепляется. Сейчас такое переключение действует на глобальные конфигурации выбранных AI-сред пользователя: отдельного набора для каждой одновременно открытой проектной сессии оно не создаёт.

Сможет ли агент переключаться сам

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

Но здесь пока остаются две разные проблемы. Первая — определить фактическое состояние. Сегодня aiman status показывает поле Pinned loadout, то есть закреплённый набор. После временного apply --loadout work оно по-прежнему может показывать pet-projects. Кроме того, пин ничего не доказывает о навыках, уже прочитанных работающей сессией. Для автоматического выбора понадобится отдельно учитывать, какой набор действительно применён и с каким набором запущен агент.

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

Возможны несколько направлений; это варианты для исследования, а не готовые возможности AIM.

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

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

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

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