By juxt
Write and maintain Allium specification files to capture domain-level software behavior, then generate integration, property-based, and state machine tests from those specs. Detect and fix divergences between specs and implementation code, with language server support for .allium files.
Tend the Allium garden. Use when the user wants to write, edit, update, add to, improve, clarify, refine, restructure, fix or migrate Allium specs. Covers adding entities, rules, triggers, surfaces and contracts, fixing syntax or validation errors, renaming or refactoring within specs, migrating specs to a new language version, and translating requirements into well-formed specifications. Pushes back on vague requirements.
Weed the Allium garden. Find where Allium specifications and implementation code have diverged, and help resolve the divergences. Use when the user wants to check spec-code alignment, compare specs against implementation, audit for spec drift or violations, sync specs with code or code with specs, or verify whether the implementation matches what the spec says.
Give your AI agents something more useful than a prompt. Velocity through clarity.
Extract an Allium specification from an existing codebase. Use when the user has existing code and wants to distil behaviour into a spec, reverse engineer a specification from implementation, generate a spec from code, turn implementation into a behavioural specification, or document what a codebase does in Allium terms.
Run a structured discovery session to build an Allium specification through conversation. Use when the user wants to create a new spec from scratch, elicit or gather requirements, capture domain behaviour, specify a feature or system, define what a system should do, or is describing functionality and needs help shaping it into a specification.
Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires.
Tend the Allium garden. Use when the user wants to write, edit, update, add to, improve, clarify, refine, restructure, fix or migrate Allium specs. Covers adding entities, rules, triggers, surfaces and contracts, fixing syntax or validation errors, renaming or refactoring within specs, migrating specs to a new language version, and translating requirements into well-formed specifications. Pushes back on vague requirements.
Modifies files
Hook triggers on file write and edit operations
Uses power tools
Uses Bash, Write, or Edit tools
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Velocity through clarity
Feed your AI something healthier than Markdown. juxt.github.io/allium
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.
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.
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
/elicit (from intent) or /distill (from code) produces the spec. Unlike re-reading code each session, the spec persists, so meaning doesn't drift./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./weed for spec↔code alignment, then the CLI's structural checks. A behaviour-level pass/fail, not merely "unit tests are green."/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:
/elicit → /propagate → implement → /weed, looping /tend → /propagate as requirements change./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.)
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:
npx claudepluginhub juxt/alliumInterrupt forward momentum and step back to reassess
Capture intent across issues, commits, and PRs — why, not just what
Pipe long command output through glance for token-efficient summaries
Specification-Driven Development with Process Discipline for Claude Code
Acceptance Test Driven Development for Claude Code. Enforces the ATDD methodology: write Given/When/Then specs first, generate a project-specific test pipeline, maintain two test streams (acceptance + unit). Inspired by Robert C. Martin's acceptance test approach from empire-2025.
Specification-driven development workflow: specify → plan → tasks → implement
Spec-driven development with search, conflict detection, and reporting
Comprehensive Behavior-Driven Development principles, practices, and collaboration patterns.
Spec-driven development pipeline for Claude Code: interview-to-spec, spec-approach, tdd, verify, diagnose, and a feature orchestrator.