Распространение профилей: поделитесь целым агентом

Распространение профиля упаковывает полного агента VibeOS — личность, навыки, задания cron, MCP-подключения, конфигурацию — в виде git-репозитория. Любой, у кого есть доступ к репозиторию, может установить всего агента одной командой, обновить его на месте и оставить нетронутыми свои воспоминания, сессии и ключи API.

Если профиль — это локальный агент, то распространение — это тот же агент, сделанный доступным для обмена.

Что это значит

До появления распространений поделиться агентом VibeOS означало отправить кому-то:

Ваш SOUL.md
Список навыков для установки
Ваш config.yaml, без секретов
Описание того, какие MCP-серверы вы подключили
Любые запланированные задания cron
Инструкции, какие переменные окружения задать

…и надеяться, что они соберут это правильно. Каждое обновление версии или исправление ошибки означало повторение передачи.

С распространениями всё это живёт в одном git-репозитории:

my-research-agent/
├── distribution.yaml    # манифест: имя, версия, требования к переменным окружения
├── SOUL.md              # личность агента / системный промпт
├── config.yaml          # модель, температура, рассуждения, настройки инструментов по умолчанию
├── skills/              # встроенные навыки, поставляемые с агентом
├── cron/                # запланированные задачи, которые выполняет агент
└── mcp.json             # MCP-серверы, к которым подключается агент

Получатели выполняют:

vibeos profile install github.com/you/my-research-agent --alias

…и теперь у них есть целый агент. Они заполняют свои собственные ключи API (.env.EXAMPLE → .env) и могут запускать my-research-agent chat или обращаться к нему через Telegram / Discord / Slack / любую шлюзовую платформу. Когда вы публикуете новую версию, они выполняют vibeos profile update my-research-agent и получают ваши изменения — их воспоминания и сессии остаются на месте.

Почему git?

Мы рассматривали tarball'ы, HTTP-архивы, собственный формат. Ничто не превзошло git:

Нулевой этап сборки для авторов. Отправляете в GitHub; потребители устанавливают. Нет цикла «упакуй это, загрузи то, обнови индекс».
Теги, ветки и коммиты уже являются системой версионирования. Отправка тега делает за нас то, что «упаковка + загрузка релиза» делает для других инструментов.
Обновления — это fetch. А не повторная загрузка всего архива.
Прозрачность. Пользователи могут просматривать репозиторий, читать различия между версиями, открывать issues против него, форкать для кастомизации.
Приватные репозитории работают бесплатно. SSH-ключи, хелперы git credential, сохранённые учётные данные GitHub CLI — любая аутентификация, которая уже настроена в вашем терминале, применяется прозрачно.
Воспроизводимость — это SHA коммита. То же, что записывают pip и npm.

Компромисс: получателям нужен установленный git. На любой машине, работающей с VibeOS в 2026 году, это уже так.

Когда следует использовать распространение?

Хорошие варианты:

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

Не подходит:

Вы просто хотите сделать резервную копию профиля на своей машине. Используйте vibeos profile export / import — для этого они и предназначены.
Вы хотите поделиться ключами API вместе с агентом. auth.json и .env намеренно исключены из распространений. Каждый установщик приносит свои собственные учётные данные.
Вы хотите поделиться воспоминаниями / сессиями / историей разговоров. Это пользовательские данные, а не содержимое распространения. Никогда не поставляются.

предупреждение

VibeOS не контролирует git. Исключения файлов, описанные на этой странице, применяются установщиком, когда кто-то выполняет vibeos profile install или vibeos profile update. Они не применяются, когда вы выполняете git add или git commit.

Жизненный цикл: от автора к установщику и обновлению

Ниже приведён полный сквозной поток. Выберите ту сторону, которая вас интересует.

Для авторов: публикация распространения

Шаг 1 — Начните с рабочего профиля

Создайте и доработайте агента как любой другой профиль:

