I am in the process of documenting the process of releasing engines to general availability (it's one of my Q1 goals). The basic process involves building the engine and getting it to work with the CLI, at which point I can test it locally and then get it out into the world in beta, and then in general availability. There's a bit of back and forth and tuning necessary, but I'll be here to help with what you need.
Which brings me to a point about bandit. We've found over time that it's a good idea to build the engine work into the tool if possible, because it concentrates the code in one place, making it less likely that the integration pieces of the code will get left behind. If you know anyone involved in the Bandit project and would like to set up a chat about that, that would be awesome.
If not, I'd suggest considering building the engine on top of the tool itself - tools often have abstractions for new types of reporting (which is necessary for the JSON output), etc.
There is a codeclimate-community organization for certain engines, but there does ultimately need to be a maintainer for the engine code, which is why working with the Bandit folks is probably your best bet for making sure that this continues to be cared and loved for in the long-term. You can create a separate codeclimate-bandit repo to hold it. It might also be interesting to think about who else would benefit from bandit running on Code Climate, and seeing if anyone else would be willing to contribute.
-f json
flagAn email from @mrb at Code Climate: