kit

Маркетплейс плагинов Claude Code и инструмент профиля.

Плагин везёт возможности — скилы, агентов, хуки, MCP-серверы, — но не может везти настройки: ни permissions, ни env, ни model. Поэтому рядом с плагинами живёт слой — именованный набор «плагины плюс настройки», который человек включает себе поимённо. Двое в одном репозитории получают разное: у одного cluster включён и права kubectl есть, у второго нет ни плагина, ни прав, ни трат контекста на них.

Слои описываются в двух файлах, а kit apply раскладывает их по штатным файлам настроек Claude Code:

Вход	Выход
.claude/kit.json — общий, коммитится	.claude/settings.json — коммитится
.claude/kit.local.json — личный, gitignored	.claude/settings.local.json — gitignored

settings.local.json kit не перезаписывает целиком: он владеет своими ключами в нём, а решения «разрешить всегда» и прочие чужие правки переживают применение.

Дефолты ядра

Ядро кладёт в settings.json дефолты — решения о том, как по умолчанию устроен репозиторий с kit. Себя оно там больше не объявляет: enabledPlugins целиком пишет claude plugin install, и kit к этому ключу не притрагивается — подробности в docs/superpowers/specs/2026-08-27-plugin-reconciliation-design.md. Дефолты сливаются первыми, поэтому перебиваются чем угодно: настройками репозитория в kit.json, слоем, личным файлом. Дефолт — предложение, а не запрет.

Ключ	Значение	Почему
autoMemoryEnabled	false	Встроенная файловая память Claude Code выключена: она копит записки в ~/.claude/projects/<репозиторий>/memory сама, а память у нас будет своя. Уже написанное не удаляется — просто перестаёт читаться и пополняться. Вернуть себе: "autoMemoryEnabled": true в settings своего kit.json или в личном kit.local.json.
language	"Russian"	Claude отвечает по-русски: ключ разворачивается в секцию # Language системного промпта. Значение — английское имя языка, а не «Русский» и не «ru»: именно так его нормализует и записывает /config, туда же смотрит английская фраза промпта. Вернуть себе английский: "language": null в settings своего kit.json или в личном kit.local.json — null удаляет ключ, и настройки выходят вообще без языка. "default" не сработает: строка непустая, и в промпт уйдёт «Always respond in default».

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

Ключ language выбирает язык, но не отвечает за то, как на нём говорят. Помощник довольно быстро сбивается на конспект вместо речи: вместо предложений идут ярлыки, вместо союзов тире, а мысль рассыпается на обрубки, которые приходится разбирать. Когда читать это станет невозможно, зовите /kit:nem. Она возвращает речь к обычным человеческим фразам и держит их до конца сессии.

След сессий

Kit собирает транскрипты сессий Claude Code и доставляет их до хранилища следа на адресе trace.co.rolder.dev. Сбор идёт в отцепленном процессе, который поднимает хук старта сессии, и работает независимо от вас — вы его не видите и не ждёте.

Собираются только сессии репозиториев, чей origin ведёт на кузню git.rolder.cloud. Всё остальное на машине не трогается вовсе: в личных файлах, в чужих репозиториях и на чужих серверах след не собирается.

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

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

Посмотреть, как идёт сбор, можно командой kit trace. Она печатает состояние демона сбора, когда он работает, и последний проход — когда лежит. Один проход руками делает kit trace --once.

Сервер кузни

Слой forge из каталога рецептов умеет объявлять MCP-сервер кузни — тогда в этом репозитории помощник получает вызовы mcp__forgejo__*: задачи, PR, workflows, пакеты и релизы. Включается он, как любой слой из каталога, именем — kit on forge себе, kit declare forge --project всем в репозитории, — а не записью тела в kit.json.

Своему слою, которого в каталоге нет, тот же MCP-сервер объявляется телом прямо в kit.json:

"layers": {
  "мой-слой": { "mcp": { "forgejo": true } }
}

kit apply разворачивает это не в файл, а в команду claude mcp add --scope local: объявление несёт машинный путь к ядру, а .mcp.json репозитория коммитится — там такому пути не место. Сам сервер (gitea-mcp) приезжает запускателем по core/tool/binaries.json и кэшируется рядом с входом; токен кузни живёт только в окружении его процесса. Устройство — в docs/superpowers/specs/2026-08-28-forge-mcp-design.md.

