I think this is a really really really good idea :).
If I were doing this, I’d make it very “code-first” - meaning, make it primarily about code rather than explanatory prose. I’d have a bit of prose explaining what the recipes are doing and how, but mostly let the code speak for itself.
Relatedly I’d be keen to make it very easy to interact with the recipes. For me it’s much easier to understand what a recipe is for when I can see and interact with the result, compared with reading the description of it. So I’d present that front and centre.
I’d also be wary of centering it on the Wiki. I think it would be good for the “master copy” of the recipes to live in GitHub, so they’re easy for people to fork and modify. But then duplicating code chunks into Wiki pages is going to make it hard to maintain. I have done this for “Your second WebExtension” and to be honest it’s a bit of a nightmare keeping the code in the article in sync with the GitHub code.
So (again, this is just my opinion) I’d make the thing live in GitHub and the Wiki side would just be a catalogue of the examples, listing things like name, description, possibly screenshot.
It’s not an exact analogy, but to present examples of WebExtensions, the primary asset is the repo (https://github.com/mdn/webextensions-examples). I then have a single index page in the Wiki, that’s generated using a KumaScript macro from a metadata file that also lives in the repo. I also have links from individual APIs to relevant examples, that are also generated by a KumaScript macro from the same metadata file.
This means that I only have to maintain the examples in the GitHub repo, and I know that the pointers in the Wiki will be kept up to date.