cf-vendor-merge skill

A skill that moves a customized standard 1C configuration to a new vendor release through a three-way git merge

  • 44 ★ on the repository
  • Last commit
Skill

Extended access

Why this level

  • Scripts run `ibcmd` and the 1C platform, create temporary databases and change branches in the working git repository.
  • The merge rewrites the configuration export, so a separate branch or a copy is needed before running.
All reasons and checks
Russian stack

alonehobo/1c-cf-vendor-merge

Install

In your terminal, with SkillFoxx CLI

npx skillfoxx add skills/cf-vendor-merge

Detects the agents on your machine, shows the access level and pins the version.

Other ways to install

Access and checks

How we review

Extended accessThe tool runs code or makes network calls and only reads external data.

  • Scripts run `ibcmd` and the 1C platform, create temporary databases and change branches in the working git repository.
  • The merge rewrites the configuration export, so a separate branch or a copy is needed before running.

This is third-party code. Review the repository files before installing.

What it does

The skill walks an agent through updating a customized standard 1C:Enterprise 8.3 configuration. It exports the old and new release files with `ibcmd`, lays the exports out on git branches, and merges three versions: the old standard release, the current configuration and the new standard release. Conflicts over deleted and changed objects, structural XML merges and templates are resolved automatically, and BSL customizations are carried over by parallel agents. After the merge the scripts check the result: references to missing objects and attributes, role rights, objects renamed to `Удалить*`, import into an empty database and a platform syntax check of modules through `/CheckModules`, including together with extensions. The skill does not update the infobase itself; that is done separately on an explicit command.

Who it is for. 1C developers and integrators who maintain a customized standard configuration and port every vendor release by hand

Good fit when

  • A new release of the standard configuration is out, and your database is on support with customizations.
  • Merging in Designer produces hundreds of conflicts and you want an agent to resolve them.
  • After the update you need proof that roles, object references and extensions still hold.
  • BSL module customizations have to be ported to the new release by parallel agents.

Not a fit when

  • The configuration has no customizations: the standard vendor update covers it.
  • You only have `.cfu` update files: the skill needs full `.cf` files of the old and new releases.
  • You need to update the infobase itself rather than the configuration: the skill does not touch the database.

Example request

Update our customized configuration to the new release: old.cf, new.cf and the current export sit in the folder next to this one

Limitations

You need Python 3 with the `lxml` library, git and the 1C 8.3 platform with `ibcmd.exe` and `1cv8.exe`. `.cfu` update files do not work. Temporary databases need about 25 GB of free space and a directory outside a cloud-synced folder. The skill is written around Windows platform paths, although the scripts are Python. No external MCP servers or other skills are needed, but the update pitfalls live in `references/gotchas.md` and are worth reading before starting.

How to disable. Delete the `cf-vendor-merge` directory from the agent's skills directory. Remove temporary databases and the merge working directory by hand.

FAQ

Will the skill update my working database?

The skill leaves the database alone. Results are checked on a temporary database, and loading into the working one is a separate step done only on an explicit command.

Does a .cfu update file work?

No, full CF files of the old and new releases are required. The old release version comes from `Configuration.xml` in the current export.

Do I need 1C MCP servers?

No, the skill runs on its own scripts and needs no other skills or MCP servers.

Which platform versions work?

The 1C 8.3 platform with `ibcmd.exe` and `1cv8.exe`. The `ibcmd` path comes from `.v8-project.json`, field `v8path`.

How much disk space is needed?

About 25 GB free, where temporary databases are created. Keep that directory outside a cloud-synced folder.

Discussion

No questions or reviews yet.

Russian stack

A skill that builds a small CF file with only the chosen objects from a 1C export so compare and merge open in seconds

SkillExtended access28Repository stars
Russian stack

A skill for 1C platform batch operations: build and unpack data processors, load and dump configurations and extensions, launch the base

SkillBroad access129Repository stars
Russian stack

A skill for fast 1C extension development: an edit-load-test loop, storage discipline and AI features through TAB's AI Library

