allium

Allium

The specification language that talks back: allium-lang.org.

What this is

Allium is a skill for clarifying intent during agentic engineering. The LLM builds and maintains a behavioural specification alongside your code, capturing what the system should do in a form that persists across sessions. Paired with a CLI that validates syntax and draws semantic inferences, it catches design gaps, surfaces implications you missed and generates tests from the formal behaviours of your system.

It also works in reverse. Point Allium at code you already have and it distils a specification of how the system behaves, surfacing bugs and edge cases the code never made explicit.

Command-line tooling

The Allium CLI checks specs for structural problems and generates tests. It catches things language models can't do reliably on their own: tracing data flow across rules, verifying that every entity lifecycle can reach a terminal state, spotting dead ends. The LLM uses these findings to ask better questions and produce more complete specs.

The skills work without the CLI, falling back to the language reference, but installing it means every edit is formally checked and the results feed straight into the conversation.

Install via Homebrew or crates.io:

brew tap juxt/allium && brew install allium

cargo install allium-cli

See the allium-tools repo for details.

How it works

You keep a .allium file alongside your code, setting out what the system should do rather than how it does it. It contains entities, which describe the things in the system and their shape, and rules. Each rule has three parts: a when that names the triggering event, a requires that lists the preconditions, and an ensures that states the outcomes. The spec and the code are two representations of the same system, one behavioural and one concrete, and much of the value comes from comparing them against each other, and against the tests that connect them. Because the behaviour is written as structure rather than prose, contradictions show up on their own: two rules with incompatible preconditions expose the conflict without a powerful model having to notice it.

Two directions feed the spec, and a loop keeps it, the tests and the code in agreement:

        intent ──/elicit──►  ┌───────────────┐  ◄──/distill── existing code
       (forward)             │ .allium spec  │              (backward)
                             └──────┬───┬────┘
                          /tend     │   │   /weed
                      (edit spec)   │   │  (reconcile with code)
                                    ▼   ▼
                                /propagate
                             (generate tests)

/elicit works forward from intent through conversation; /distill works backward from existing code, filtering out implementation detail. /tend makes targeted edits as requirements change; /weed finds where spec and code have diverged and reconciles them in either direction; /propagate generates tests from the spec so the implementation is checked against specified behaviour. /allium is the entry point: point it at your project and it routes you to the right one. The skills table below covers each in detail.

The Allium loop

Agentic coding runs as a loop. The agent gathers context, takes action, verifies the result and repeats until the goal is met. Verification is the phase that decides quality, because the loop needs a signal it can trust to tell green from done. Allium is built for that loop and takes on its hardest parts: a verification signal at the level of behaviour, and context that doesn't drift between sessions.

   gather context ───▶ take action ──────▶ verify ─────────▶ repeat
   /elicit · /distill   /propagate → tests   run tests          until
   → the spec           then implement       → /weed            converged
   (durable context)                         → CLI checks
          ▲                                        │
          └──────────────── revise intent ◀────────┘
              /tend, when verify shows the SPEC
              (not the code) was wrong

Gathering context means producing the spec, working forward from intent with /elicit or backward from existing code with /distill. The spec persists, so meaning carries from one session to the next instead of being re-read from the code each time. Taking action starts with /propagate, which turns the spec into tests, the contract you then implement against. For new behaviour, confirm those tests fail first, since a generated test that is already green is either already covered or vacuous.

Verification runs the tests, then /weed to check that spec and code still agree, then the CLI's structural checks. A pass at this level means the behaviour is right, not just that the unit tests are green. The loop repeats until spec, tests and code agree and no questions remain open. It can re-enter at any phase: when verification shows the spec itself was wrong, you revise intent with /tend instead of patching the code, the way real development turns up requirements by building rather than assuming them fixed from the start.

Two entry points run the same loop:

• Spec-first (new features): /elicit → /propagate → implement → /weed, looping /tend → /propagate as requirements change.
• Code-first (existing code): /distill → review → /propagate → run against the code → /weed, repeated per area until a pass finds nothing new.

See recommended loops for the full walkthrough, both diagrams, exit conditions and the implementation prompt. This is the "agentic loop" framing now common in AI engineering; for background see How Claude Code works and Loop Engineering.

Get started

Allium works with Claude Code, Codex, Copilot, Cursor, Windsurf, Aider, Continue and 40+ other tools. How you install depends on your editor, but the skills are the same everywhere. See supported harnesses for the full matrix and what each one gets.

