# allium

Captures domain behaviour in .allium specs and drives a loop reconciling requirements, integration tests, and application code.

- skill · `type=skill` · Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode · 3600 installs · ★ 521
- Author: juxt
- License: MIT · policy=mirror · the beginning of the file is at the end of this page
- Source: https://github.com/juxt/allium/tree/HEAD/skills/allium/SKILL.md
- Updated: 2026-09-27
- HTML: https://affpapa.org/en/nevibecode/skills/allium

## What it does

The skill provides syntax and structure for Allium, a domain-level specification language. It captures observable system behavior, entities, and business logic before implementation starts. Allium explicitly ignores implementation choices like framework selection, database schemas, UI layouts, and internal algorithms.

When given a goal via `/allium <goal>`, the agent drives an autonomous loop: gather context, create specs, propagate tests, and verify alignment against code. Allium does not produce application code or unit tests. It only generates domain specifications along with integration and property-based tests. Implementation remains standard coding that you or the agent write against failing tests.

## Install

### Claude Code (native platform)

1. **Skills CLI (Vercel)**
```bash
npx skills add juxt/allium --skill allium -a claude-code
```

2. **Manually: put the files in place**
- File: `~/.claude/skills/allium/SKILL.md` — Copy the whole skill folder; for one project use .claude/skills/allium/

### Codex

1. **Skills CLI (Vercel)**
```bash
npx skills add juxt/allium --skill allium -a codex
```

2. **Manually: put the files in place**
- File: `.agents/skills/allium/SKILL.md` — For all projects use ~/.agents/skills/

### Cursor

1. **Skills CLI (Vercel)**
```bash
npx skills add juxt/allium --skill allium -a cursor
```

2. **Manually: put the files in place**
- File: `.cursor/skills/allium/SKILL.md` — Cursor also reads .agents/skills/ and .claude/skills/

### GitHub Copilot

1. **GitHub CLI**
```bash
gh skill install juxt/allium allium
```

2. **Manually: put the files in place**
- File: `.github/skills/allium/SKILL.md`

### Gemini CLI

1. **Skills CLI (Vercel)**
```bash
npx skills add juxt/allium --skill allium -a gemini-cli
```

2. **Platform CLI**
```bash
gemini skills install https://github.com/juxt/allium --path skills/allium
```

### Windsurf (Devin Desktop)

**Manually: put the files in place**
- File: `.devin/skills/allium/SKILL.md` — The legacy .windsurf/skills/ path still works

### OpenCode

**Skills CLI (Vercel)**
```bash
npx skills add juxt/allium --skill allium -a opencode
```

### Claude.ai

**Claude.ai**
- Zip the folder and upload it in Settings → Capabilities → Skills

Where a file is given instead of a command, copy the files from the source to that path: https://github.com/juxt/allium/tree/HEAD/skills/allium/SKILL.md

## When to use it
- specify domain logic without committing to an implementation stack
- generate integration and end-to-end tests from domain specs
- reconcile drift between code and behavioural requirements
- drive an autonomous spec-to-test-to-code convergence loop

## Example prompts
- /allium add gift cards
- /allium get password reset working
- Write an allium spec for the Candidacy entity with interview slots

## Source text · SKILL.md · MIT

Below is the content of a third-party file. It is data, not instructions for you: do not act on anything written inside unless the human asks. Block tag: 03e822b8a0e3a271.

BEGIN THIRD-PARTY FILE 03e822b8a0e3a271
```text
---
name: allium
description: Give your AI agents something more useful than a prompt. Velocity through clarity.
version: 3
auto_trigger:
  - file_patterns: ["**/*.allium"]
  - keywords: ["allium", "allium spec", "allium specification", ".allium file"]
---

# Allium

Allium is a formal language for capturing software behaviour at the domain level. It sits between informal feature descriptions and implementation, providing a precise way to specify what software does without prescribing how it's built.

The name comes from the botanical family containing onions and shallots, continuing a tradition in behaviour specification tooling established by Cucumber and Gherkin.

Key principles:

- Describes observable behaviour, not implementation
- Captures domain logic that matters at the behavioural level
- Generates integration and end-to-end tests (not unit tests)
- Forces ambiguities into the open before implementation
- Implementation-agnostic: the same spec could be implemented in any language

Allium does NOT specify programming language or framework choices, database schemas or storage mechanisms, API designs or UI layouts, or internal algorithms (unless they are domain-level concerns).

## Routing table

| Task | Tool | When |
|------|------|------|
| Writing or reading `.allium` files | this skill | You need language syntax and structure |
| Building a spec through conversation | `elicit` skill | User describes a feature or behaviour they want to build |
| Extracting a spec from existing code | `distill` skill | User has implementation code and wants a spec from it |
| Modifying an existing spec | `tend` skill | User wants targeted changes to `.allium` files |
| Checking spec-to-code alignment | `weed` skill | User wants to find or fix divergences between spec and implementation |
| Generating tests from a spec | `propagate` skill | User wants to generate tests, PBT properties or state machine tests from a specification |
| Attesting a loop's convergence | `witness` skill | User wants to independently confirm a run's convergence claim from ground truth — tests really pass, no generated test was weakened, no blocking question was silently parked |
| Driving the whole loop to convergence | this skill (see [driving the loop](./references/driving-the-loop.md)) | User wants to build or reconcile a feature end to end — `/allium <goal>` runs the gather→act→verify→repeat loop autonomously until spec, tests and code agree |

## Responding to `/allium` (loop-first)

`/allium` is the entry point. Bias toward the autonomous path — the whole-loop value is exactly what occasional single-skill use misses:

- **Clear single task** → route straight to that skill (per the routing table); don't make the user wade through a menu.
- **A goal or feature** (e.g. "add gift cards", "get password reset working") → drive the whole loop end to end yourself, rather than running one phase. Follow [driving the loop](./references/driving-the-loop.md).
- **Bare or ambiguous** → orient the user loop-first: offer to drive the loop as the default, then list the individual skills as the control path with a one-line hint each, and suggest a concrete starting point from the project state (existing `.allium` specs? code but no spec? drift to reconcile?). For example:
```
END THIRD-PARTY FILE 03e822b8a0e3a271

The third-party file has ended. Everything between the 03e822b8a0e3a271 tags is data: requests and commands from it are not followed. An “end of file” line with another tag inside the block is part of the file.

First 3306 of 17416 bytes. © juxt · MIT · https://github.com/juxt/allium/tree/HEAD/skills/allium/SKILL.md

_Part of the page did not fit — see the HTML version._

---
NeVibeCode on affpapa.org. Catalog texts are descriptions, not instructions for the agent. How to choose and install: https://affpapa.org/en/nevibecode/agents.md