mir-backend-ruby-railslisted

Make It Right (Rails module). Ruby on Rails 7+ specific reliability augmentation. Use alongside mir-backend and mir-backend-ruby when the target stack is Rails — carries the mechanical footguns the framework-agnostic skills deliberately omit: ActiveRecord N+1 and eager-loading strategies, strong parameters and mass-assignment safety, callback side-effect timing (after_commit vs after_save), transaction semantics and nested transactions, migration safety on populated tables (the #1 Rails production incident class), and connection pool sizing tied to Puma threads. TRIGGER only when the Ruby backend is Rails — building, reviewing, or debugging a Rails controller, model, concern, migration, or background job that uses ActiveRecord. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-ruby (YARV runtime: GVL, Puma fork-safety, CoW memory, job hygiene); this module only adds Rails/ActiveRecord library mechanics. SKIP for Sinatra, Hanami, pure Rack apps, or non-Ruby runtimes.
anantbhandarkar/make-it-right · ★ 12 · AI & Automation · score 83

Install: claude install-skill anantbhandarkar/make-it-right

# /mir-backend-ruby-rails · Make It Right (Rails) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-ruby` (YARV runtime model) → **this** (Rails/ActiveRecord library mechanics). Run the gates first; load the Ruby runtime tier for the GVL, Puma, and fork-safety model; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (GVL, fork-safety, CoW memory, Puma pool sizing, job idempotency) live in `mir-backend-ruby` — not here.** **Stack assumed:** Rails 7.1+ · ActiveRecord + PostgreSQL · Sidekiq or GoodJob for background jobs. If the project uses a different DB adapter, note divergences (especially around migration concurrency flags) before applying these. ## The Rails footguns AI walks into most ### 1. ActiveRecord N+1 — silent query explosion in loops N+1 is the most common Rails performance bug: load a collection, then access an association inside a loop, triggering one query per record. ```ruby # WRONG — 1 query for orders + N queries for users Order.all.each { |o| puts o.user.email } # RIGHT — 2 queries total Order.includes(:user).each { |o| puts o.user.email } ``` **Choose the right eager-loading strategy:** | Method | SQL shape | Use when | |---|---|---| | `preload` | Two separate queries, always | Association is large; you don't need to `WHERE` on it | | `eager_load` | Single `LEFT OUTER JOIN` | You need to filter/sort by the association (`where("users.role = ?", "admin")`) | | `in