P4 · Skill authoring

$ARGUMENTS Variable

Define invocation arguments and map accepted flags to behavior.

Editorially reviewedSource unconfirmed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A teaching catalog checker accepts a file path and –json for machine consumption. $ARGUMENTS availability/injection is host-specific, so define the argument contract first.

Mechanism

Specify catalog-check <path> [--json] with one existing permitted file and format-only flag. Define default text/JSON shape, success/invalid states, missing paths/unknown flags. Use host parsing with separate values, not executable strings. Check positive/negative inputs and use actual mechanisms when no such variable exists.

Bad example

Use $ARGUMENTS for any directory, guess missing paths/unknown flags and execute parameter text as shell.

Good example

Parse the teaching usage: missing path, unknown flag or out-of-scope target reports usage/stops before reads. --json yields contracted machine output and default is text. Arguments stay data; verify host variable syntax separately.

Why the change matters

Contracts connect invocation, scope and output, reducing guesswork. Isolating host mechanics avoids treating variable-like text as universal execution capability.

Observable expectation

Teaching permitted file/–json returns parseable output; missing path/–jsno reads nothing; space-containing paths remain one argument. Unimplemented interfaces are examples, not passing executions.

Limits

No frozen source is confirmed and catalog-check is fictional. Existence is not permission; parsing/quoting varies. $ARGUMENTS is not built into every agent and its name cannot promise injection.

Sources and evidence

Source text has not been located. This method meets the editorial criteria; its examples are independent teaching constructions.

Read the editorial criteria