Годі розкидати 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