vibeos profile create research-bot
research-bot setup                    # настройте модель, ключи API
# Отредактируйте ~/.vibeos/profiles/research-bot/SOUL.md
# Установите навыки, подключите MCP-серверы, запланируйте задания cron и т.д.
research-bot chat                     # тестируйте, пока не будете довольны

Шаг 2 — Добавьте `distribution.yaml`

Создайте ~/.vibeos/profiles/research-bot/distribution.yaml:

name: research-bot
version: 1.0.0
description: "Автономный исследовательский ассистент с инструментами arXiv и веб-поиска"
vibeos_requires: ">=0.12.0"
author: "Ваше Имя"
license: "MIT"

# Сообщите установщикам, какие переменные окружения нужны агенту. Они проверяются
# в оболочке установщика и существующем файле .env, чтобы их не донимали
# вопросами о ключах, которые у них уже настроены.
env_requires:
  - name: OPENAI_API_KEY
    description: "Ключ API OpenAI (для доступа к модели)"
    required: true
  - name: SERPAPI_KEY
    description: "Ключ SerpAPI для веб-поиска"
    required: false
    default: ""

Это весь манифест. Каждое поле, кроме name, имеет разумное значение по умолчанию.

Шаг 3 — Создайте `.gitignore` перед первым коммитом

предупреждение

Сделайте это до выполнения git init или git add. Если вы уже общались с профилем, запускали настройку или иным образом использовали его, каталог теперь содержит файлы, которые вы не должны отправлять: .env, auth.json, memories/, sessions/, state.db*, logs/ и другие.

Создайте ~/.vibeos/profiles/research-bot/.gitignore как минимум со следующим содержимым:

# Учётные данные и секреты — НИКОГДА не коммитить
auth.json
.env
.env.EXAMPLE    # создаётся при установке, не является областью авторства

# Базы данных времени выполнения и состояние
state.db
state.db-shm
state.db-wal
vibeos_state.db
response_store.db
response_store.db-shm
response_store.db-wal
gateway.pid
gateway_state.json
processes.json
auth.lock
active_profile
.update_check

# Пользовательские данные — НИКОГДА не коммитить
memories/
sessions/
logs/
plans/
workspace/
home/

# Кеши и сгенерированные артефакты
image_cache/
audio_cache/
document_cache/
browser_screenshots/
cache/

# Инфраструктура (не должна быть в каталоге профиля, но безопасно исключить)
vibeos-agent/
.worktrees/
profiles/
bin/
node_modules/

# Пространство пользовательской кастомизации — ваши локальные переопределения
local/

# Контрольные точки и резервные копии (могут быть огромными)
checkpoints/
sandboxes/
backups/

# Логи
errors.log
.vibeos_history

Это зеркалирует жёстко исключённые пути, которые установщик отбрасывает на своей стороне. Всё остальное, что вы хотите оставить вне репозитория (черновики, большие файлы, локальные навыки), также должно быть здесь.

Шаг 4 — Отправьте в git-репозиторий

cd ~/.vibeos/profiles/research-bot
git init
git add .
git commit -m "v1.0.0"
git remote add origin git@github.com:you/research-bot.git
git tag v1.0.0
git push -u origin main --tags

Репозиторий теперь является распространением. Любой, у кого есть доступ, может его установить.

примечание

Установщик дополнительно удалит жёстко исключённые пути, даже если автор каким-то образом их отправит — но это защищает только установщиков, а не автора.

Шаг 5 — Помечайте версионные релизы тегами

Каждый раз, когда агент достигает стабильной точки, увеличивайте версию и ставьте тег:

# Отредактируйте distribution.yaml: version: 1.1.0
git add distribution.yaml SOUL.md skills/
git commit -m "v1.1.0: более точная SOUL для исследований, добавлен навык arxiv"
git tag v1.1.0
git push --tags

Получатели, выполняющие vibeos profile update research-bot, получат последнюю версию.

Как выглядит репозиторий

Полное авторское распространение:

research-bot/
├── .gitignore                   # исключает секреты и пользовательские данные (см. Шаг 3)
├── distribution.yaml            # обязательно
├── SOUL.md                      # настоятельно рекомендуется
├── config.yaml                  # модель, провайдер, настройки инструментов по умолчанию
├── mcp.json                     # подключения MCP-серверов
├── skills/
│   ├── arxiv-search/SKILL.md
│   ├── paper-summarization/SKILL.md
│   └── citation-lookup/SKILL.md
├── cron/
│   └── weekly-digest.json       # запланированные задачи
└── README.md                    # человекочитаемое описание (необязательно)

Принадлежащее распространению vs принадлежащее пользователю

Когда установщик обновляется до новой версии, некоторые вещи заменяются (область автора), а некоторые остаются нетронутыми (область установщика). По умолчанию:

Категория	Пути	При обновлении
Принадлежит распространению	`SOUL.md`, `config.yaml`, `mcp.json`, `skills/`, `cron/`, `distribution.yaml`	Заменяются из нового клона
Переопределение конфига	`config.yaml`	Фактически сохраняется по умолчанию — установщик мог настроить модель или провайдера. Передайте `--force-config` при обновлении, чтобы сбросить.
Принадлежит пользователю	`memories/`, `sessions/`, `state.db`, `auth.json`, `.env`, `logs/`, `workspace/`, `plans/`, `home/`, `_cache/`, `local/`	Никогда не трогаются

Вы можете переопределить список принадлежащего распространению в манифесте:

distribution_owned:
  - SOUL.md
  - skills/research/            # только мои исследовательские навыки; другие установленные навыки остаются
  - cron/digest.json

Если опущено, применяются значения по умолчанию выше — это то, что нужно большинству распространений.

Для установщиков: использование распространения

Установка

vibeos profile install github.com/you/research-bot --alias

Что происходит:

Клонирует репозиторий во временный каталог.
Читает distribution.yaml, показывает вам манифест (имя, версия, описание, автор, требуемые переменные окружения).
Проверяет каждую требуемую переменную окружения в вашей оболочке и существующем .env целевого профиля. Отмечает каждую как ✓ установлено или требует настройки, чтобы вы точно знали, что нужно настроить.
Запрашивает подтверждение. Передайте -y / --yes, чтобы пропустить.
Копирует файлы, принадлежащие распространению, в ~/.vibeos/profiles/research-bot/ (или туда, куда разрешается name из манифеста). Жёстко исключённые пути удаляются во время этого копирования, даже если автор случайно оставил их в репозитории.
Записывает .env.EXAMPLE с закомментированными требуемыми ключами — скопируйте в .env и заполните.
С --alias создаёт обёртку, чтобы вы могли запускать research-bot chat напрямую.

Типы источников

Работает любой git-URL:

# Сокращение GitHub
vibeos profile install github.com/you/research-bot

# Полный HTTPS
vibeos profile install https://github.com/you/research-bot.git

# SSH
vibeos profile install git@github.com:you/research-bot.git

# Самостоятельный хостинг, GitLab, Gitea, Forgejo — любой Git-хост
vibeos profile install https://git.example.com/team/research-bot.git

# Приватный репозиторий с использованием настроенной git-аутентификации
vibeos profile install git@github.com:your-org/internal-bot.git

# Локальный каталог во время разработки (не требуется git push)
vibeos profile install ~/my-profile-in-progress/

Переопределение имени профиля

Два пользователя, желающие одно и то же распространение под разными именами профилей:

# Алиса
vibeos profile install github.com/acme/support-bot --name support-us --alias
# Боб (то же распространение, другое локальное имя)
vibeos profile install github.com/acme/support-bot --name support-eu --alias

Заполнение переменных окружения

После установки профиль агента содержит .env.EXAMPLE:

# Переменные окружения, необходимые для этого распространения VibeOS.
# Скопируйте в `.env` и заполните своими значениями перед запуском.

# Ключ API OpenAI (для доступа к модели)
# (обязательно)
OPENAI_API_KEY=

# Ключ SerpAPI для веб-поиска
# (необязательно)
# SERPAPI_KEY=