Claude Code via the JUXT plugin marketplace:

/plugin marketplace add juxt/claude-plugins
/plugin install allium

Codex via the JUXT plugin marketplace:

codex plugin marketplace add juxt/claude-plugins
codex plugin add allium@juxt-plugins

Cursor, Windsurf, Aider, Continue and other skills-compatible tools:

npx skills add juxt/allium

GitHub Copilot reads skills and agents from the repository automatically. No installation needed.

Other editors: If your editor doesn't read from .agents/skills/, symlink the installed skills into wherever it does look (e.g. ln -s .agents/skills/allium .continue/rules/allium, or mklink /J on Windows). Use a symlink rather than copying; the skill files contain relative links to reference material that a copy would break.

Once installed, type /allium to get started. Allium examines your project and points you at the best next move — usually driving the whole loop end to end, or a single skill like distilling a spec from existing code or building one through conversation. Once you're familiar with the individual skills, you'll likely invoke them directly.

Jump to what Allium looks like in practice.

Supported harnesses

Allium is built to be portable. The skills are plain Markdown and the CLI is a standalone binary, so any tool that can follow instructions and run allium check can use it. Whether a harness is supported comes down to one thing: it needs to read Anthropic-style skills or an AGENTS.md file. If it does, npx skills add juxt/allium installs the skills and they run. The harnesses named below are the ones we provide install paths and per-editor setup for; anything else works through that same standard.

Allium reaches a harness through up to four layers. Harnesses differ in how many of them they can use.

• Skills. The six workflows (/allium, /elicit, /distill, /propagate, /tend, /weed), and the core of Allium. Any agent that reads Anthropic-style skills or an AGENTS.md can run them.
• Autonomous agents. tend and weed running in their own context. This needs a harness with a subagent concept.
• Automatic verification. A post-edit hook runs allium check and feeds the results back in the same turn. This needs an edit hook.
• Live diagnostics. The allium-lsp language server, for go-to-definition, hover and inline errors. This needs an LSP client.

Harness	Skills	Agents	Auto-verify	LSP	Install
Claude Code	✓	✓	✓	✓	Plugin
Codex	✓	—	git hook	manual	Plugin
GitHub Copilot (agent mode)	✓	✓	git hook	—	Reads repo
Cursor	✓	—	recipe	—	npx skills
Windsurf	✓	—	recipe	—	npx skills
Aider	✓	—	recipe	—	npx skills
JetBrains (Junie)	✓	—	recipe	manual	npx skills
Any other skills or AGENTS.md reader (Continue, Cline, Zed, Gemini CLI, opencode, Amp, Kilo Code, Factory, …)	✓	—	git hook	manual	npx skills

recipe means we ship an editor-specific config you turn on once: Cursor and Windsurf edit hooks, Aider's lint-cmd, or a JetBrains File Watcher. git hook means verification runs through the harness-agnostic pre-commit hook or a manual allium check, rather than live in the loop. manual LSP means the allium-lsp server works with the editor's language client, but you wire it up yourself. Only the Claude Code plugin does that for you.

Claude Code is the reference harness. It uses every layer, and we test against it first. Everything else runs the same skills. The differences are in verification and live diagnostics, not in the language or the workflows.

Not supported

Allium needs an agent that can read and maintain a spec. A couple of categories are out of scope by design.

• Autocomplete-only assistants. These predict the next token. They don't follow a skill or drive a loop, so there is nothing for Allium to attach to. GitHub Copilot's agent mode is supported, but its plain ghost-text completions are not.
• Harnesses with no way to load instructions. If a tool can't read a skill, an AGENTS.md or a rules file, you can't point it at Allium.

If a tool in either group gains an instruction-following agent, we'll add it.

Reporting issues

If a skill won't load or misbehaves on one of the harnesses above, tell us. Raise an issue and name the harness. If your harness runs the skills but has no automatic verification or live diagnostics, that's a capability gap rather than a fault: run allium check from the git pre-commit hook or by hand, and wire up allium-lsp if your editor has a language client. Autocomplete-only tools have no agent for the skills to attach to, so Allium won't run there.

How editors discover skills and agents is still settling, and we ship the most portable formats we can. If your editor doesn't pick something up, tell us which one.

Skills and agents

Allium provides five skills, an entry point and two autonomous agents.

Skill	Purpose
/allium <goal or prompt>	Entry point. Give it a goal and it drives the whole loop to convergence — gather context, take action, verify, repeat — running the other skills as phases; give it a single task and it routes you to the right skill.