Тем же слоем приезжают скилы кузни: forge:plan — словарь Плана, что такое задача и крупная задача и где они лежат; forge:task — цикл одной задачи от взятия до закрытия; forge:release — выпуск версии: срез от прошлого тега, секции по читателям, тег и release-объект; forge:feedback — сигнал о самом рабочем месте. Скилы написаны по провалам живых прогонов, а не переносом текста — устройство и мерки в docs/superpowers/specs/2026-08-28-forge-plan-design.md.

Установка

На голой машине — один однострочник. Он ставит git, bun, Claude Code, ядро kit, где может — Desktop, и последним шагом заводит доступ к кузне:

curl -fsSL https://git.rolder.cloud/forge-public/kit/raw/branch/main/bootstrap/bootstrap.sh | sh

Без curl — тем же адресом через wget -qO-:

wget -qO- https://git.rolder.cloud/forge-public/kit/raw/branch/main/bootstrap/bootstrap.sh | sh

На Windows — из PowerShell, но обязательно дочерним процессом:

powershell -NoProfile -Command "iex (iwr -UseBasicParsing https://git.rolder.cloud/forge-public/kit/raw/branch/main/bootstrap/bootstrap.ps1).Content"

Голый irm … | iex исполняет шим в текущей сессии, и exit в конце шима закрывает её вместе с докладом — человек теряет окно ровно тогда, когда в нём появилось, что читать. Дочерний процесс делает exit безобидным, как | sh на Linux; той же формой пользуется и официальная документация bun.

Дальше руками: открыть Claude Desktop — он сам проведёт вход, — открыть свой репозиторий и сказать /kit:setup. Там, где Desktop поставить нельзя (Windows, macOS), доклад даст ссылку на страницу загрузки; там, где его не бывает вовсе (прочий Linux, сервер по SSH), остаётся консольный claude со входом в браузере. Больше ручного ничего нет.

Живьём проверены Linux (пять дистрибутивов: Debian, Ubuntu, Fedora, Alpine, Arch) и Windows 10. macOS не прогонялся ни разу — ни машины, ни докера. Что именно не проверено и почему — в разделе «Не проверено» спеки бутстрапа.

На Debian и Ubuntu установка Desktop сама подключает к системе сторонний репозиторий пакетов Anthropic и его ключ подписи — подробности и что именно подключается см. в спеке бутстрапа.

Однострочник прогнан целиком с боевого зеркала на чистом debian:12 — 2026-08-26, код возврата 0: порог доставил unzip, встали bun, git 2.39.5, Claude Code 2.1.246, ядро kit и Desktop.

Устройство бутстрапа — bootstrap/README.md и docs/superpowers/specs/2026-08-25-machine-bootstrap-design.md.

Вызов

В сессии Claude Code инструмент зовётся одним словом: ядро везёт шим в bin/, а Claude Code подмешивает bin каждого включённого плагина в PATH своего Bash-тула.

kit <команда>

Что делает команда, она рассказывает сама: kit <команда> --help печатает её форму вызова и одну фразу о деле, а kit --help — весь список. Справка только печатает и не трогает ни файлов, ни сети, поэтому спросить её безопасно и до первого настоящего вызова.

И в терминале. Ядро кладёт второй шим в ~/.local/bin/kit (на Windows — kit.cmd в %USERPROFILE%\.local\bin, и каталог дописывается в PATH пользователя). Его ставит бутстрап и обновляет каждый kit apply. Этот шим лежит вне тела плагина и потому находит тело сам — через реестр установок Claude Code, при каждом вызове.

Не работает короткая форма только в хуках: их запускает сам Claude Code, минуя шелл. Там форма длинная — инструмент едет исходником вместе с ядром и запускается bun:

bun ${CLAUDE_PLUGIN_ROOT}/tool/src/cli.ts <команда>

Шимов теперь два, и оба проверены живьём. Сессионный (core/bin/kit) отвечает в Bash-туле сессии, открытой на свежем теле. Терминальный (tool/src/shim) — цепочка «шим находит резолвер, резолвер читает реестр установок и динамическим импортом зовёт найденное тело» — прогнан и автоматическим тестом целиком, и руками: на Linux после kit apply, на Windows 10 после kit shim, где заодно подтвердилась запись каталога в PATH пользователя и работа kit.cmd в новом терминале (2026-08-28). Не нашлась короткая форма — работает длинная.

