base-sync

name

base-sync

description

Синхронизировать скиллы наследника с базовым шаблоном obsidian-agent-base — показать diff и сводку различий между base и текущим проектом, подтянуть обновления base, не затирая локальные кастомизации, и при необходимости продвинуть локальное улучшение обратно в base. Используй когда пользователь пишет /base-sync, "синхронизируй с base", "покажи дифф base vs проект", "что изменилось в base", "подтяни обновления шаблона", "продвинь это в base".

base-sync

Сверяешь общие скиллы наследника (new-task, close-task, worklog, list-tasks, decompose, learn, first-task-do, weekly-report, vault-скилл) с базовым шаблоном obsidian-agent-base и помогаешь пользователю решить, что подтянуть, а что оставить как локальную кастомизацию.

Тяжёлую работу (хэши, классификация, diff) делает скрипт .claude/sync-base.cjs. Скилл — это разговорная оболочка: запустить скрипт, объяснить состояния по-русски, применить безопасные обновления и провести разбор спорных.

Скрипт не редактирует SKILL.md. Все правки контента делаешь ты через Edit/Write, чтобы пользователь видел и одобрял каждую. Скрипт меняет только skills-lock.json (команды bootstrap/stamp).

Когда что запускать

1. Первый раз в проекте (нет блока baseSync в skills-lock.json): node .claude/sync-base.cjs bootstrap Принимает текущий base как точку отсчёта, авто-маппит локальные имена по алиасам (add-task→new-task, list→list-tasks, *-vault→obsidian-vault), помечает уже разошедшиеся скиллы customized: true. Покажи пользователю маппинг и спроси, всё ли верно (особенно not-imported скиллы и *-vault).

2. Регулярная сверка: node .claude/sync-base.cjs status Выводит таблицу состояний. Доменные скиллы наследника (которых нет в base) в таблицу не попадают — это нормально.

Состояния и что делать

• UNCHANGED — ничего не делаем.
• BASE-CHANGED — base обновился, локально не трогали. Безопасно подтянуть:
  1. node .claude/sync-base.cjs diff <skill> — покажи, что прилетает.
  2. Если customized: false — перенеси изменения base в локальный файл (Edit/Write), сохранив локальные пути/маркеры.
  3. Если customized: true — НЕ копируй целиком. Покажи хунки, перенеси только смысловые правки, сохранив кастомизацию (путь лога, секции # Week:, имена).
  4. node .claude/sync-base.cjs stamp <skill> — зафиксируй новую точку синхронизации.
• LOCALLY-MODIFIED — наследник правили, base не двигался. Тянуть нечего. Спроси: «продвинуть это улучшение в base?» (см. ниже).
• BOTH-CHANGED — и base, и наследник разошлись. Это ручной разбор:
  1. node .claude/sync-base.cjs diff <skill> — покажи различия base-сейчас vs локальный.
  2. Объясни, какие хунки — это обновления base (стоит взять), а какие — локальная кастомизация (оставить).
  3. Внеси согласованные правки в локальный файл.
  4. stamp <skill>.
• NEW-IN-BASE — в base есть скилл, которого нет у наследника. Спроси, импортировать ли (и под каким именем). Если не нужен — пометь в lock status: "not-imported" (правится руками или повторным bootstrap).

Продвижение улучшения вверх (наследник → base)

Когда локальное улучшение полезно всем (LOCALLY-MODIFIED или часть BOTH-CHANGED):

1. Открой base-репозиторий (baseSync.base.path).
2. Перенеси обезличенную версию правки в skills/<baseName>/SKILL.md базы по конвенциям INTEGRATION.md: убери имена людей/компаний, конкретные трекеры (Planfix/CRM) → «внешний трекер/система», доменные папки → общие.
3. Закоммить base (у base есть remote — это единственное место, где делаем коммит/пуш, и только по просьбе пользователя).
4. Вернись в наследника и stamp <skill> — его merge-base сдвинется на новый base, скилл перестанет числиться «впереди».
5. Сосед (другой наследник) при следующем status увидит BASE-CHANGED и сможет подтянуть уже обобщённое улучшение.

Защита от ошибок

• Не копируй base поверх customized: true скилла молча — сначала покажи хунки.
• Не делай stamp до того, как реально внёс/согласовал правки: stamp лишь фиксирует «здесь синхронно».
• Не коммить автоматически. Коммит base — только по явной просьбе.
• Не добавляй доменные скиллы наследника в base.
• Если diff пустой, а состояние не UNCHANGED — расхождение только во frontmatter (name/description), оно намеренно игнорируется хэшем; обычно достаточно stamp.

Проверка перед ответом

1. node .claude/sync-base.cjs status после правок показывает ожидаемую картину (подтянутое стало UNCHANGED).
2. Локальные кастомизации (путь лога, # Week:, имена скиллов) на месте.
3. skills-lock.json валиден (JSON не сломан), github-записи v1 не пострадали.
4. В ответе пользователю: что подтянул, что оставил как кастомизацию, что осталось разобрать.