Templating

Polytoken’s facets, subagents, and skills are built from templates. Polytoken renders both shipped definitions and your custom definitions with the same template syntax.

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.

Frontmatter

Every file you author opens with a YAML frontmatter block, the same convention other tools use. Frontmatter 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.

Templating with MiniJinja

The body of an authored file, everything below the frontmatter, 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.

Polytoken’s template functions

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.

Where templating applies

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.

Including other files

Two mechanisms pull content from other project files into a facet or subagent definition. They differ in when the content is read and how it is treated.

@file references are resolved at load time, before Jinja directives run. When Polytoken loads a definition file, it scans for @path/to/file references and inlines the raw file content in place. That content is treated as literal text, not as a template, so any {{ }} or {% %} markers inside an included file pass through unchanged. Use @file when you want to share static text across definitions without any templating.

transclude("path.md") is a Jinja function, so it runs at render time. The included file is itself rendered as a template with the current context, so {{ facet_name }} inside a transcluded file expands. File paths resolve relative to the directory of the file that contains the transclude() call, and are confined to that directory subtree: ../ escapes are rejected. transclude() also accepts polytoken:// addresses for shipped prompt fragments. See the Template Reference for the full signature.