Тем же путём в PATH Bash-тула попадает и вторая команда — graf, инструмент описания системы из плагина dev (plugins/dev/bin/graf). Действует то же ограничение: только в шелле Bash-тула, ни в хуках, ни в собственном терминале человека этой команды нет.

Команда	Что делает
init	Заводит kit.json и kit.local.json, перенося рукописные настройки
apply	Ставит и снимает плагины по профилю, пишет settings.json, settings.local.json, kit.lock.json, блоки в .gitignore и .gitattributes; для слоя с ключом npm ещё кладёт блок скоупов в .npmrc и ставит недостающие пакеты командой bun add -d
check	То же вычисление, ничего не меняет; расходится ли профиль с настройками и с машиной — в том числе если плагин стоит, но в настройках выключен, или ядро стоит у самой папки, а не только в области user
update	Спрашивает зеркало, какой ревизии тела плагинов стоят на машине, и обновляет отставшие; --check только докладывает, ничего не трогая
shim	Кладёт (или обновляет) терминальный шим — ~/.local/bin/kit, на Windows kit.cmd — и на Windows же дописывает его каталог в PATH; то же самое попутно делает apply
declare <слой> [--project]	Убирает из kit.json запись слоя, оставшуюся от прежних выпусков, и применяет; с --project — ещё и включает слой всем в репозитории
on <слой>	Включает слой себе и применяет
off <слой>	Выключает слой себе и применяет
status	Какие слои включены, что каждый дал и что сейчас на диске
schema	Описание формата kit.json: ключи, типы, порядок применения
recipes	Какие слои бывают, кому какой нужен и что каждый даёт — плагины, MCP-серверы, настройки
app	Поднимает сервер приложений kit; зовёт его десктоп, а не человек
forge login	Заводит доступ к кузне: вход в Keycloak, пропуск хранилища, git-конфиг
forge run -- <команда>	Запускает команду с токеном кузни в окружении
forge mcp	Запускает MCP-сервер кузни с токеном в окружении; зовёт его Claude Code, не человек
forge plan	Показывает План кузни: крупные задачи, отдельные, долг и взятое тобой

Коды возврата: 0 — сделано, 1 — конфликт, устаревший профиль или ошибка во входных файлах, 2 — команда не разобрана.

Ядро само ставит на событие SessionStart один хук — session start --hook, — и он делает одним процессом пять проверок: профиль, доступ к кузне, свежесть тел, сбор следа и память. Сказанное ими едет одной запиской. Настроек ни одна из пяти не применяет: они только докладывают. Правит по-прежнему человек или сессия за него. Плана словами среди них больше нет, а проверка кузни в кузнином репозитории говорит сессии, когда показать доску: если человек спросил, что в плане, или просто поздоровался и дела не назвал.

Хук стоит с матчером startup|clear|compact — на возобновлении сессии он не работает вовсе. Записок там и правда не нужно: всё сказанное уже в контексте. Но вместе с ними на возобновлении не поднимается и демон сбора следа, который поднимает проверка следа. Обычно его уже поднял свежий старт; после перезагрузки машины, если первой пошла возобновлённая сессия, сбор постоит до следующего свежего старта.

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

В Claude Code Desktop план показывается доской. Рисует её инструмент mcp__kit__plan сервера kit — объявление этого сервера ставит слой forge, руками в конфиг десктопа лезть не нужно. Просить доску дословно не надо: сессия показывает её сама, когда её спрашивают о плане или просто здороваются. На доске крупные с прогрессом, отдельные задачи, долг и взятое тобой с пометками живости; у свободной задачи кнопка «Взять», у своего или остывшего дерева — «Продолжить», у крупной без задач — «Нарезать», и у всего ссылка в кузню. Кнопка шлёт команду в чат теми же словами, какими её сказал бы человек. В терминале план по-прежнему можно увидеть текстом — командой kit forge plan. После первого kit apply десктоп надо перезапустить.

Настройка разговором

/kit:setup — проводник настройки: скил ядра, который доводит репозиторий до рабочего состояния разговором. Ни kit.json, ни kit.local.json человек при этом не открывает.

Ситуаций две, и выбор между ними решает наличие .claude/kit.json. Профиля нет — проводник заводит его командой kit init, которая заодно переносит в профиль настройки, написанные в settings.json руками; список слоёв он берёт из kit recipes и называет их человеческими фразами, а не содержимым. Профиль есть — проводник читает kit status и предлагает включить то, что объявлено, но выключено.

