This mostly looks fine to me! However, I have some questions about the design:

• What's the use-case for more than one metadata attribute?
• Should we allow the metadata attribute to take a list of strings, instead of a single string? I think the main reason to do this is that it's more compact than multiple metadata attributes, since it's one line instead of multiple lines. We should think about this now, since it's a breaking change for JSON deserializers if metadata changes from a string to a list of strings.

This mostly looks fine to me! However, I have some questions about the design:
What's the use-case for more than one metadata attribute?

I wonder if you're asking about metadata being repeatable or a more generic question about attaching multiple metadata items per recipe. If it's the latter I envisioned multiple tools, each with their own metadata, which can at the same time use just so there needs to be some way to specify multiple items. The other approach would be to have the metadata attribute take multiple strings and expose that via JSON as a metadata array.

(As a practical example, I'm currently parsing pragma-like comments from recipes using JavaScript and there are multiple different ones in one recipe).

I initially chose "repeatable" as I had key-value structure for metadata in mind (where each external tool would use their different key and they could coexist) but stopped half-way as I was wondering if this is a bit too complex.

Should we allow the metadata attribute to take a list of strings, instead of a single string? I think the main reason to do this is that it's more compact than multiple metadata attributes, since it's one line instead of multiple lines.

I think it's a reasonable approach and I'm happy to adjust the code if we settle on this.

We should think about this now, since it's a breaking change for JSON deserializers if metadata changes from a string to a list of strings.

Totally agreed. The PR didn't take too much time and I think having something concrete is a great conversation starter.

Thanks for your time! 👋

Let's allow a list of strings, as well as allowing the metadata attribute to appear multiple times. I don't see any issue with it, and it allows metadata authors flexibility in how they'd like to structure their metadata.

I don't see any issue with it, and it allows metadata authors flexibility in how they'd like to structure their metadata.

Good idea.

I've left the constraint to require at least one argument in the [metadata] attribute as it seemed weird to have an argumentless node like that.

The code could be restructured a bit because structure-wise what [metadata] takes looks identical to the Interpreter struct (one required "command" and a set of arguments). I've kept the code simple for now, unless you see value in adjustments.

LGTM!