I was thinking along the same lines as @darrenboyd - ruby is whatever the current environment is (be it the default ruby or the one setup by rvm or rbenv - as long as the correct requirements are configured, like in the case of rvm or rbenv)

I have not used rbenv, that's why I left it in the pre-commit hook, as-is.

I don't mind taking the consequences if/when I push this change. But:

How do we expect users to setup pre-commit in development? 

The way _I_ would expect it be setup in a project when using rvm (with gemsets declared) is that I would have to declare it in my Gemfile under the `:development` and/or `:test` section (optionally including rubocop to activate it in pre-commit runs for the project)

Relying on having pre-commit installed on the default env might work, but could lead to confusion. 

For example, if I don't have pre-commit installed in the default env, and I switched into a project directory configured with a different ruby env and gemset (via rvm), and I decide to install pre-commit (either manually or via bundle/Gemfile) - when I attempt to commit, then pre-commit hook will fail to run the pre-commit checks (this is because the pre-commit hook currently will always expect it to be under the default ruby)