По каждому слою проводник спрашивает, кому его подключить, и это не вежливость. Команда kit declare <слой> --project ставит имя слоя в список project в kit.json, а этот файл коммитится: слой получит каждый, кто работает в репозитории. Вариант «себе» — kit on <слой> — никого другого не затрагивает. Если человек торопит и просит ничего не спрашивать, вопрос всё равно задаётся, одной формой на все слои сразу; слои подключаются человеку одному только тогда, когда он отвечать отказался.

Убирать оставшуюся в kit.json запись слоя командой kit declare <слой> можно только после того, как kit обновлён у всех, кто работает в репозитории: версия старее этой видит в project имя слоя без записи в layers и отказывает «неизвестный слой».

Проводник не правит settings.json и settings.local.json: эти файлы создаёт kit apply, и написанное в них руками пропадает при следующем запуске. Доступ к кузне он тоже не заводит и плагины не обновляет — это делают команды /kit:login и /kit:update. В конце разговора он предупреждает: плагины установлены, но их скилы появятся только в новой сессии, а текущая продолжит работать со старым набором.

Про проводника не обязательно знать заранее. Если kit.json в репозитории есть, а не включено ни одного слоя — ни всем в project, ни лично в on, — хук старта сессии сам спрашивает, настроить ли сейчас. Такой репозиторий kit ничем не снабжает, и молчать о нём значит оставить установленный kit стоять вхолостую. Появился слой хоть с одной стороны — записка пропадает. Там, где профиля нет вовсе, хук молчит: ядро стоит на всю машину, и чужой репозиторий от своего по отсутствию kit.json не отличить.

Проводник пройден живьём 2026-08-30 на двух рабочих репозиториях — пустом и уже с профилем. Обе ситуации закрылись разговором: ни kit.json, ни kit.local.json человек не открывал, слои объявлены командами, коммиты ушли в репозитории. Там же нашлась граница: в репозитории, чей .claude/settings.json порождает nix и лежит симлинком в /nix/store, kit init профиль заводит, а kit apply в этот файл писать не может.

Текст скила написан дисциплиной письма скилов — сперва прогоны без неё, потом текст под найденные провалы. Числа заходов, доклад живого прогона и стенд — core/tool/tests/давление/настройка-репозитория.md, устройство — docs/superpowers/specs/2026-08-30-проводник-настройки-design.md.

Доступ к кузне

Один раз на машине — /kit:login: человек подтверждает вход в браузере, и дальше git push в git.rolder.cloud, авторство коммитов и инструменты кузни работают сами. Тело доступа на диск не ложится: git credential helper читает его из хранилища на каждый вызов. В репозиториях, не относящихся к кузне, kit не проявляется никак — конфиг подключается включением по условию, по ссылке ремоута.

Ключи проекта

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

Ключи объявляются в secretspec.toml, в таблице [profiles.default]. Форма файла задана чужим инструментом и не выбирается: манифест грузит настоящий бинарь secretspec — тот же, что читает кластер, когда собирает ExternalSecret, — а свой разбор этого файла kit не ведёт вовсе. Оттого форма строже, чем кажется на вид, и часть требований держит не кластер, а сам бинарь при загрузке манифеста:

• в [project] обязана стоять строка revision — без неё манифест не грузится вовсе;
• у каждого ключа обязано быть поле description — тем же порядком, без него манифест тоже не грузится;
• на каждый профиль, который назовут --profile, в манифесте нужна своя секция, пусть и пустая. Это касается и development, которым живёт локальный запуск: профиль, унаследованный от default, бинарь профилем не считает;
• имена ключей — только ASCII: они становятся именами переменных окружения дочернего процесса.

Манифест, который бинарь действительно грузит, выглядит так:

[project]
name = "shop-api"
revision = "1.0"

[profiles.default]
DATABASE_URL = { description = "строка подключения к базе" }

[profiles.development]

Работа делится надвое, и черта проходит по значению. Имена и схему пишет помощник — они секретными данными не являются. Значение кладёт человек своей рукой:

kit secrets set DATABASE_URL --profile development

Команда спросит значение скрытым вводом. Аргументом командной строки она его не примет вовсе, потому что аргумент виден в списке процессов, в истории оболочки и в контексте сессии.

Профилей два, и это то место, где спотыкаются чаще всего. Локальный запуск читает development, кластер читает prod, так что одно и то же значение кладётся дважды. Таблица [profiles.default] профилем значений не является: она служит только объявлению, и положенное в профиль default не прочитает никто.

