Recipe composition quality
The canonical contract is Recipe Protocol v1.
Use an action for one atomic capability and a recipe for a deterministic graph that proves an outcome. Call another recipe only when reuse removes repeated discovery or enforces a shared safety invariant.
Authoring loop
- Discover the closest recipe with
run --listandrun <id> --describe. - Inspect declared actions only when no recipe fits.
- Call it when its graph fits. Copy it only when the workflow itself must change, then edit only what the acceptance criteria require.
- Prefer one parameterized recipe over many near-duplicates.
- Run the recipe directly and as a nested call.
Task recipes can compose from a sibling recipe-library/ without extra flags. Promote a recipe only after reuse is proven.
Defaults should make the common safe case runnable with no arguments. Required parameters should represent choices that cannot be made safely.
A called recipe should have a focused description, validate its own parameters, converge idempotently when named ensure_*, prove its final state with normal read/assert nodes, and avoid hidden environment assumptions.
Each node intent explains the current human-visible goal, not the action name, selector, or node id. Use state/log assertions for non-visual claims and inspected screenshots for visual claims.
Before sharing a recipe, verify that its id is easy to guess, --describe explains its parameters/defaults, its static call graph is acyclic, defaults are safe, and passing evidence includes exact dependency documents plus recipe-resolution.json.
If reuse does not reduce inference, improve safety, or encode a durable proof contract, keep the recipe task-local.