Skip to content

Templating

Polytoken’s facets, subagents, and skills are built from templates. You author them in the same templating system Polytoken uses to build its own prompts and behavior, so its defaults and your changes are the same kind of thing.

Most of the time you will not need to touch any of it. Building a dependable harness on top of a coding agent is work I have done before; ed3d-plugins is my earlier effort at it. Polytoken makes that the default. When you do need the harness to behave a certain way, you extend it in the same templates Polytoken ships.

Every file you author opens with a YAML front-matter block, the same convention other tools use. Front matter has two layers. The conventional keys, such as name and description, sit at the top level where any harness reads them, so they carry across tools. Anything specific to Polytoken lives under one key, polytoken: the model a facet runs on, the tools a subagent gets, a skill’s tags. The presence of that key also marks the file as Polytoken’s, which is what makes templating available.

Which keys are legal, both at the top level and under polytoken, depends on the file type. The Template Reference lists them. AGENTS.md files work a little differently; see Project Context.

The body of an authored file, everything below the front matter, is a template. Polytoken renders it with MiniJinja, which follows Jinja2’s syntax closely. The everyday constructs, including variables, conditionals, loops, and filters, are Jinja2-compatible. The MiniJinja documentation covers the details and the few advanced features it leaves out.

Polytoken renders the body before the model sees it, so your instructions can adapt. A facet can tell a vision model one thing and a text-only model another:

{% if supports_vision %}
You can read images the user shares. Inspect them directly.
{% else %}
You cannot see images. Ask the user to describe what they show.
{% endif %}

Everything a template can read, every variable and the functions Polytoken adds, is in the Template Reference.

Templates catch typos at render time. Referencing a variable that does not exist raises an error rather than rendering blank, so a broken prompt never reaches the model.

On top of standard MiniJinja, Polytoken adds a few functions that query the current setup. has_tool, has_skill, and has_mcp check whether something is available this turn. is_model_variant checks the model family. get_tool pulls a tool’s details. With them, a template can include instructions only when the relevant tool or skill is available. The full list, with signatures, is in the Template Reference.

Facets, subagents, and skills all render this way, so everything on this page applies to each of them. AGENTS.md files are not rendered as templates by default; see Project Context.