Дальше приложение поднимается с ключами в окружении:

kit secrets run -- bun run dev

Прежде чем поднимать, kit secrets check называет разом все ключи, которых не хватает, — не дожидаясь, пока run упадёт на первом же.

Ключ, ставший ненужным, снимается из хранилища:

kit secrets delete DATABASE_URL --profile development

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

Что происходит с ключами, показывает kit secrets status: какие объявлены, в каких профилях лежат значения и что с ними в кластере — состояние ExternalSecret вместе с профилем, из которого он тянет ключ. Расхождение между тем, где значение лежит, и тем, откуда его ждут, команда называет прямо. Значений она не читает вовсе: наполненность видна по пути метаданных хранилища, и увидеть само значение эта команда не может физически.

Дорогу от «приложению нужен ключ» до «ключ у процесса» ведёт скил kit:secrets. Что он говорит и о чём молчит, записано по провалам прогонов без него: стенд и числа заходов лежат в core/tool/tests/давление/ключи-проекта.md, устройство — docs/superpowers/specs/2026-09-03-ключи-проекта-design.md.

Слой dev

Скилы разработчика — дисциплина брейншторма, планов, TDD, отладки и ревью. Слой включают двумя способами: себе — тогда он ляжет в личный settings.local.json и соседа не затронет,

kit on dev

или всему репозиторию — тогда он приезжает каждому, кто здесь работает:

kit declare dev --project

В самом kit слой включён всем: этот репозиторий пишут, и набор нужен тут любому.

Слой из каталога (kit recipes) включается по имени, а не записью в файле: kit on dev — себе, kit declare dev --project — всем. Тело слоя даёт рецепт, руками kit.json для этого открывать не нужно, а правка рецепта в новой версии kit доезжает сама, следующим kit apply, без повторного включения.

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

Внутри — тринадцать скилов, зовутся dev:brainstorming, dev:test-driven-development, dev:systematic-debugging и так далее. Плагин ставит свой хук на SessionStart: он вкладывает dev:using-superpowers целиком в контекст, иначе набор молчит — правило «сначала проверь, есть ли подходящий скил» обязано быть прочитано до первого ответа. У кого слой не включён, хука нет вовсе.