Скопируйте его:

cp ~/.vibeos/profiles/research-bot/.env.EXAMPLE ~/.vibeos/profiles/research-bot/.env
# Отредактируйте .env, вставьте свои реальные ключи

Требуемые ключи, которые уже были в вашей оболочке (например, OPENAI_API_KEY, экспортированный в вашем ~/.zshrc), помечаются как ✓ установлено во время установки — вам не нужно дублировать их в .env.

Проверка установленного

vibeos profile info research-bot

Показывает:

Распространение: research-bot
Версия:          1.0.0
Описание:       Автономный исследовательский ассистент с инструментами arXiv и веб-поиска
Автор:          Ваше Имя
Требует:        VibeOS >=0.12.0
Источник:       https://github.com/you/research-bot
Установлено:    2026-05-08T17:04:32+00:00

Переменные окружения:
  OPENAI_API_KEY (обязательно) — Ключ API OpenAI (для доступа к модели)
  SERPAPI_KEY (необязательно) — Ключ SerpAPI для веб-поиска

vibeos profile list также показывает столбец Распространение, так что с первого взгляда видно, какие из ваших профилей пришли из репозиториев, а какие вы создали вручную:

 Профиль          Модель                       Шлюз          Псевдоним     Распространение
 ───────────────    ───────────────────────────    ───────────    ───────────    ────────────────────
 ◆default         claude-sonnet-4              остановлен     —            —
  coder           gpt-5                        остановлен     coder        —
  research-bot    claude-opus-4                остановлен     research-bot research-bot@1.0.0
  telemetry       claude-sonnet-4              работает       telemetry    telemetry@2.3.1

Обновление

vibeos profile update research-bot

Что происходит:

Повторно клонирует репозиторий из записанного URL источника.
Заменяет файлы, принадлежащие распространению (SOUL, навыки, cron, mcp.json).
Сохраняет ваш config.yaml — вы могли настроить модель, температуру или другие параметры. Передайте --force-config, чтобы перезаписать.
Никогда не трогает пользовательские данные: воспоминания, сессии, аутентификацию, .env, логи, состояние.

Нет повторной загрузки всего архива. Нет затирания ваших локальных изменений конфига. Нет удаления истории ваших разговоров.

Удаление

vibeos profile delete research-bot

Приглашение на удаление показывает информацию о распространении перед запросом подтверждения:

Профиль: research-bot
Путь:    ~/.vibeos/profiles/research-bot
Модель:  claude-opus-4 (anthropic)
Навыки:  12
Распространение: research-bot@1.0.0
Установлено из: https://github.com/you/research-bot

Это навсегда удалит:
  • Все конфиги, ключи API, воспоминания, сессии, навыки, задания cron
  • Псевдоним команды (~/.local/bin/research-bot)

Введите 'research-bot' для подтверждения:

Так вы никогда случайно не удалите агента, не зная, откуда он взялся или не имея возможности переустановить его.

Варианты использования и шаблоны

Личное: синхронизация одного агента между машинами

Вы создали исследовательского ассистента на ноутбуке. Вы хотите того же агента на рабочей станции.

# Ноутбук — сначала создайте .gitignore (см. «Для авторов» Шаг 3), затем:
cd ~/.vibeos/profiles/research-bot
git init && git add . && git status   # убедитесь, что секреты не проиндексированы
git commit -m "initial"
git remote add origin git@github.com:you/research-bot.git
git push -u origin main

# Рабочая станция
vibeos profile install github.com/you/research-bot --alias
# Заполните .env. Готово.

Любая итерация на ноутбуке (git commit && push) подтягивается на рабочую станцию с помощью vibeos profile update research-bot. Воспоминания остаются на каждой машине — ноутбук помнит свои разговоры, рабочая станция помнит свои, они не пересекаются.

Команда: доставка проверенного внутреннего агента

Ваша инженерная команда хочет общего бота для ревью PR с определённой SOUL, определёнными навыками и cron-задачей, которая прогоняет каждый PR через него.

