The key insight here seems to be that you usually need to specify the tasks for a repo twice: once in your task runner (Makefile, package.json, bazel BUILD file) and then again in your readme so that people can learn what custom tasks exist and what they do.

This tool tries out the idea that maybe if the readme was structured the right way, it could double as the task runner specification. That way, even if you don't have the tool installed (maybe because you're browsing the repo online instead of in your editor) you can still see what the tasks do alongside their instructions

TIL Make is the Zoidberg of technologies.

Also non trivial Makefiles quickly become an unintelligible mess of rules both explicit and implicit, and an endless stack of variables that never feel fully defined.

Make is not actually that great of a task runner, but the syntax is easy and its ubiquitous.

I created a tool that allows you to define tasks in the easy make-style, but is purpose-build to be a task runner:

* https://github.com/TekWizely/run

Why not both?