RuboCop's real surface is config/default.yml, and its minor version promise covers API and cop configuration

Out of the box it reports problems, and config/default.yml is where the behaviour lives

The default posture is enforcing the community Ruby Style Guide, reporting what it finds, and correcting many of the findings for you. That last part is the distinction that matters: RuboCop is described as a static code analyzer, a.k.a. a linter, and as a code formatter, and auto-correction is described as applying to many problems rather than all of them.

Nearly everything else is a configuration decision. The README points at config/default.yml in the master branch as the file holding the configuration options, and says most aspects of behaviour can be tweaked through them. That single YAML file is therefore the difference between an opinionated gate in your CI and a tool you have made agree with your codebase.

The practical consequence is that adopting RuboCop is not installing a gem, it is taking ownership of a configuration file you have to keep current as the defaults move underneath you. The repository lints itself with a .rubocop.yml at its root, so the same file exists in your project the moment you want it.

The Gemfile entry has to set require: false because the tool is standalone

There are three forms of the install, and the difference between them is not cosmetic.

gem 'rubocop', require: false

gem 'rubocop', '~> 1.92', require: false

gem install rubocop

The README gives the reason for require: false plainly: it is a standalone tool. If you add the gem without it, Bundler treats it like an application dependency and loads it during boot, which couples a command line tool to your app's start-up. The conservative line pins to the current minor series, ~> 1.92, and the README frames it as a way to prevent an unwanted update.

The stated policy is stability between minor versions in both API and cop configuration, with big changes reserved for major releases. Read strictly, that promise protects your code and your config from rewrites.

The analysis target is Ruby 2.0 while the runtime floor is MRI 2.7

Two different versions appear in the compatibility section and they answer two different questions.

MRI 2.7+
JRuby 9.4+

Those are the officially supported runtimes, so MRI 2.6 and JRuby before 9.4 are outside official support. Separately, the project states that it targets Ruby 2.0+ for code analysis, which means the language surface it parses starts at 2.0 even though the process needs 2.7 or newer.

The gap is not a contradiction but it does have a consequence. The floor for parsing is much lower than the floor for running, so a codebase still written in older Ruby syntax can be analysed, while the analyser itself is only officially supported on MRI 2.7+ or JRuby 9.4+. That makes RuboCop awkward on a locked-down legacy image where the runtime cannot be upgraded: you would have to run it from a newer environment than the code it inspects. The README points to a compatibility document for the full matrix rather than enumerating version-by-version behaviour here.

The logo is licensed non-commercial, so putting it in your product is a separate question

The trademark-looking asset most projects copy without checking is the one with the narrowest terms. The RuboCop logo was created by Dimiter Petrov and is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. The code itself is MIT under LICENSE.txt, so the license covering the software and the license covering the logo are not the same.

The consequence is concrete for anyone who wants to signal compliance. A badge or logo on the readme of a personal or open source project fits the non-commercial terms. The same asset inside a commercial product, on an internal developer portal at a company, or on the marketing site of a vendor selling tooling may not, and the non-commercial clause is in the license name for a reason. The README does offer Markdown snippets for the two readme badges, but offering a snippet is not a grant of rights for a commercial deployment.

If the badge matters to you commercially, clear it separately or skip it. Nothing in the tool's output depends on the logo being present.

The repository keeps a .rubocop_todo.yml, which is the same escape hatch your project will reach for

Look at what the project uses on itself. Alongside a .rubocop.yml at the root there is a .rubocop_todo.yml, and the top-level entries also include config/, exe/, bin/, spec/, tasks/, .rspec, .simplecov, changelog/, relnotes/ and a .pre-commit-hooks.yaml. The todo file is the deferred-offenses pattern: offenses are recorded rather than fixed, so the tool can pass while the debt is written down.

This is worth understanding because it is a design decision, not a bug. Turning on RuboCop in an existing codebase produces a wall of offenses on the first run, and a todo file is the least disruptive way past it. The cost is that the todo file becomes part of your configuration surface and tends to stay there.

Two smaller signals sit in the same list. A .pre-commit-hooks.yaml means the project can run as a git hook, though the README's setup section does not walk you through installing it.

Three of the eleven core developers are marked retired and funding is the stated capacity limit

The team list names eleven people, with Bozhidar Batsov as author and head maintainer, and marks three as retired: Yuji Nakayama, Evgeni Dzhelyov and Masataka Kuwabara. The rest are listed as active.

The project also states what it wants that money buys. A monthly budget of a couple of thousand dollars would make it possible to pay people to work on complex features and fund things like hardware and conference travel, and a monthly budget over $5000 would open the possibility of someone working full time on it. Open Collective is named as the preferred funding platform, with GitHub Sponsors, Patreon, PayPal and Tidelift also listed.

Read as engineering planning rather than as a donation page: the release cadence you see, v1.92.2 on 2026-10-29, v1.92.1 on 2026-10-22 and v1.92.0 on 2026-10-10, is produced by a small group on that budget. The repository is not archived and the last push was 2026-11-02, so it is being worked on right now. Companies told they can take a support-like subscription through Tidelift instead of a donation are pointed at that for accounting reasons.

Passing RuboCop does not mean the style guide is covered

The single most useful sentence in the README for scoping the tool is the contribution note: converting more of the Ruby Style Guide into RuboCop cops is the project's top priority right now, and writing a new cop is presented as the easy way to start contributing.

That statement is an admission that coverage is partial. RuboCop enforces many of the guidelines in the style guide out of the box, and the honest reading of many is that some parts of the guide have no cop yet. A file can therefore be completely clean under RuboCop and still differ from what the guide asks for, with nothing in the tool output to tell you which guideline was missed, because no cop exists to express it.

The consequence is that RuboCop should not be described as enforcing the guide. It enforces the subset that has been converted. If your review process treats a clean RuboCop run as proof of style compliance, that assumption is wrong in a way no configuration will fix, and it is a gap that closes only as more cops land.

Running it is one command, and the editor story runs through a built-in LSP server

The quickstart is intentionally thin. You change into a Ruby project and run the tool.

cd my/cool/ruby/project
rubocop

The first run on an existing codebase is the adoption moment: whatever config/default.yml says is what you get, and the size of the first report is your backlog.

For editors, the README points at a built-in LSP server with its own page in the documentation. The docs are at docs.rubocop.org, and the default configuration file is linked from the master branch on GitHub, which is where to check what a given cop's default actually is before you override it.

Editorial conclusion

RuboCop is worth adopting for Ruby codebases that want an enforced, machine checked version of a shared style guide, and the minor version policy means your integration code and your cop configuration survive routine upgrades. It is not a substitute for the Ruby Style Guide itself, because converting the guide into cops is still the stated top priority, which means passing RuboCop does not mean the guide is covered. Before you commit, pin the version as the README recommends, keep require: false in the Gemfile, check your Ruby runtime against MRI 2.7 or JRuby 9.4, and remember the logo is non-commercial.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rubocop/rubocop on GitHub