What changes for the user
Today the allium Claude Code plugin gives Claude the skills and agents to read,
write, and verify .allium specs — but not the allium-lsp language server.
Claude edits .allium files without live diagnostics, definition navigation,
or hover information, even though the same LSP binary already drives the VS Code
extension. After this change, Claude would see checker errors immediately after
each edit instead of waiting for the user to run allium check manually.
Why it matters
The Claude Code plugin system supports lspServers configuration
(see Plugins reference — LSP servers),
which feeds LSP diagnostics to Claude after each file edit and exposes
go-to-definition and hover data. For a spec language where cross-file references,
rule preconditions, and status-lifecycle constraints must stay internally
consistent, live checker feedback in the editing loop reduces the round-trip
between "Claude edits spec" and "user discovers the error".
Acceptance criteria
Suggested configuration (inline in .claude-plugin/plugin.json):
"lspServers": {
"allium": {
"command": "allium-lsp",
"extensionToLanguage": {
".allium": "allium"
}
}
}
The command must be in $PATH. Install via:
npm install -g allium-lsp # current install path
Nix / Homebrew install paths will follow from juxt/allium-tools#16.
Out of scope
- Bundling the
allium-lsp binary inside the plugin (Claude Code LSP plugins
configure the connection; they do not ship the binary)
- Any changes to
allium-lsp itself or the allium-tools repo
- MCP-LSP bridge configuration (would be a separate plugin component)
- Neovim / Helix LSP wiring (separate from the Claude Code plugin)
Links
What changes for the user
Today the allium Claude Code plugin gives Claude the skills and agents to read,
write, and verify
.alliumspecs — but not theallium-lsplanguage server.Claude edits
.alliumfiles without live diagnostics, definition navigation,or hover information, even though the same LSP binary already drives the VS Code
extension. After this change, Claude would see checker errors immediately after
each edit instead of waiting for the user to run
allium checkmanually.Why it matters
The Claude Code plugin system supports
lspServersconfiguration(see Plugins reference — LSP servers),
which feeds LSP diagnostics to Claude after each file edit and exposes
go-to-definition and hover data. For a spec language where cross-file references,
rule preconditions, and status-lifecycle constraints must stay internally
consistent, live checker feedback in the editing loop reduces the round-trip
between "Claude edits spec" and "user discovers the error".
Acceptance criteria
plugin.jsonincludes anlspServersentry that wires theallium-lspbinary to the
.alliumfile extension.alliumfile editwithout a separate
allium checkinvocationREADME.mdnotes thatallium-lspmust be installed separately beforethe LSP integration is active (consistent with the notice on official
marketplace LSP plugins)
Suggested configuration (inline in
.claude-plugin/plugin.json):The
commandmust be in$PATH. Install via:npm install -g allium-lsp # current install pathNix / Homebrew install paths will follow from juxt/allium-tools#16.
Out of scope
allium-lspbinary inside the plugin (Claude Code LSP pluginsconfigure the connection; they do not ship the binary)
allium-lspitself or theallium-toolsrepoLinks
allium-lspsource:packages/allium-lsp/in juxt/allium-toolsnix shellinstall path): Add a Nix flake allium-tools#16bun build --compileforallium-lspdistribution allium-tools#17