Skip to main content

Module helpers

Module helpers 

Source
Expand description

minijinja helper functions registered against a per-skill render pass.

Each helper is constructed from a shared HelperContext that captures everything required for resolution: the source root, the parsed manifest bundle, the active product, and the current skill’s required_clis / state_out_mode. Helpers are stateless beyond this snapshot, so two cold processes registering the same context produce identical output.

Helpers take keyword arguments as a minijinja::value::Kwargs and return a minijinja::Value; the context fed to the renderer lives in IndexMap / BTreeMap per Resolved Decision #9.

Modules§

cli_ref
cli_ref(name) — resolve a CLI reference. The current skill’s required_clis map is the authoritative source for version floors; when a binary appears there, we emit name (floor). Falling back to cli-tools.yaml covers third-party tools without a per-skill floor. Unknown names surface a typed error so drift audit’s cli_ref rejection class fires loud and early.
script
script(path) — resolve a script path to a runtime-portable form tied to the active product. The path argument is the source-tree path of the script (e.g. core/skills/reporting/topic-radar/scripts/topic-radar.sh); the helper translates it into the product’s installed runtime path so rendered SKILL bodies are byte-stable across hosts.
skill_ref
skill_ref(id) — resolve a tracked skill id (<domain>.<skill>) to the product-native invocation name for the active product. Falls back to the canonical id when the per-product entry omits name.
state_out
state_out(domain, topic=, repo=) — emit either an agent-out path-for invocation (mode runtime) or a literal resolved path (mode literal), driven by the current skill’s state_out_mode.

Structs§

HelperContext
Snapshot of the resolution context that all four helpers share for a single skill’s render. Cloned via Arc into each helper closure.

Functions§

register_all
Register every renderer helper on engine with the shared ctx.