Содержимое перенесено из Superpowers Jesse Vincent (MIT, лицензия рядом — plugins/dev/LICENSE). Формулировки скилов не тронуты; правок ровно два вида. Первая — ссылки скилов друг на друга, superpowers: → dev:. Вторая — вырезаны куски про чужие харнессы, их четыре: раздел «Platform Adaptation» в using-superpowers, пути к личным скилам в скиле письма, перечень харнессов с субагентами в executing-plans, три рецепта запуска сервера в visual-companion. Вместе с ними ушли пять файлов references/*-tools.md, каталоги Codex, Cursor, Devin, Gemini, Hermes, Kimi, opencode и Pi, их CI и релизная обвязка. У нас сугубо Claude Code.

В плагине теперь живёт и своё — граница между перенесённым и своим проходит по именам скилов, и её стережёт core/tool/tests/dev.test.ts двумя поимёнными списками: ПЕРЕНОС ловит недостачу в переносе, СВОИ — лишнее в плагине.

Своё — модель и метод акта описания системы, модель.md и метод.md в model/, инструмент, который эту модель реализует, — команда graf (tool/, bin/graf), и два скила. Кроме четырнадцати перенесённых скилов Superpowers плагин везёт dev:concept и dev:construct — они ведут описание системы в графе проект/ по Модели, которая лежит рядом, в plugins/dev/model: dev:concept наполняет слой Концепт, dev:construct — слой Конструкция.

Слой cloud

Доставка проекта в облако Rolder и разбор того, что там упало. Слой везёт два скила. Первый, cloud:deploy, отвечает на «разверни»: помощник сам проходит всю дорогу от декларации cloud.yaml до итога прогона выкатки. Поля декларации он каждый раз читает у инструмента облака, проверяет написанное командой check до пуша, пушит в ветку deploy/* и дочитывает прогон workflow через сервер кузни, а не отправляет человека во вкладку Actions.

Инструмент облака, пакет @rolder/cloud, живёт в npm-реестре кузни. Звать его по имени пакета ненадёжно: скоуп реестра bun x читает только из ~/.npmrc домашнего каталога, да и то не всякой сборкой: bunx на машине может оказаться отстающим bun, который уходит на npmjs, где пакета нет. Поэтому слой несёт ключ npm, и kit apply по нему один раз на репозиторий кладёт строку скоупа @rolder блоком в .npmrc и ставит пакет в devDependencies командой bun add -d. Оба файла коммитятся, и дальше инструмент зовётся локальным именем bunx cloud. Скил об этом устройстве не знает: если пакета в package.json нет, check и хук старта сессии скажут об этом так же, как о любом другом расхождении. Тем же слоем объявляется сервер кузни, он нужен, чтобы читать прогоны.

Второй скил, cloud:diagnose, отвечает на «упало, разберись»: он ведёт от решения облака о поде — оно лежит событием в хранилище логов — к предсмертным строкам приложения и к числам, которыми эта причина меряется. Числа даёт команда kit cloud metrics: она берёт запрос на PromQL и сама знает дорогу к хранилищу рядов через сервер облака, выбор быстрого и глубокого хранилища и шаг, с которым каждое из них пишет.

Что оба скила делают и чего не делают, записано по провалам прогонов без них: стенды и числа заходов лежат в core/tool/tests/давление/выкатка-проекта.md и core/tool/tests/давление/разбор-упавшего.md. Разбор оказался тем редким случаем, где ремесло модель держит сама: без скила прогоны доходили до улики на обеих моделях. Не держится знание об устройстве самого слоя — два языка запросов у двух его команд и глубина двух хранилищ рядов, — и текст скила написан ровно под это.

Устройство репозитория

.claude-plugin/marketplace.json   каталог: ядро и предметные плагины
cloud.yaml                        декларация облака: сервер следа и его база, память и её база, разворачивает слой cloud
secretspec.toml                   объявление ключей сервера следа и памяти — имена, без значений
core/                             плагин kit — ядро, обязателен
  bin/kit                         команда «kit» в сессии — шим на bun
  tool/src/shim/                  вторая дорога: шим на PATH машины и резолвер
  commands/                       слэш-команды: /kit:login, /kit:update и /kit:nem
  hooks/hooks.json                проверка свежести профиля
  tool/                           инструмент: исходник, тесты
plugins/dev/                      плагин dev — скилы разработчика, включается слоем
  bin/graf                        команда «graf» в сессии — шим на bun
  model/                          Модель и метод: язык, форма, ходы акта
  tool/                           инструмент описания: исходник, тесты, графы
plugins/forge/                    плагин forge — скил Плана кузни, включается слоем
plugins/cloud/                    плагин cloud — скилы доставки в облако и разбора упавшего, включается слоем
trace/                            приёмник следа и накатка его схемы, объявлены в cloud.yaml
memory/                           накатка памяти (sibyl), объявлена в cloud.yaml
cloud.d/                          сырые манифесты выкатки самого kit
bootstrap/                        бутстрап машины — не часть плагина, см. bootstrap/README.md
docs/superpowers/specs/           спеки доставки и бутстрапа — что и почему устроено так
.forgejo/                         ворота и список состава зеркала

Последние два в зеркало не уезжают: там только тела и бутстрап — то, что чужая машина действительно берёт. Кто читает это в forge-public/kit, путей в docs/ у себя не найдёт — спеки живут в источнике.

Тесты и проверка типов инструмента:

cd core/tool && bun test && bunx tsc --noEmit -p tsconfig.json
cd plugins/dev/tool && bun test
cd trace && bun test

Если у инструмента описания краснеет приёмка (tests/acceptance.test.ts) — разошёлся снимок, а не ядро, — смотри plugins/dev/tool/README.md: там же команда, которой снимки переснимаются заново.

Потребляют все — и команда, и внешние — с публичного зеркала git.rolder.cloud/forge-public/kit; пишут авторы в приватный git.rolder.cloud/corolder/kit, откуда снапшот main выкладывает CI.

История выпусков — в CHANGELOG.md. Выпусков здесь пока нет: первым будет v0.8.0, а восемь версий предшественника остались в corolder/devkit.

В зеркало уезжает не весь main, а объявленное в .forgejo/mirror.list: тела, бутстрап, каталог маркетплейса, этот README и changelog. Ворота, спеки и профиль самого репозитория разработки остаются в источнике — в зеркале воротам нечего охранять, и бежали они там впустую и красными. Полноту списка стережёт core/tool/tests/mirror.test.ts: новая запись в корне роняет ворота вопросом «везём или нет», и незамеченной не уезжает и не пропадает ни одна.