Hey,
I haven’t encountered ex_check so far, it looks pretty cool! The video drives the point very clearly, good job!
I’m not really sure to what extent would ex_check benefit from the imperative approach. Base on what I’ve seen, my understanding is that it’s a plug and play tool, and in this case a declarative config makes more sense, because the user really needs to provide facts (e.g. run this, don’t run that), and not the flow. But TBH I didn’t have the time to look at docs or the code more carefully, so perhaps I’m missing some opportunities. As the author and someone who’s so deep in, you’re definitely in a better position to asses this 
There is a bit of overlap, but I can see both libs having their own worth. When it comes to ex_check, It’s cool that people can quickly get some standard checks running, and I quite like how the tool gently informs the developer that there are some other possible checks worth considering.
The tools can also complement each other. For example, one could easily use ex_check from the ci by just running mix check, although it would be interesting to see if a tighter integration could be obtained, such that ex_check can provide the list of commands, which would then be executed by the ci engine.
I’m not sure what ex_check can get from ci (but hopefully there is something ), but I think that ci can learn something from ex_check. The present generator is pretty basic and naive, generating just the few basic checks. It could take a similar approach to ex_check, figuring out from the dependencies which steps can be added (e.g. db setup if ecto is a dependency, dialyzer if dialyxir is a dep, etc.).