SkillExtended access4Repository stars
Editors’ pick

Skills covering the full 1C:Enterprise 8.3 development cycle, from XML sources to publishing and web client testing

SkillBroad access781Repository stars

1C Developer Claude Skill

1C Developer — Claude Skill

Russian stack

A Claude skill for 1C:Enterprise 8.3 development: planning, BSL code and code review explained in Georgian

SkillExtended access2Repository stars

README in short

The README lists what the skill exports, merges and checks, and gives the requirements: Python, `lxml`, git, the 1C platform and disk space. Installation comes down to copying a directory into the skills directory.

README badge

Original SKILL.md

---
name: cf-vendor-merge
description: Обновление доработанной типовой конфигурации 1С на новый релиз через трехстороннее git-слияние XML-выгрузок (старый типовой / текущая / новый типовой) с автоматическим разбором конфликтов, переносом доработок BSL агентами и проверкой импортом, синтаксическим контролем модулей платформой и совместимостью расширений. Используй, когда нужно обновить конфигурацию на поддержке с доработками на новый релиз поставщика, «обновить базу на релиз», «перенести доработки на новую версию». НЕ для обновления без доработок (там db-update / vrunner cf_vendor_update) и не для обновления самой информационной базы — база обновляется отдельно, только по прямой команде.
argument-hint: "[старый.cf] [новый.cf] [текущая конфигурация]"
allowed-tools:
  - Bash
  - PowerShell
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - Agent
  - AskUserQuestion
---

# /cf-vendor-merge — обновление доработанной конфигурации на новый релиз

Скрипты: `scripts/` рядом с этим файлом (Python 3 + `lxml`, git, платформа 1С 8.3). Внешние MCP и другие skills не нужны. Грабли и решения — `references/gotchas.md`, прочитай до начала.
Все скрипты работают с рабочим каталогом слияния `<work>` и файлом состояния `<work>/vendor-merge.json`.

## Что нужно от пользователя

1. Полные `.cf`/`.dt` **старого** релиза (на котором стоит текущая конфигурация — версия в `Configuration.xml` текущей выгрузки) и **нового** релиза. `.cfu` не подходит.
2. Текущая конфигурация: XML-выгрузка (каталог) или ревизия в git, либо база, из которой выгрузить (`1cv8 DESIGNER /DumpConfigToFiles <каталог>`).
3. `ibcmd.exe` (из `.v8-project.json` → `v8path`), каталог для временных баз не в облачной папке, ~25+ ГБ свободно.
Рабочую базу не трогай: результат проверяется на временной/копии; загрузка в рабочую — только по прямой команде.

## Этап 1. Выгрузки и ветки

```
python vm_dump.py --ibcmd <ibcmd> --src <старый.cf> --out <tmp>\old_xml
python vm_dump.py --ibcmd <ibcmd> --src <новый.cf>  --out <tmp>\new_xml --keep-db
python vm_branches.py --repo <git-репозиторий> --work <work> --old-xml <tmp>\old_xml --new-xml <tmp>\new_xml (--custom-xml <каталог> | --custom-rev <ревизия>) [--root <коммит с .gitattributes>] [--gitattributes <файл>]
```
Сверь версии, которые печатают скрипты: старый релиз = версия поставщика в текущей конфигурации; формат выгрузки одинаковый. Ветки: `vendor-<старая>`, `vendor-<новая>`, `custom` (дерево текущей, родитель — старый релиз). Заданный `VM_COMMIT_TRAILER` (например, `\n\nCo-Authored-By: ...`) добавляется к сообщениям коммитов.

## Этап 2. Слияние и автоматический разбор

```
python vm_merge.py --work <work>                     # git merge -X no-renames, conflicts.json
python vm_resolve_md.py --work <work> [--apply]      # modify/delete: шум -> принять удаление поставщика
python vm_xmlmerge.py --work <work> [--apply]        # структурное слияние XML (без Template.xml)
python vm_templates.py --work <work> [--apply]       # макеты: целиком наш/поставщика по правилам
```

Report a problem