Хватит разбрасывать AI-ресурсы: управляем skills, rules и MCP с помощью Bear.CTXPM

Когда AI-файлы копятся

Поработайте с агентами для кода достаточно долго, и репозиторий наполнится не только промптами. Появятся rules, задающие стиль кода, skills для рутинных задач, спецификации с границами продукта, MCP-конфиги для подключения внешних сервисов и memories о прошлых решениях. Что-то пришло из open source сообществ, что-то принадлежит команде, а что-то важно только для одного проекта.

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

С этого бардака и начинается Bear.CTXPM. Название — сокращение от Context Package Manager. Это open source протокол для работы с AI-ресурсами в паре с CLI-утилитой ctxpm. Он упорядочивает контекст и возможности, которыми пользуется AI, так же, как вы уже упорядочиваете код проекта.

Классические пакетные менеджеры ждут, что вы будете набирать команды для установки, обновления и проверки. CTXPM идёт по пути AI-first. Правила протокола и логика работы внедряются через входные документы агентов, и вместе со встроенными skills и CLI-инструментами это позволяет агентам проверять, обновлять, валидировать и приводить ресурсы в порядок прямо по ходу обычного кодинга, ревью и отладки. Флаги подкоманд учить не нужно. Агент читает протокол, вызывает инструменты и спрашивает вас, когда нужно решение.

Сначала протокол, потом инструмент

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

• Какие AI-ресурсы есть в проекте?
• Они внешние или их поддерживает сам проект?
• Где они лежат и должны ли быть под контролем версий?
• Из какой точки входа их должен читать каждый агент?
• Как их устанавливать, валидировать, переносить и обновлять?

Эти договорённости фиксируются в манифесте ctxpm.yaml, в структуре папки .ctxpm/ и во входных документах для агентов в корне проекта. CLI делает установку, обнаружение и валидацию надёжнее, но протокол от него не зависит. Там, где инструмент запустить нельзя, AI всё равно может понять проект по манифесту и каталогам.

Два вида владения

Терминов владения всего два: dependency и package.

dependency — это внешний AI-ресурс, который проект потребляет. Он может прийти из Git-репозитория, OCI-реестра, файлового пути или откуда-то ещё. Его содержимое обычно целиком не коммитится, но ctxpm.yaml фиксирует источник, путь и стабильную версию — примерно как сторонние зависимости в коде приложения.

package — это то, что проект поддерживает сам. Он связан с бизнес-логикой проекта, структурой кода или рабочими практиками, поэтому коммитится, проходит ревью вместе с исходниками и правится при каждом изменении проекта.

Владение не зависит от типа. Любой из двух видов может быть skill, rule, spec, prompt, memory или mcp. Skill для коммитов, импортированный с GitHub, — это dependency плюс skill. Релизный процесс, специфичный для одного репозитория, — package плюс skill. Собственные ограничения проекта на правку исходного кода могут быть package плюс rule. Так остаётся понятным, кто поддерживает ресурс и к кому идти, когда он сломался.

Что лежит в каталоге

В проекте, перешедшем на CTXPM, обычно есть ctxpm.yaml — манифест ресурсов. Установленные внешние ресурсы попадают в .ctxpm/dependencies/, который, как правило, указан в .gitignore. Ресурсы, которые поддерживает проект, лежат в .ctxpm/packages/ и обычно отслеживаются системой контроля версий.

.ctxpm/AGENTS.md — общий источник для входных файлов агентов. В зависимости от включённых профилей агентов в корне могут появиться сгенерированные копии с именами AGENTS.md, CLAUDE.md, GEMINI.md или любыми другими, которые ожидает агент, и все они указывают на один и тот же текст. Правила поддерживаются в одном месте, а входные файлы подстраиваются под соглашения каждого агента.

Входной документ также объясняет AI, как искать нужное. Начать с манифеста, перейти к собственным packages проекта, затем к внешним dependencies и подтягивать memory только тогда, когда задаче нужна история. Контекст не забивается всеми файлами с самого начала. Именно это делает подход управляемым AI: протокол — это руководство к действию, а не статическая конфигурация. Агент читает ресурсы по приоритету, решает, какие правила относятся к текущей задаче, и в подходящие моменты запускает проверки и обслуживание, так что разработчикам не приходится отрываться от кода и делать это вручную.

Репозиторий как собственный пример

Репозиторий самого проекта живёт по этим правилам. Сам ctxpm и внешний skill git-commit считаются внешними зависимостями. Релизный процесс, который обслуживает только этот репозиторий, — package плюс skill. Напоминание не смешивать исходный код продукта с собственными управляемыми ресурсами репозитория — package плюс rule. Упрощённый манифест выглядит так:

