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’srequired_clismap is the authoritative source for version floors; when a binary appears there, we emitname (floor). Falling back tocli-tools.yamlcovers third-party tools without a per-skill floor. Unknown names surface a typed error so drift audit’scli_refrejection 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 omitsname.- state_
out state_out(domain, topic=, repo=)— emit either anagent-out path-forinvocation (moderuntime) or a literal resolved path (modeliteral), driven by the current skill’sstate_out_mode.
Structs§
- Helper
Context - Snapshot of the resolution context that all four helpers share for a
single skill’s render. Cloned via
Arcinto each helper closure.
Functions§
- register_
all - Register every renderer helper on
enginewith the sharedctx.