Propagate
Turn an Allium behavior spec into complete tests—boundary, property, and state-machine coverage mapped to your codebase.
Overview
propagate is an agent skill most often used in Ship (also Validate scope, Build backend) that generates tests from Allium specifications so every spec obligation has a corresponding test.
Install
npx skills add https://github.com/juxt/allium --skill propagateWhat is this skill?
- Generates tests from Allium specs with deterministic obligation completeness
- Surface mode targets API, UI contract, and integration boundary tests
- Uses allium plan and allium model JSON for obligations and domain shapes
- Bridges spec constructs to implementation with property-based and state machine tests
- Falls back to manual taxonomy from test-generation.md when CLI is unavailable
Adoption & trust: 1.3k installs on skills.sh; 390 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a formal Allium spec and code, but no systematic way to ensure every declared behavior, boundary, and state transition is covered by tests.
Who is it for?
Builders using Allium specs who want spec-to-test propagation instead of hand-writing cases from a mental checklist.
Skip if: Greenfield ideas with no `.allium` spec, or teams that only want exploratory manual QA without specification linkage.
When should I use this skill?
When the user wants to propagate tests, generate test files from a spec, create property-based or state machine tests, or check coverage against spec obligations.
What do I get? / Deliverables
You get project-convention test files aligned to Allium test obligations, including surface boundary coverage and deeper property or state-machine tests where the spec demands them.
- Generated test files in project conventions
- Coverage mapping to spec obligations
- Surface, property, or state-machine test suites per mode
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship/testing because the skill's primary output is generated test suites against obligations. Propagation maps every spec construct to test obligations and implements them in project test conventions.
Where it fits
After drafting a `.allium` API contract, propagate surface boundary tests before implementation hardens.
Map domain model entities from `allium model` into unit and integration tests as handlers land.
Run propagation to close gaps between `allium plan` obligations and the existing test suite.
Re-propagate when the spec changes so regression tests track new state transitions.
How it compares
Use instead of asking the agent to invent tests from code alone—obligations come from the spec and Allium plan output.
Common Questions / FAQ
Who is propagate for?
Solo and indie developers practicing specification-driven development with Allium who need automated, complete test generation tied to spec constructs.
When should I use propagate?
In Validate (scope) while locking behavior in a spec, in Build (backend) as APIs stabilize, and in Ship (testing) to propagate obligations into boundary, property, and state-machine tests.
Is propagate safe to install?
Review the Security Audits panel on this Prism page; the skill may invoke Allium CLI and write test files—confirm tool access and repo scope before running.
SKILL.md
READMESKILL.md - Propagate
# Propagation 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. ## Prerequisites Before propagating tests, you need: 1. **An Allium spec** — the `.allium` file describing the system's behaviour 2. **A target codebase** — the implementation to test 3. **Test obligations** — from `allium plan <spec>` (JSON listing every required test) 4. **Domain model** — from `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`](../allium/references/test-generation.md). ## Modes ### Surface mode 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: 1. **Exposure tests** — verify each item in `exposes` is accessible to the specified actor, including `for` iteration over collections 2. **Provides tests** — verify operations appear when their `when` conditions are true and are hidden otherwise, including when the corresponding rule's `requires` clauses are not met 3. **Actor restriction tests** — verify the surface is not accessible to other actor types 4. **Actor identification tests** — verify only entities matching the actor's `identified_by` predicate can interact; for actors with `within`, verify interaction is scoped to the declared context 5. **Context scoping tests** — verify the surface instance is absent when no entity matches the `context` predicate 6. **Contract obligation tests** — verify `demands` are satisfied by the counterpart, `fulfils` are supplied by this surface, including all typed signatures 7. **Guarantee tests** — verify `@guarantee` annotations hold across the boundary 8. **Timeout tests** — verify referenced temporal rules fire within the surface's context 9. **Related navigation tests** — verify navigation to related surfaces resolves to the correct context entity ### Spec mode Walks the full test obligations document. Use when the user wants comprehensive test coverage for the entire specification. Categories from the test-generation taxonomy: - **Entity and value type tests** — fields, types, optional (`?`) null handling, `when`-clause state-dependent presence, relationships, join lookups, equality - **Enum tests** — comparability across named enums, membership tests, inline enum isolation - **Sum type tests** — variant fields, type guards, exhaustiveness, creation via variant name, base `.created` trigger narrowing - **Derived value and projection tests** — computation, filtering, `-> field` extraction, parameterised derived values, `now` volatility, collection operations - **Default instance tests** — unconditional existence, field values, cross-references between defaults - **Config tests** — defaults, overrides, mandatory parameters, expression-form defaults, qualified references, config chains - **Invariant tests** — post-rule verification, edge cases, implication logic, entity-level invariants - **Rule tests** — success/failure/edge cases, conditionals (ensuring `if` guards read resulting state), entity creation, removal, bulk updates, rule-level `for` iteration, `let` bindings, chained triggers - **State transition tests** — valid/invali