What this looks like in practice

Type /allium in Claude Code and Allium examines your project, then offers to distill from existing code or build a new spec through conversation. If you already know which mode you want, you can go directly: /allium:elicit builds a spec through structured conversation, /allium:distill extracts one from existing code.

Claude Code
> /allium
✻ I can see you have an existing codebase with authentication, billing and a team management module, but no Allium spec yet. I can distill from code to capture what your implementation currently does, or start from intent to build a spec through conversation. Which would you prefer?
> Distill from code. Start with the authentication module.
✻ I've read through auth/. I can see login, password reset, session management and role-based access. I've drafted an initial spec at auth.allium with 4 entities and 9 rules. A few things I want to flag:
✻ Your login handler in auth/login.py:34 allows unlimited retries for users with an internal role. Is that intentional, or should the lockout policy apply to everyone?
> That's a bug. Lockout should apply to everyone. Update the spec and fix the code.

The elicitation guide and distillation guide cover both approaches in detail.

Allium surfaces implications you missed

A booking platform wants to add self-service rescheduling.

Claude Code
> Customers want to reschedule appointments through the app. Add a reschedule option to the booking detail page.
✻ Your Allium has a CancellationFee rule: cancellations within 24 hours of the appointment incur a charge. A reschedule is functionally a cancellation followed by a new booking, so rescheduling a same-day appointment would trigger the fee.
✻ Should rescheduling be exempt from the cancellation fee, follow the same 24-hour policy as cancellations or have its own separate policy?
> Rescheduling should be free if it's to another slot in the same week. Otherwise the cancellation policy applies.
✻ When you say same week, do you mean the calendar week (Monday to Sunday) or within seven days of the original appointment? An appointment on Saturday rescheduled to the following Tuesday would be within seven days but cross a calendar week boundary.
> Within seven days of the original appointment.

Without Allium, the LLM would have implemented a straightforward reschedule endpoint. The behavioural model caught that a same-day reschedule triggers the cancellation fee, and then pushed the developer to define “same week” precisely enough to implement.

Knowledge persists across sessions

A developer starts a new session days later, working on a different feature.

Claude Code
> Add a free trial. New subscribers get their first month at no charge.
✻ Your Allium has a constraint here. SubscriptionCreated ensures a payment is processed and InvoiceGenerated requires invoice.amount > 0. A free first month would need to bypass both.
✻ Should the trial skip invoice generation entirely, or create a zero-value invoice for the audit trail? And should the PaymentMethod still be captured upfront, or only when the trial converts?
> Create a zero-value invoice and capture the payment method upfront.

The developer never mentioned invoicing or payment method capture. The Allium did, from a session that ended days ago. Without it, the LLM would have implemented the trial with no awareness of these constraints, and the gaps would have surfaced in production.

Allium grounds a design conversation

A developer asks for a straightforward feature.

Claude Code
> Add a bulk discount. Orders over 50 units get 15% off.
✻ Your Allium already has a LoyaltyDiscount rule that gives returning customers 10% off orders over £100. A 55-unit order from a loyal customer could qualify for both. Your OrderTotal derivation doesn't specify how multiple discounts interact.
✻ Should discounts stack (10% + 15% = 25%), apply the better of the two (15%) or compound (15% then 10% on the remainder)? And should the bulk discount apply before or after the loyalty calculation?
> Apply the better of the two. They shouldn't stack. Update the Allium first, then adjust the pricing logic.

Without Allium, the LLM would have added the bulk discount with no awareness of the loyalty programme. The specification surfaced a pricing interaction the developer never mentioned, and the conversation arrived at an explicit discount precedence rule.

Distillation catches drift

A developer asks the LLM to check whether the code still matches the Allium.

Claude Code
> Can you check whether our publishing workflow matches the Allium?
✻ I found a divergence. Your Allium says ArticlePublished requires article.status = approved, meaning every article goes through editor review before publication. But publishing/views.py line 82 skips the approval check for users with role = senior_author. The Allium has no such exception.
✻ Either the code introduced a shortcut or the Allium is incomplete. Which should we trust?
> That was a quick fix during a deadline. The approval step matters. Fix the code to match.

Code and intent diverge silently over time. Allium gives the LLM something to check against, turning “does this look right?” into a concrete comparison with a definitive answer. See the distillation guide for a structured approach to catching drift, and the elicitation guide for building specs from conversations like the ones above.