npx claudepluginhub juxt/claude-plugins --plugin alliumThis skill uses the workspace's default tool permissions.
This skill generates tests from Allium specifications. Propagation is how plants reproduce from cuttings of the parent: the spec is the parent, the tests are the offspring.
Integrates Allium behavioral specs with /core:agent-loop workflow. Use to attach specs to epics, propagate tests before TDD, or check spec/code divergence after CI.
Provides syntax and structure for authoring and reading .allium files, a formal language specifying domain-level software behavior for integration test generation.
Generates Gherkin BDD feature files from structured use case flows using Clark's UC2.0-to-Gherkin algorithm. Analyzes test coverage completeness against use case steps.
Share bugs, ideas, or general feedback.
This skill generates tests from Allium specifications. Propagation is how plants reproduce from cuttings of the parent: the spec is the parent, the tests are the offspring.
Deterministic tools guarantee completeness (every spec construct maps to a test obligation). You handle the implementation bridge: correlating spec constructs with code, generating tests in the project's conventions.
Before propagating tests, you need:
.allium file describing the system's behaviourallium plan <spec> (JSON listing every required test)allium model <spec> (JSON describing entity shapes, constraints, state machines)If the CLI tools are not available, derive test obligations manually from the spec using the test-generation taxonomy in references/test-generation.md.
Generates boundary tests from surface declarations. Use when the user wants to test an API, UI contract or integration boundary.
For each surface in the spec:
exposes is accessible to the specified actor, including for iteration over collectionswhen conditions are true and are hidden otherwise, including when the corresponding rule's requires clauses are not metidentified_by predicate can interact; for actors with within, verify interaction is scoped to the declared contextcontext predicatedemands are satisfied by the counterpart, fulfils are supplied by this surface, including all typed signatures@guarantee annotations hold across the boundaryWalks the full test obligations document. Use when the user wants comprehensive test coverage for the entire specification.
Categories from the test-generation taxonomy:
?) null handling, when-clause state-dependent presence, relationships, join lookups, equality.created trigger narrowing-> field extraction, parameterised derived values, now volatility, collection operationsif guards read resulting state), entity creation, removal, bulk updates, rule-level for iteration, let bindings, chained triggerstransitions_to vs becomes semanticswithin scoping, context scoping, related navigation@invariant honouring, demands/fulfils directionwhen set, absence obligations on leaving, no obligation when moving within or outside, convergent transitions all set the field, guard required to access when-qualified fields, derived value when inference via input intersection.created()) to each terminal state, following a valid path through the transition graph. Each test exercises a complete lifecycle.allium analyse identifies potential deadlocks, generate tests that put the entity in the stuck state and verify whether it can progress.If allium analyse is available, use its findings to prioritise test generation. A missing_producer or dead_transition finding indicates a gap worth exercising with a test. A deadlock finding should generate a test documenting that the entity cannot escape the stuck state. Consult actioning findings for the finding type taxonomy.
For deterministic obligations: field presence, enum membership, transition validity, surface exposure, state-dependent field presence and absence. These are standard unit/integration tests.
For invariants and rule properties. Each expression-bearing invariant becomes a PBT property:
Use the project's PBT framework:
| Language | Framework | Discovery |
|---|---|---|
| TypeScript | fast-check | package.json |
| Python | Hypothesis | pyproject.toml |
| Rust | proptest | Cargo.toml |
| Go | rapid | go.mod |
| Elixir | StreamData | mix.exs |
Fall back to assertion-based tests if no PBT framework is present.
For entities with status enums. When a transition graph is declared, walk every path through the graph. When no graph is declared, derive valid transitions from rules.
when clausesState machine tests require an action map: a function per transition edge that takes the entity in the source state and produces it in the target state by calling the actual implementation code. Without this map, the test framework can describe valid paths through the graph but cannot execute them.
To build the action map:
requires clauses), invokes the code, and returns the entity in the target state(from_state, to_state) keyOnce the map is built, the PBT framework can walk random valid paths: start at any non-terminal state, pick a random outbound edge, apply its action, check all entity-level invariants, repeat. The path length and starting state are generated randomly. This is the fullest expression of the spec's transition graph as a test.
You correlate spec constructs with implementation code, the same way the weed skill correlates for divergence checking.
Map surfaces to their implementation:
Discover the mapping by reading the codebase. Look for naming patterns, route definitions and handler registrations.
For each rule in the spec:
Temporal triggers (deadline-based rules) need a controllable time source in the test. If the implementation uses wall-clock time (Instant.now(), System.currentTimeMillis()), the test cannot reliably position itself before, at or after a deadline.
Before attempting temporal tests, check whether the component accepts an injected clock or time parameter. Common patterns: a Clock parameter on the constructor, an epoch-millisecond argument on the method, a TimeProvider interface. If the seam exists, inject a controllable time source. If it does not, flag this as a test infrastructure gap: the temporal tests cannot be generated until the component supports time injection. Do not attempt to test temporal behaviour by sleeping or racing against wall-clock time.
When a rule emits a trigger that another spec's rule receives (e.g. the Arbiter emits ClerkReceivesEvent, the Clerk handles it), testing the chain requires multiple components wired together.
Before generating cross-module tests:
Cross-module tests are integration tests by nature. They verify that the spec's trigger chains are faithfully implemented across component boundaries. Prioritise them after single-component tests are passing.
When exploring the codebase, note which spec obligations are already covered by existing tests. An existing integration test that exercises the happy path from event submission through to acknowledged output already covers multiple rule_success obligations and the end-to-end scenario.
When an existing test covers a spec obligation, reference it rather than generating a duplicate. The propagate skill's value at the integration level is verifying that coverage is complete against the spec's obligation list, identifying gaps, and generating tests to fill them. Replacing working hand-written tests with generated equivalents adds no value.
Deferred specifications are fully specified in separate files. When the target codebase doesn't include the deferred spec's module, generate a test stub with a placeholder:
// TODO: deferred spec — InterviewerMatching.suggest
// This behaviour is specified as deferred. Provide a mock or skip.
elicit or distill skill to develop it further before propagating tests. A spec with rules and surfaces enables the full test taxonomy including data flow chain tests and reachability tests.allium plan output or manual derivationallium model output or manual derivationBefore generating tests, establish:
__tests__/, tests/, etc.)When generator specs are available, use them to produce valid test data:
when clauses (e.g. a shipped Order has tracking_number and shipped_at populated; a pending Order does not)