# Ведущий инженер — сначала создайте .gitignore (см. «Для авторов» Шаг 3), затем:
cd ~/.vibeos/profiles/pr-reviewer
# ... создайте и настройте ...
git init && git add . && git status   # убедитесь, что секреты не проиндексированы
git commit -m "v1.0 PR reviewer"
git tag v1.0.0
git push -u origin main --tags    # отправьте на внутренний Git-хост вашей компании

# Каждый инженер
vibeos profile install git@github.com:your-org/pr-reviewer.git --alias
# Заполните .env своим собственным ключом API (выставляется счёт им), .env.EXAMPLE указывает, что требуется
pr-reviewer chat

Когда ведущий выпускает v1.1 (лучшая SOUL, новый навык), инженеры выполняют vibeos profile update pr-reviewer, и все переходят на новую версию в течение нескольких минут.

Сообщество: публикация публичного агента

Вы создали что-то новое — возможно, «трейдера Polymarket» или «суммаризатора академических статей» или «ассистента для управления сервером Minecraft». Вы хотите поделиться этим.

# Вы — сначала создайте .gitignore (см. «Для авторов» Шаг 3), затем:
cd ~/.vibeos/profiles/polymarket-trader
# Напишите хороший README.md в корне репозитория — GitHub показывает его на странице репозитория
git init && git add . && git status   # убедитесь, что секреты не проиндексированы
git commit -m "v1.0"
git tag v1.0.0
# Опубликуйте в публичный репозиторий GitHub
git remote add origin https://github.com/you/vibeos-polymarket-trader.git
git push -u origin main --tags

# Любой
vibeos profile install github.com/you/vibeos-polymarket-trader --alias

Твитните команду установки. Люди, которые попробуют, пришлют вам issues и PR. Если кто-то захочет кастомизировать, он форкнет — тот же git-воркфлоу, который все уже знают.

Продукт: доставка агента с жёсткими настройками

Вы создали VibeOS-поверх — возможно, обвязку для мониторинга соответствия, стек поддержки клиентов, доменную исследовательскую платформу. Вы хотите распространять это как продукт.

# distribution.yaml
name: telemetry-harness
version: 2.3.1
description: "Обвязка телеметрии соответствия — мониторинг и ревью регулируемых рабочих процессов"
vibeos_requires: ">=0.13.0"
author: "Acme Compliance Inc."
license: "Commercial"

env_requires:
  - name: ACME_API_KEY
    description: "Ваш лицензионный ключ Acme Compliance (пишите на support@acme.com)"
    required: true
  - name: OPENAI_API_KEY
    description: "Ключ API OpenAI для доступа к модели"
    required: true
  - name: GRAPHITI_MCP_URL
    description: "URL вашего экземпляра графа знаний Graphiti"
    required: false
    default: "http://127.0.0.1:8000/sse"

Ваши клиенты устанавливают одной командой; предварительный просмотр установки говорит им, какие ключи нужно подготовить; обновления выкатываются в момент, когда вы помечаете новый релиз тегом; их данные соответствия (memories/, sessions/) никогда не покидают их машину.

Эфемерный: одноразовые скрипты на общей инфраструктуре

Вы ведущий по эксплуатации. Вам нужен временный агент для диагностики инцидента в продакшене — готовая SOUL с правильными инструментами и MCP-подключениями — который будет работать на ноутбуках трёх дежурных инженеров в течение следующей недели.

# Вы — сначала создайте .gitignore (см. «Для авторов» Шаг 3), затем:
# Создайте профиль, закоммитьте, отправьте в приватный репозиторий
git push -u origin main

# Каждый дежурный
vibeos profile install git@github.com:your-org/incident-2026-q2.git --alias

# Инцидент разрешён — удалите
vibeos profile delete incident-2026-q2

Цикл установка-удаление достаточно дёшев, чтобы быть одноразовым.

Рецепты

Фиксация на конкретной версии

примечание

