The Nagios idiom check_command name!arg1!arg2 names one command template once and instantiates it with different positional arguments per host or service. jaque keeps the idiom: a top-level commands map holds the templates, a command check names one and supplies args, and $ARGn$, $USERn$ and $_HOSTxxx$/$_SERVICExxx$ macros expand exactly as an operator coming from Nagios expects. This is how fifty services that differ in one flag share one line. The only thing dropped is the ! splitting, which belongs to the importer, not the schema.

1. Define a command once

resources: USER1: "/usr/lib/nagios/plugins"

commands: check_creds: line: "$USER1$/check_creds.sh --user $ARG1$ --password $_HOSTPASSWORD$"

resources plays the role of Nagios's resource.cfg: $USERn$ lookups only, so the schema requires every key to match USER<digits>; anything else is a config error rather than a silently unreachable value. It keeps paths and credential-adjacent strings out of the main object files, as it always did. commands maps a name to a template line. $ARGn$ are positional arguments supplied at the call site; $_HOSTxxx$ and $_SERVICExxx$ expand a host's or a service's vars, whose keys the schema forces to uppercase so the CUE reads the way the macro reads.

2. Instantiate it per object

hosts: gw: {
	address: "192.168.1.1"
	vars: PASSWORD: "s3cr3t"
	check: {type: "icmp", host: "192.168.1.1"}
	services: creds: check: {
		type:    "command"
		command: "check_creds"
		args:    ["jaque"]
	}
}

command is a key into the top-level commands map; args fills $ARG1$, $ARG2$ and so on, the same argument list Nagios passed after the !s. A command naming a key that is not in commands is a config error.

3. Two expansion modes

A template is shell: false by default: after macro expansion the resolved line is tokenized and executed directly, like a legacy check, with no shell in between. shell: true hands the whole resolved line to /bin/sh -c instead. That is the mode for a command that pipes or redirects, at the usual cost: quoting is the caller's problem, and so is everything a shell does with a $ or a ; it was not expecting.

commands: check_shell: {
	line:  "echo $_SERVICEMESSAGE$ $ARG1$"
	shell: true
}

Once resolved, a command check runs exactly like a legacy exec plugin: the same exit-code protocol, the same perfdata grammar, the same process-group kill on timeout.

4. Security considerations

With shell: false, an args value or a vars value is one argument vector element and cannot become a second command. With shell: true, every macro value is interpolated into a line /bin/sh will parse: a vars entry or an args element containing shell metacharacters is a command injection, and the template author is the one who accepted that by choosing the mode. Use shell: true only for templates whose every macro value the operator controls. resources and vars are plain text in the config file and are expanded into process argument vectors, where any user on the host can read them from the process table.