Allium

Velocity through clarity

Feed your AI something healthier than Markdown. juxt.github.io/allium

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.

How it works

You keep a .allium file alongside your code describing what the system should do — entities and their shapes, and rules in the form when an event happens, requires these preconditions hold, ensures these outcomes follow — while deliberately leaving out how it's done. The spec is the primary artefact; the code that implements it is secondary. Because the structure is explicit rather than prose, contradictions surface on their own: two rules with incompatible preconditions expose the conflict without anyone needing to be clever enough to spot it.

Two forces feed the spec, and one loop keeps it honest against the code:

        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 is a loop: the agent gathers context, takes action, verifies the result, and repeats until the goal is met. The phase that decides quality is verification — a signal the loop can trust to tell green from done. Allium is built for that loop, and it owns the hard parts: a behavioural verification signal, 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

• Gather context — /elicit (from intent) or /distill (from code) produces the spec. Unlike re-reading code each session, the spec persists, so meaning doesn't drift.
• Take action — /propagate turns the spec into tests (the contract), then you implement against them. For new behaviour, confirm the tests fail first — a generated test that's already green is already covered or vacuous.
• Verify — run the tests, then /weed for spec↔code alignment, then the CLI's structural checks. A behaviour-level pass/fail, not merely "unit tests are green."
• Repeat — until spec, tests and code agree and no open questions remain. The loop can re-enter at any phase: when verification shows the spec was wrong, you revise intent (/tend), not just the code — the way real development discovers requirements by building, rather than assuming them fixed up front.

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.

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.

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.

Skills and agents

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

How skills appear depends on your editor. Some show the fully qualified form (/allium:weed), others show the short form (/weed), and some support both. If one form isn't recognised, try the other. The entry point is /allium — because its name matches the plugin, its fully qualified form is /allium:allium (the same plugin:skill rule as every other skill); either invokes it. Skills also auto-trigger when you open or edit .allium files.

Tend and weed are also available as autonomous agents that run in their own context, keeping Allium syntax out of your main session. Claude Code picks up agents from agents/, Copilot from .github/agents/. How editors discover skills and agents is still settling; we make these available in the most portable formats we can and expect to consolidate as conventions stabilise. If your editor doesn't pick something up, raise an issue.

For larger codebases, distillation and other ambitious tasks may need several passes to capture everything. Consider an iterative approach like the Ralph Wiggum loop, repeating until there's nothing further to do.

Why not just point the LLM at the code?

Within a session, meaning drifts: by prompt ten or twenty, the model is pattern-matching on its own outputs rather than the original intent. Across sessions, knowledge evaporates entirely. Modern LLMs navigate codebases effectively, but the limitation appears when you need to distinguish what the code does from what it should do. Code captures implementation, including bugs and expedient decisions. The model treats all of it as intended behaviour.

Precise prompting helps, but precise prompting means specifying intent: which behaviours are deliberate, which constraints must be preserved. You end up writing descriptions of intent distributed across your prompts. Allium captures this in a form that persists. The next engineer, or the next model, or you next week, can understand what the system does and what it was meant t