XBSL: a toolkit for 1C:Element
XBSL
A linter with autofixes, an LSP, docs search and metadata scaffolding for 1C:Element, plus an MCP server and a VS Code extension on one engine
Medium risk
We rate an entry medium when the tool runs code, makes network calls or reads project files. Check what exactly it does before installing.
Why this level
- The --fix command and scaffolding operations directly rewrite the project's yaml and xbsl files
- Private plugins via entry points can add third-party code into the linter engine
Install
In your terminal, with SkillFoxx CLI
npx skillfoxx add cli/xbslDetects the agents on your machine, checks the risk and pins the version.
Other ways to install
Install the tool
pipx install xbslWithout pipx, pip install xbsl works too.
Install the package with pip install xbsl, generate the language data with xbsl extract --dist "path to the 1C:Element distribution", then connect the MCP server with claude mcp add xbsl -- xbsl-mcp.
Other ways from the author
pip install xbslInstall the package from PyPI.
This is third-party code. Review the repository files before installing.
What it does
XBSL closes a real gap: 1C:Element has no tooling outside the platform itself, and the only code check is a slow server-side compilation on deploy. The engine reads pairs of Name.yaml and Name.xbsl files and answers right away on your own machine: 250 rules across four tiers, from structure and the yaml schema to semantics checked against platform and project data, autofixes via --fix, and a baseline to adopt a rule on old code without cleaning everything up front. Metadata scaffolding creates objects, attributes, routes and forms without hand-written yaml: 33 element kinds, forms generated with real content, and context-aware object renaming. The same engine is served through four surfaces: the CLI, an LSP server for editors, an MCP server for AI agents, and a local web UI, while the platform's language data is generated from the user's own distribution rather than shipped in the repository.
Who it is for. For 1C:Element developers who want instant local code checks and automated metadata operations instead of waiting for server-side compilation.
Good fit when
- You want 1C:Element code checked right on your own machine, without waiting for a deploy and server compilation
- You want to quickly create an object, attribute or form without hand-writing yaml
- You want an MCP server that gives an agent linting, documentation search and scaffolding operations in one round trip
Not a fit when
- The project isn't on 1C:Element: the rules and metamodel are specific to this platform
- You don't have access to your own 1C:Element distribution: the language data (keywords, types, metamodel) is only generated from it and isn't shipped in the repository
- You need checks without installing the Python package: the README doesn't describe alternative binary builds beyond the native mypyc wheels
Example request
Create a new Goods catalog in the vendor/App/Main project and add it a string Color attributeLimitations
The platform's language data (keywords, the stdlib type catalog, the configuration metamodel, terms, the documentation index, the component schema) is not shipped in the repository and is generated by the xbsl extract command from the user's own 1C:Element distribution. The project is independent and not affiliated with 1C; 1C:Element and 1C:Fresh are trademarks of their respective owners. Before version 0.16 the project was named xbsl-lint with the xbsllint package; old commands and imports are kept as aliases. A private plugin can add rules and language data via entry points, which widens the third-party code surface if such a plugin is installed.
How to disable. Uninstall the package with pip uninstall xbsl, disable the VS Code extension, and remove the xbsl block from your MCP client configuration.
Security check
- The --fix command and scaffolding operations directly rewrite the project's yaml and xbsl files
- Private plugins via entry points can add third-party code into the linter engine
README in short
The README explains the problem of 1C:Element having no tooling outside the platform and a single-engine architecture with four surfaces (CLI, LSP, MCP, web). It describes a three-step quick start including mandatory language-data generation from the user's own distribution, a set of 250 rules across four tiers, autofixes and a baseline, metadata scaffolding with 33 element kinds and command examples, a VS Code extension built on the LSP server, 51 built-in code templates, documentation search via a local docs.sqlite, an MCP server with linting and meta_* operation tools, a local web UI, CI integration, and an extension mechanism via entry points for private plugins. MIT license.
FAQ
Does the linter's data ship with the package?
No, the README explicitly states none of it is in the repository; all data is generated from the user's own platform distribution via xbsl extract.
Can the MCP server create objects, not just check code?
Yes, every scaffolding operation is available via MCP as meta_* tools, and an agent can create an object and get the lint of the written files in one call.
Related
A skills library that gives coding agents a development process: brainstorming, planning, TDD, subagents and code review
Skills for real engineers by Matt Pocock
Skills For Real Engineers
Small composable skills for engineering with agents: plan grilling, TDD, bug diagnosis, code review and architecture
GitHub toolkit for spec-driven development: the specify CLI adds agent commands and skills to a project, from principles to implementation
Reference MCP servers
Model Context Protocol servers
Official reference MCP servers: Filesystem, Fetch, Git, Memory, Sequential Thinking, Time and Everything