Фиксация git-ссылки (#v1.2.0) запланирована, но не входит в первоначальный релиз — установка в настоящее время отслеживает ветку по умолчанию. Отслеживайте установленную версию через vibeos profile info <name>` и воздерживайтесь от обновлений, пока не будете готовы.

Проверка вашей версии против последней

# Ваша установленная версия
vibeos profile info research-bot | grep Версия

# Последняя вышестоящая (без установки)
git ls-remote --tags https://github.com/you/research-bot | tail -5

Сохранение локальных настроек конфига при обновлениях

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

# ~/.vibeos/profiles/research-bot/local/my-overrides.yaml
# (распространение никогда не трогает local/)

…и ссылайтесь на него из config.yaml или вашей SOUL по мере необходимости.

Принудительная чистая переустановка

# Удалите и переустановите с нуля (также теряются воспоминания/сессии)
vibeos profile delete research-bot --yes
vibeos profile install github.com/you/research-bot --alias

# Обновитесь до текущего main, но сбросьте config.yaml до настроек распространения по умолчанию
vibeos profile update research-bot --force-config --yes

Форк и кастомизация

Стандартный git-воркфлоу — распространения — это просто репозитории:

# Форкните репозиторий на GitHub, затем установите свой форк
vibeos profile install github.com/yourname/forked-research-bot --alias

# Итерируйте локально в ~/.vibeos/profiles/forked-research-bot/
# Отредактируйте SOUL.md, закоммитьте, отправьте в свой форк
# Изменения вышестоящего: подтяните их в свой форк обычным способом

Тестирование распространения перед отправкой

На машине автора:

# Установка из локального каталога (не требуется git push)
vibeos profile install ~/.vibeos/profiles/research-bot --name research-bot-test --alias

# Доработка, удаление, переустановка, пока не будет правильно
vibeos profile delete research-bot-test --yes
vibeos profile install ~/.vibeos/profiles/research-bot --name research-bot-test

Чего НЕТ в распространении (никогда)

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

auth.json — OAuth-токены, учётные данные платформы
.env — ключи API, секреты
memories/ — память разговоров
sessions/ — история разговоров
state.db, state.db-shm, state.db-wal — метаданные сессий
logs/ — логи агента и ошибок
workspace/ — сгенерированные рабочие файлы
plans/ — черновые планы
home/ — домашняя точка монтирования пользователя в бэкендах Docker
*_cache/ — кеши изображений / аудио / документов
local/ — зарезервированное пространство для пользовательской кастомизации

Когда вы клонируете распространение как установщик, эти файлы просто не копируются в ваш каталог профиля. Когда вы обновляетесь, ваши копии остаются на месте. Если вы установили одно и то же распространение на пяти машинах, у вас есть пять изолированных наборов этих данных — по одному на машину.

предупреждение

Это исключение выполняется во время установки / обновления на машине установщика. Оно не предотвращает коммит конфиденциальных/ненужных файлов автором. Авторы должны использовать .gitignore, чтобы держать секреты вне репозитория.

Безопасность и доверие

Распространения профилей по умолчанию не подписаны. Вы доверяете:

Git-хосту (GitHub / GitLab / где угодно) отдавать байты, которые отправил автор.
Автору не отправлять вредоносную SOUL, навыки или задания cron.

Задания cron из распространения не планируются автоматически — установщик выводит vibeos -p <name> cron list, и вы включаете их явно. SOUL.md и навыки АКТИВНЫ, как только вы начинаете общаться с профилем, поэтому прочитайте их перед первым запуском, если устанавливаете от кого-то, кого не знаете.

Грубая аналогия: установка распространения похожа на установку расширения браузера или расширения VS Code. Низкий порог входа, большая мощность, доверяйте источнику. Для внутренних корпоративных распространений используйте приватный репозиторий и обычную git-аутентификацию — ничего нового настраивать не нужно.

Будущие версии могут добавить подпись, файл блокировки (.distribution-lock.yaml) с разрешённым SHA коммита и флаг --dry-run, который выводит diff перед применением обновления. Ничего из этого пока не поставляется.

Под капотом

Для деталей реализации, точного поведения CLI и всех флагов смотрите Справочник команд профиля.

Краткая версия:

install, update, info находятся внутри vibeos profile — не в параллельном дереве команд.
Формат манифеста — YAML с крошечной обязательной схемой (только name).
Установщик использует ваш локальный бинарник git для клонирования, поэтому любая аутентификация, которую уже обрабатывает ваша оболочка (SSH-ключи, хелперы учётных данных), работает прозрачно.
После клонирования .git/ удаляется — установленный профиль сам по себе не является git-чекаутом, что позволяет избежать ловушек типа «ой, я случайно закоммитил свой .env в git-историю распространения».
Зарезервированные имена профилей (vibeos, test, tmp, root, sudo) отклоняются во время установки, чтобы избежать коллизий с распространёнными бинарниками.

Смотрите также

Профили: запуск нескольких агентов — базовая концепция
Справочник команд профиля — каждый флаг, каждая опция
vibeos profile export / import — локальное резервное копирование / восстановление (не распространение)
Использование SOUL с VibeOS — создание личностей
Личность и SOUL — как SOUL вписывается в агента
Каталог навыков — навыки, которые можно включить

Что это значит​

Почему git?​

Когда следует использовать распространение?​

Жизненный цикл: от автора к установщику и обновлению​

Для авторов: публикация распространения​

Шаг 1 — Начните с рабочего профиля​

Шаг 2 — Добавьте distribution.yaml​

Шаг 3 — Создайте .gitignore перед первым коммитом​

Шаг 4 — Отправьте в git-репозиторий​

Шаг 5 — Помечайте версионные релизы тегами​

Как выглядит репозиторий​

Принадлежащее распространению vs принадлежащее пользователю​

Для установщиков: использование распространения​

Установка​

Типы источников​

Переопределение имени профиля​

Заполнение переменных окружения​

Проверка установленного​

Обновление​

Удаление​

Варианты использования и шаблоны​

Личное: синхронизация одного агента между машинами​

Команда: доставка проверенного внутреннего агента​

Сообщество: публикация публичного агента​

Продукт: доставка агента с жёсткими настройками​

Эфемерный: одноразовые скрипты на общей инфраструктуре​

Рецепты​

Фиксация на конкретной версии​

Проверка вашей версии против последней​

Сохранение локальных настроек конфига при обновлениях​

Принудительная чистая переустановка​

Форк и кастомизация​

Тестирование распространения перед отправкой​

Чего НЕТ в распространении (никогда)​

Безопасность и доверие​

Под капотом​

Смотрите также​

Что это значит

Почему git?

Когда следует использовать распространение?

Жизненный цикл: от автора к установщику и обновлению

Для авторов: публикация распространения

Шаг 1 — Начните с рабочего профиля

Шаг 2 — Добавьте `distribution.yaml`

Шаг 3 — Создайте `.gitignore` перед первым коммитом

Шаг 4 — Отправьте в git-репозиторий

Шаг 5 — Помечайте версионные релизы тегами

Как выглядит репозиторий

Принадлежащее распространению vs принадлежащее пользователю

Для установщиков: использование распространения

Установка

Типы источников

Переопределение имени профиля

Заполнение переменных окружения

Проверка установленного

Обновление

Удаление

Варианты использования и шаблоны

Личное: синхронизация одного агента между машинами

Команда: доставка проверенного внутреннего агента

Сообщество: публикация публичного агента

Продукт: доставка агента с жёсткими настройками

Эфемерный: одноразовые скрипты на общей инфраструктуре

Рецепты

Фиксация на конкретной версии

Проверка вашей версии против последней

Сохранение локальных настроек конфига при обновлениях

Принудительная чистая переустановка

Форк и кастомизация

Тестирование распространения перед отправкой

Чего НЕТ в распространении (никогда)

Безопасность и доверие

Под капотом

Смотрите также