XBSL (1C:Element)

A toolkit for 1C:Element: a linter with autofixes, an LSP server, documentation search, metadata scaffolding and translation into English spellings. Plus an MCP server and a VS Code extension on the same engine.

XBSL is a toolkit for 1C:Element projects. Such a project is written in pairs of files: Name.yaml describes an element, Name.xbsl holds its code. The platform checks the code once, when a deploy compiles it on the server, and that takes a while. XBSL answers on your own machine long before then. It ships as a Python engine plus a VS Code extension built on that engine.

What is in the box

Linter with autofixes – 280 rules in four tiers: yaml structure, text and typography conventions, code structure, and semantics checked against the platform data and the project itself (a plugin can add rules of its own on top).
LSP server – live diagnostics, go-to-definition and completion for any LSP-capable editor.
Metadata scaffolding – creating objects, attributes, routes and forms without hand-writing yaml.
Translation into English spellings – the project dictionary, the coverage and a CI check. What is left over comes back as suggestions from Yandex or Google.
Documentation search – a local full-text index built from your own 1C:Element distribution.
MCP server – linting, documentation search and every scaffolding operation exposed as tools for AI agents.
Web panel – a local page with the project findings: rule settings by tier, filters and opening a file in the editor.
VS Code extension (publisher keyfire, extension id keyfire.xbsl) – syntax highlighting, project-wide diagnostics, the form designer, a metadata tree, the platform docs panel, debugging and a deploy button, all backed by the same engine.

Where to go next

Quick start – install the package, generate the language data from your distribution, run the first check.
Checking sources – the flags of a run, what the deeper rules rely on, the baseline for an old codebase, CI.
Rules – the full list of linter checks, with severities and scope.
Metadata scaffolding – objects, attributes, routes and forms through the engine instead of hand-written yaml; the code templates.
Translating a project – the dictionary, the coverage, machine translation of what is missing, the CI check.
Servers and plugins – the LSP server, the MCP server, the web panel, and rules, data and severities of your own.
Platform data – the generated datasets, the documentation index, the diff between two platform versions.
Commands – every command and flag, generated from the tool itself.
Visual designer – the form panel, the palette, the properties panel and following the cursor.
Documentation panel – the platform help inside the editor: contents, search, the page for a symbol.
Guide – the map of all of the above.
README on GitHub – the short project tour and quick-start commands.
Contributing – how to add a rule or update the language data.

Nearby

The 1C:Element toolkit comes in two halves: one checks, the other delivers. A third tool does the same job on the neighbouring platform.

Elemctl – it delivers what the linter has checked: build from sources, upload, apply. It also verifies that the stand really came up on the new build. The XBSL: deploy command of the VS Code extension calls exactly this.
EDT-Bridge – the same idea on the 1C:Enterprise platform: an MCP bridge into 1C:EDT. An agent uses it to read the configuration, edit modules and forms, build extensions and debug.

Language data (keywords, the stdlib type catalog, the configuration metamodel) is generated from your own 1C:Element distribution and is not bundled with the project – see Language data in the guide.

Not affiliated with 1C. “1C:Element”, “1C:Fresh” and related names are trademarks of their respective owners – see NOTICE.