Agent skill · product strategy · juxt
elicit
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.
Why this skill is useful
Provides structured templates and domain-specific questions for eliciting software specifications that the AI wouldn't generate on its own.
What it needs
About 12k tokens when loaded. Last updated 2026-07-22. 443 stars on the source repository.
What this skill does
Elicitation This skill guides you through building Allium specifications by conversation. The goal is to surface ambiguities and produce a specification that captures what the software does without prescribing implementation. Scoping the specification Before diving into details, establish what you are specifying. Not everything needs to be in one spec. Questions to ask first "What's the boundary of this specification?" A complete system? A single feature area? One service in a larger system? Be explicit about what is in and out of scope. "Are there areas we should deliberately exclude?" Third-party integrations might be library specs. Legacy features might not be worth specifying. Some features might belong in separate specs. "Is this a new system or does code already exist?" If code exists, you are doing distillation with elicitation. Existing code constrains what is realistic to specify. Documenting scope decisions Capture scope at the start of every spec: The version marker (-- allium: N) must be the first line of every .allium file. Use the current language version number. Finding the right level of abstraction Too concrete and you are specifying implementation. Too abstract and you are not saying anything useful. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills juxt/elicit