I like the idea behind this because I am also very sensitive to that type of things. Probably over-sensitive but I just worry that if you let one thing go, it b

I like the idea behind this because I am also very sensitive to that type of things. Probably over-sensitive but I just worry that if you let one thing go, it becomes a slippery slope and you then have a mess of a repo. That being said, if you care about these things, I wonder if these checks are best left to a pre-commit hook. It removes noise from the commit history and the PRs and forces people to think about it right away, rather than being corrected after the fact. I guess having that done on a server has the benefit of not having to worry about keeping the linters' version up-to-date/homogenous over all the devs' machines. At work, we have JSCS (https://github.com/jscs-dev/node-jscs https://github.com/jscs-dev/node-jscs) and SCSS-lint (https://github.com/causes/scss-lint https://github.com/causes/scss-lint) as part of our pre-commit hook (on top of editor plugins) and that has been great honestly. It decreased the PR noise a lot and I feel it has been good for new hires since it avoids having the first PR comments being about style issues. I wrote a post about how I added JSCS in the pre-commit hook by the way: http://tech.adroll.com/blog/web/2014/03/05/adding-jscs-to-your-commit-hook.html http://tech.adroll.com/blog/web/2014/03/05/adding-jscs-to-yo... It should be easily extendable to other linters.