A fire dispatch center has a custom slash command that produces an after-action summary for a single incident. Today the incident number is hard-coded and shift leads copy the file and edit it for each call, which has already caused one summary to be filed against the wrong incident. The architect wants one command definition that accepts the incident number when it is invoked. What should the command use?

The failure in the dispatch center is not a modeling problem but a parameterization problem. A command that hard-codes a value forces a duplicate-and-edit cycle, and every duplicate is another chance to edit the wrong field under time pressure. The architectural fix is to make the varying value an input to one reviewed definition.

Slash commands are parameterized by substitution. $ARGUMENTS expands to everything the operator types after the command name, and positional forms let a command pick out individual values when it needs more structure. One definition then serves every incident, collapsing the near-identical copies into a single file, and pairing the placeholder with an argument-hint frontmatter field tells the shift lead exactly what to type.

There is no variables: frontmatter block that interrogates the operator after the command starts, since command metadata covers description, argument hints, allowed tools, and model selection; an @ reference inlines a specific file by path and cannot infer which incident the operator has in mind; and the environment-variable option rests on a false premise, because slash commands do accept input at invocation time, which is the whole purpose of the placeholder.

Exam caveat: substitution is textual, so whatever the operator types lands in the prompt verbatim and a mistyped incident number yields a confidently wrong summary just as reliably as a copied file did. Operational check: invoke the command with a deliberately malformed incident number and confirm the definition validates or echoes it back for confirmation before any after-action text is drafted.