Configuration

RailsCTO is designed to work with zero configuration. After running rails-cto init, the plugin's skills activate automatically based on what files your agent touches and what commands you type.

That said, there are a few things worth understanding if you want to customize behavior or debug a misfire.

What you can configure

• CLAUDE.md wiring — How the plugin injects mandatory skills into your project's CLAUDE.md and what that block does.
• Skill routing — How the orchestrator decides which skill to invoke, what triggers each skill, and how to override routing decisions.

What you should not configure

RailsCTO's quality gates are intentionally mandatory. Things you should not disable or work around:

• RuboCop rules via rubocop:disable comments — fix the code instead.
• .rubocop.yml exemptions that suppress warnings — the project's rules are set for a reason.
• Skipping the QA skill after Ruby file changes — the gate exists to keep the work shippable.

If a skill is consistently getting in your way, that's a sign either your code needs refactoring or the skill itself needs improvement. Open an issue at the plugin's GitHub repo instead of disabling the gate.

Project-level customization

Each config file the companion gem drops in — .rubocop.yml, .reek.yml, .bundler-audit.yml, config/brakeman.yml — is a template, not a lock. You can extend or override rules in them for your project's specific needs. The gem's doctor command will flag drift from the bundled template, but drift is allowed. See Config Templates for details.