NorthStar prompt templates are plain strings with variable placeholders embedded directly in the content. When you compile a template, the SDK replaces every placeholder with the value you supply — and if any placeholder has no corresponding value, it raises aDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/sidmanale643/northstar/llms.txt
Use this file to discover all available pages before exploring further.
ValueError immediately rather than leaving a gap in the rendered output. The template engine supports two placeholder styles so you can use whichever feels natural for your team or mix them freely in a single template.
Supported template syntax
Both placeholder styles resolve to the same underlying mechanism — a regex scan followed by string substitution — and can be used together in the same template.The single-brace
{variable} pattern only matches identifiers — it will not
accidentally consume Python format strings that use positional arguments like
{0} or advanced format specs like {value:.2f}. Only plain alphabetic
variable names ([a-zA-Z_][a-zA-Z0-9_]*) are treated as template variables.Compilation API
northstar.compile_prompt(prompt_version, variables)
The module-level compile_prompt function (exported from northstar as an alias for prompts.compile) renders a PromptVersion with a dict of variable values and returns a CompiledPrompt.
CompiledPrompt.bind(variables, span)
bind() is a context manager on CompiledPrompt that compiles the underlying template with the given variables and, when the block exits, records a prompt link on the target span. This is the preferred way to associate a prompt version with a model call span when you need explicit control over which span receives the link.
client.pull_prompt() returns a CompiledPrompt pre-loaded with the resolved PromptVersion. Call bind() on that object to render and link it:
span is omitted, bind() automatically picks up the active model call span from the current context — so in most cases you do not need to pass it explicitly:
bind() is both a sync and async context manager — async with prompt.bind(...) works identically in async agent code.CompiledPrompt fields
The UUID of the parent
Prompt this compiled result belongs to.The UUID of the
PromptVersion that was rendered. This is the value stored
in the prompt link on the model call span.The fully rendered template string with all variable placeholders replaced by
their supplied values. Pass this directly to your LLM as the message content.
The original unrendered template string (i.e.
PromptVersion.content).
Stored alongside content so you can always recover the template structure
from the compiled result.The dict of variable values that were substituted during compilation. Stored
in the prompt link payload and visible in the dashboard trace view.
The model identifier hint inherited from the
PromptVersion. Your code can
read this instead of hardcoding the model name in the calling code.The temperature hint inherited from the
PromptVersion.The maximum token limit hint inherited from the
PromptVersion.The
content_hash inherited from the PromptVersion, carried through to
the prompt link so the dashboard can detect content drift between runs.Missing variable behaviour
If any variable referenced in the template is absent from thevariables dict passed to compile_prompt or bind(), the SDK raises a ValueError at compile time — before anything is sent to your LLM:
Variable schema auto-extraction
When aPromptVersion is created — either on the server or locally in code — NorthStar scans the template content and builds a variables list automatically. The extraction logic lives in _prompt_template.py.
extract_variables(template)
Scans the template for both {{ jinja }} and {python} placeholder patterns and returns a sorted list of unique variable names:
variables_schema(template)
Wraps extract_variables and returns the full list of variable descriptor dicts that is stored on PromptVersion.variables:
"string", marked required: True, and have default: None. If the server returns a PromptVersion with an empty variables list, the SDK re-runs variables_schema locally via a Pydantic model validator so the schema is always populated before you call compile_prompt.
render_template(template, variables)
The low-level render function used internally by compile_prompt. Calls extract_variables first to check for missing keys, then performs Jinja-style substitution followed by Python-style substitution on the result:
render_template directly — use compile_prompt or bind() instead.
End-to-end example
The following shows the full pull → bind → record flow, reading the model hint directly from the compiled prompt:prompt_version_id, the content_hash, and the exact variable_values used — making the trace fully reproducible from the dashboard.