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 written as Name.yaml (element description) and Name.xbsl (code module) pairs. It gives fast local feedback ahead of the slow server-side compilation that runs on deploy – the only check the platform itself provides. The project ships as a Python engine and a VS Code extension built on top of it.

What is in the box

Linter with autofixes – 190 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, coverage and a CI gate, with an external translator (Yandex or Google) filling the remainder as suggestions.
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 a legacy 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, coverage, machine translation of what is missing, the CI gate.
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 is two halves of one loop, and a third tool does the same job on the neighbouring platform.

Elemctl – delivery of what the linter has checked: build from sources, upload, apply, and an honest verification that the stand actually 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 through which an agent reads the configuration, edits modules and forms, builds extensions and debugs.

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.