What the terse style actually is
a2a.terse.v1 is a house style for authoring agent-to-agent YAML artifacts -- tools, tasks, routines, and manifests -- optimized for two things at once: being cheap to parse and cheap to read. "Terse" is not a vague aesthetic preference here; it is enforced structurally by fixing the artifact to exactly four top-level keys and penalizing anything that restates structured data as prose.
The four keys
- inputs -- named, typed parameters, required/optional made explicit. A caller should never have to infer an artifact's input shape from its step descriptions.
- outputs -- named, typed results. Same discipline as inputs: declared, not described.
- steps -- an ordered list of short, single-clause actions. Any branching or looping is made explicit in the step list rather than buried in a paragraph.
- eval -- the self-eval tail: a trailing array of assertions the artifact makes about its own output, meant to be executed by a runtime before the task is considered done.
Nothing else belongs at the top level. A terse artifact that needs more structure than these four keys provide is a signal the artifact should be split, not that the style should be extended.
Why a self-eval tail
Most YAML tool-spec styles stop at describing what a tool does. The terse style's distinguishing move is requiring every artifact to also carry how a runtime can check that it did the right thing -- correctness becomes part of the artifact instead of an externally maintained test suite that can drift out of sync with the spec it's meant to verify.
See also: how rubric.md grades a candidate artifact against this style, and the live catalog of both halves.