Template schemas

cxg 1.3.0 parses three template formats with three separate parsers. They share no structure, and the failure when you use the wrong one is silent — the engine loads the file and ignores what it does not recognise.

You are writing	Schema	Read by
A template in any of the 11 non-YAML languages	Annotation header	src/engine/common.rs
A declarative .yaml / .yml template	YAML schema	src/engine/yaml/mod.rs
A JavaScript probe for cxg pentest	Pentest JS probe	pentest/js_engine.py

The formats do not mix

The YAML engine deserializes the document and never looks at comments, so an # @id: header in a .yaml file is inert. The annotation parser reads only the first 50 lines of a file for @field: comments and never parses YAML, so a matchers: block in a .py file is inert. Neither case is reported as an error.

Which schema applies to a file

Each engine claims files by extension. This is the whole of that mapping:

Engine	Files	Schema
c	.c	Annotation header
cpp	.cpp, .cc, .cxx	Annotation header
go	.go	Annotation header
java	.java	Annotation header
javascript	.js, .mjs	Annotation header
perl	.pl	Annotation header
php	.php	Annotation header
python	.py	Annotation header
ruby	.rb	Annotation header
rust	.rs	Annotation header
shell	.sh	Annotation header
yaml	.yaml, .yml	YAML schema

The pentest probe format is not in that table on purpose: those probes are not loaded by the template engine at all. cxg pentest runs them inside an authenticated browser context, and a .js file in a template directory is read by the javascript engine above instead — a different format with a different contract. See Pentest JS probe.

Writing one

Start from the skeleton cxg ships for the language: cxg template skeleton, then check it with cxg template validate. The guide Write your first template walks the whole path.