← Назад Harupa
2026-06-08RU EN UA BY PL

My Architect, часть 5: дистрибуция через Claude Code marketplace

Это финал серии про My Architect — систему, в которой проект живёт между сессиями AI-агента. В части 1 я объяснял, зачем агенту память и план. Сегодня про последний кусок пазла: как всё это попадает на машину пользователя за две команды.

Проблема последней мили

Со стороны пользователя My Architect — это три вещи. MCP-сервер @my-architect/mcp, который даёт агенту тридцать с лишним инструментов. Skill myarchitect — поведенческие правила: когда агент сам заводит ноду под отложенный баг, а когда останавливается и спрашивает. И четыре slash-команды для типовых сценариев.

Раньше установка выглядела как инструкция на полстраницы. Открой .mcp.json, впиши конфиг сервера, не перепутай имя переменной окружения. Скачай SKILL.md, положи в ~/.claude/skills/, повтори на рабочем ноутбуке. Каждый ручной шаг — место, где человек отваливается, а у меня появляется ещё одна копия skill, которую надо не забыть обновить.

Plugin marketplace в Claude Code закрыл эту дыру. Маркетплейс — это обычный публичный git-репозиторий с manifest-файлом, плагин внутри него — папка с конфигом, skill и командами. Никакой регистрации, никакой модерации, никакого магазина: репо на GitHub и есть канал дистрибуции.

Установка глазами пользователя

Один раз экспортировать токен (берётся в Settings → Connect Agent на сайте):

export MCP_API_KEY=mcp_ВАШ_ТОКЕН

Дальше две команды внутри Claude Code:

/plugin marketplace add d7561985/my-architect-marketplace
/plugin install my-architect@my-architect-marketplace

Проверка — /mcp: сервер my-architect должен значиться подключённым.

За кулисами Claude Code клонирует репозиторий, парсит manifest, регистрирует skill и slash-команды, а при старте сессии поднимает MCP-сервер командой npx -y @my-architect/mcp@latest. Пользователь не редактировал ни одного файла руками. Та самая инструкция на полстраницы ужалась до трёх строк, и сломаться в них почти негде.

Анатомия: два манифеста и markdown

Корневой marketplace.json — тонкая обёртка: имя, владелец, список плагинов со ссылками на папки. Поле $schema указывает на схему с json.schemastore.org, так что редактор подсвечивает ошибки ещё до коммита.

Вся содержательная часть — в plugin.json плагина:

{
  "name": "my-architect",
  "version": "1.4.0",
  "mcpServers": {
    "my-architect": {
      "command": "npx",
      "args": ["-y", "@my-architect/mcp@latest"],
      "env": {
        "MCP_API_KEY": "${MCP_API_KEY}",
        "MA_API_URL": "https://my-architect.app"
      }
    }
  }
}

Здесь важна одна строка: "${MCP_API_KEY}". Это подстановка из shell-окружения пользователя в момент запуска. Репозиторий публичный, и секретам в нём не место — токен живёт у пользователя в ~/.zshrc и никогда не покидает его машину.

Остальное — markdown. SKILL.md с YAML frontmatter (name и description, по которому Claude решает, когда подгружать skill), и commands/*.md — четыре файла, каждый из которых становится slash-командой вроде /my-architect:next. Команды — тонкие промпт-обёртки над skill: «возьми следующую задачу и веди её по Workflow D».

Кода сервера здесь нет

В репозитории маркетплейса нет ни строчки TypeScript. MCP-сервер живёт в приватном продуктовом репо и публикуется в npm, а плагин ссылается на @my-architect/mcp@latest. Вышла новая версия сервера с новыми инструментами — пользователи получают её при следующем запуске Claude Code, вообще без действий со своей стороны и без релиза плагина.

Со skill ситуация обратная, и это осознанное решение. SKILL.md лежит в публичном репо как единственный источник правды. Приватный продуктовый репозиторий копию не держит принципиально: я уже проходил период, когда одна версия skill жила в ~/.claude/skills/ как личная установка, вторая в продукте, и они тихо разъезжались. Теперь правило записано прямо в CLAUDE.md маркетплейса: редактируем здесь, пушим отсюда, пользователи тянут отсюда. Любая найденная копия — устаревшая по определению.

Дисциплина версий

У маркетплейса есть неочевидное следствие: /plugin update my-architect срабатывает только если версия в plugin.json изменилась. Поправил формулировку в SKILL.md и запушил без bump — никто из пользователей этого не увидит, обновление просто не предложится. Поэтому правило жёсткое: каждое видимое изменение — это bump версии плюс запись в CHANGELOG, даже если поменялось одно слово.

Перед публикацией — claude plugin validate .: оба манифеста и frontmatter skill должны распарситься. Релиз закрывается командой claude plugin tag, которая сверяет версию в plugin.json, запись в маркетплейсе и создаваемый git-тег между собой и только потом ставит тег вида my-architect--v1.4.0. Согласованность версий проверяет инструмент, а не моя внимательность, и это правильное распределение обязанностей.

Полтора месяца в changelog

Плагин живёт с конца апреля, и его changelog получился летописью того, как менялось моё понимание работы агента с архитектором:

  1. v1.0.0 (29 апреля) — skill как проактивный трекер бэклога плюс автоконфигурация MCP-сервера.
  2. v1.1.0 (29 мая) — Workflow C: документы на узлах как source of truth, validate_project перед закрытием задачи.
  3. v1.2.0 (5 июня) — Workflow D: архитектор перестал быть журналом постфактум, skill теперь требует читать ноду и доки до кода и обновлять их по ходу работы.
  4. v1.3.0 (7 июня) — четыре slash-команды: next, progress, doc, reconcile.
  5. v1.4.0 (7 июня) — ужесточённое правило именования узлов: сущность, а не работа, с линтером на стороне сервера.

Заметьте: четыре содержательных релиза за пять недель, и ни один не потребовал от пользователей ничего, кроме /plugin update.

Итог серии

Пять частей складываются в одну мысль. Агент силён ровно настолько, насколько хорош внешний контур вокруг него.

В части 1 — зачем этот контур нужен: память агента не контекстное окно, а структура проекта, которую он читает за один вызов. В части 2 — на чём он стоит: YAML-файлы вместо базы, атомарная запись и живая синхронизация с канвой. В части 3 — как заставить агента планировать как архитектор: иерархия, наследуемые требования, User Story Map. В части 4 — рабочий цикл от get_next_task до complete_task с документацией как частью задачи. И сегодня — последняя миля: всё это ставится двумя командами и обновляется одной.

Попробовать можно на my-architect.app: аккаунт, токен, две команды в Claude Code. Если что-то не сойдётся с тем, что я тут написал — напишите мне, такие письма полезнее похвалы.