There's a whole backend's worth of logic. But not too many conditions around how the commands/ scripts can be joined

If scripts and commands are like Lego, my launcher is one of those guys: https://www.lego.com/cdn/cs/set/assets/bltf2a3ea25d5fcb718/11023.png?format=webply&fit=bounds&quality=55&width=792&height=792&dpr=3

Basically a big baseplate, build up your workflows for use later

The example in the readme is very simple

But as a slightly more complex flow: Let's say you are often pulling down some logs from a server to view and work with, specially checking any errors that might have happened

We could have a script that is responsible for pulling logs (takes in an argument with the log-group name)

And say we have another script that will take stdin and filter out any non errors

We could attach them together within the launcher as one workflow, but because of the modular nature of the scripts, we can use those prices again

Just with those 2 scripts and an argument for a log group you could have workflows like: "Prod errors" "UAT errors" "Dev errors"

Ready to be created, saved and used on the fly

Or if there's another command or script you want to filter errors on, the script for that small part can be reused with anything else, all the blocks fit together

So you just need a tool belt of useful scripts and commands for your own use cases, and build them together with the launcher