Recipe anatomy

Every workflow in the catalog lives in its own directory under recipes/, and every directory contains the same set of files:

recipes/<workflow-id>/
├── recipe.yml
├── workflow.md
├── README.md
├── checklist.md
├── output.schema.json
└── examples/
    ├── input.md
    └── expected-output.md

Here is what each file is for:

• recipe.yml holds the metadata: title, summary, domain category, execution mode, inputs, outputs, safety rules, and which agents the recipe is compatible with. It is validated against a strict JSON Schema, so unknown fields, invalid values, malformed IDs, invalid dates, and missing files all fail validation. Schema version 4 keeps domain category separate from execution_mode; an autonomous recipe also carries a strict autonomy contract.
• workflow.md is the workflow itself and the single source of truth. Every workflow follows the same fifteen sections, from Objective through Example, so once you have read one recipe you can find your way around all of them.
• README.md explains the recipe to a human who is deciding whether to use it.
• checklist.md is a compact version of the steps, made for ticking off during execution.
• output.schema.json describes the shape of the artifact the workflow is expected to produce.
• examples/ contains a complete synthetic input and its matching expected output, so you can see what good evidence looks like before running anything.

Adapter compatibility and verification status live in the metadata, not in the prose. That separation lets you tell portable content apart from tested claims about external tools.

Execution mode is also separate from verification. autonomous means the workflow is designed to continue after upfront authorization, while the execution stage records whether a named external agent actually demonstrated that behavior.