version: 1.0

project:
  name: Bear.CTXPM

agents:
  - generic
  - claude-code

dependencies:
  - name: ctxpm
    type: skill
    path: .ctxpm/dependencies/skills/ctxpm
    source:
      type: git
      url: https://github.com/gBearBest/Bear.CTXPM

packages:
  - name: ctxpm-release
    type: skill
    path: .ctxpm/packages/skills/ctxpm-release

  - name: ctxpm-source-boundary
    type: rule
    path: .ctxpm/packages/rules/ctxpm-source-boundary.md

Задача манифеста — зафиксировать зоны ответственности. AI, который позже зайдёт в репозиторий, поймёт, какой контент следует за апстримом, за какой отвечает проект и какие правила прочитать, прежде чем трогать исходники.

От разовой установки к обслуживанию силами AI

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

• находить AI-ресурсы, которые ещё не под управлением, и спрашивать, переносить ли их
• в разумные моменты проверять обновления внешних зависимостей
• сверять манифест с реальными каталогами и автоматически чинить символические ссылки входных файлов
• спрашивать вас, когда ресурсы конфликтуют или владелец неясен

AI не гоняет фиксированные скрипты. Он понимает смысловые границы протокола и сам решает, что делать, когда и нужно ли сначала спросить подтверждение. detect и migrate разбираются со старыми ресурсами: сначала сканирование только на чтение, потом ваше подтверждение, что именно переносить. check-updates и update тоже разделены намеренно: сначала найти и показать изменения, обновить — после подтверждения.

Для обычных внешних Git-ресурсов CTXPM записывает коммит, в котором последний раз менялся путь ресурса, а не обязательно самый свежий HEAD репозитория. Если в большом репозитории меняются только другие каталоги, зависимый skill не покажет ложного обновления, потому что версия соответствует корню реально установленного ресурса.

Разделение труда

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

Фиксированные шаги подходят для CLI: создание каталогов, починка символических ссылок, установка зависимостей, вычисление версий, поиск неуправляемых ресурсов, валидация манифестов. Решения, требующие суждения, остаются за AI: определить владельца ресурса, объяснить риски, решить, нужно ли подтверждение, разобраться с конфликтами при миграции. Протокол задаёт правила, CLI делает повторяемые шаги стабильными, а AI берёт на себя всё, что требует интерпретации. Вы остаётесь на уровне решений.

На практике AI сканирует проект в поисках неуправляемых ресурсов, читает ctxpm.yaml, чтобы понять владение и зависимости, проверяет обновления в апстриме, чинит символические ссылки входных файлов и загружает ресурсы по приоритету, экономя контекст. Вы решаете, станут ли разбросанные ресурсы пакетами или будут помечены как зависимости, обновляться ли при выходе новой версии и какое правило побеждает, если два конфликтуют. Это отличается от npm install, где вы помните команду и запускаете её сами. Здесь агент следит за состоянием проекта в фоне, пока вы пишете код, делаете ревью и отлаживаете, и подаёт голос только тогда, когда нужно ваше решение.

Кому это полезно

Разовому AI-демо это, скорее всего, не нужно. А вот долгоживущие проекты обычно упираются в такие ситуации:

• нескольким агентам нужно читать один набор правил проекта
• команды хотят общие skills, не копируя их в каждый репозиторий
• собственные промпты, спецификации и memories проекта нужно ревьюить вместе с исходниками
• у внешних ресурсов должны быть известные источники, версии и границы обновлений
• старые разбросанные AI-файлы нужно инвентаризировать перед миграцией

CTXPM не напишет за вас промпты и не берётся судить, какой агент умнее. Он проясняет, где ресурсы должны лежать, кто ими владеет и как долго они живут, чтобы AI-процессы можно было поддерживать вместе с проектом.

С чего начать

Дайте агенту такую инструкцию:

Следуй руководству по адресу https://raw.githubusercontent.com/gBearBest/Bear.CTXPM/latest/INSTALL.md, чтобы изучить этот проект, настроить его и перестроить так, чтобы AI-ресурсы и зависимости управлялись через Bear.CTXPM.

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

Если в вашем проекте уже есть rules, skills, промпты или memories, ранняя расстановка границ сэкономит уборку потом. Именно на этом шаге и сосредоточен CTXPM: дать существующему контексту дом и понятного ответственного. Репозиторий: https://github.com/gBearBest/Bear.CTXPM