From rails-load-defaults
Guides incremental upgrade of Rails config.load_defaults by walking through each new_framework_defaults config. Handles uncomment-test-commit workflow and consolidation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rails-load-defaults:rails-load-defaultsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill guides the incremental upgrade of `config.load_defaults` in a Rails
configs/5_0.ymlconfigs/5_1.ymlconfigs/5_2.ymlconfigs/6_0.ymlconfigs/6_1.ymlconfigs/7_0.ymlconfigs/7_1.ymlconfigs/7_2.ymltemplates/cookie_rotator.rbtemplates/new_framework_defaults_5_0.rbtemplates/new_framework_defaults_5_1.rbtemplates/new_framework_defaults_5_2.rbtemplates/new_framework_defaults_6_0.rbtemplates/new_framework_defaults_6_1.rbtemplates/new_framework_defaults_7_0.rbtemplates/new_framework_defaults_7_1.rbtemplates/new_framework_defaults_7_2.rbThis skill guides the incremental upgrade of config.load_defaults in a Rails
application. The process walks through each config introduced in a new Rails
version, one at a time, so the user can test each change in isolation.
When a Rails app has a load_defaults version lower than its Rails version,
there are framework default configs that need to be adopted. This skill:
load_defaults versionnew_framework_defaults_X_Y.rb initializer with all configs commentedconfig/application.rb when all configs are doneRead config/application.rb and look for:
config.load_defaults X.Y
Also check if a config/initializers/new_framework_defaults_*.rb file already
exists (the user may be mid-upgrade).
Report to the user:
load_defaults versionRead the appropriate config reference file for the target version:
configs/5_0.ymlconfigs/5_1.ymlconfigs/5_2.ymlconfigs/6_0.ymlconfigs/6_1.ymlconfigs/7_0.ymlconfigs/7_1.ymlconfigs/7_2.ymlEach config file contains entries organized into tiers with lookup patterns and decision trees for each config.
If no new_framework_defaults_X_Y.rb exists yet, copy the template from
the templates/ directory into the app's config/initializers/:
templates/new_framework_defaults_5_0.rb → config/initializers/new_framework_defaults_5_0.rbtemplates/new_framework_defaults_5_1.rb → config/initializers/new_framework_defaults_5_1.rbtemplates/new_framework_defaults_5_2.rb → config/initializers/new_framework_defaults_5_2.rbtemplates/new_framework_defaults_6_0.rb → config/initializers/new_framework_defaults_6_0.rbtemplates/new_framework_defaults_6_1.rb → config/initializers/new_framework_defaults_6_1.rbtemplates/new_framework_defaults_7_0.rb → config/initializers/new_framework_defaults_7_0.rbtemplates/new_framework_defaults_7_1.rb → config/initializers/new_framework_defaults_7_1.rbtemplates/new_framework_defaults_7_2.rb → config/initializers/new_framework_defaults_7_2.rbThese templates contain the exact canonical Rails initializer with all configs
commented out, matching what rails app:update would generate. Always use
the template rather than generating from scratch — this ensures the comments,
formatting, and config ordering match the Rails source.
Process configs in order from safest (Tier 1) to those needing analysis (Tier 2).
For each config:
Run the lookup patterns defined in the config reference:
grep -r or find to search for the patterns listedTell the user:
Once the user agrees:
Stop and wait. The user will:
If the change broke something:
Some configs are marked application_rb_only in the version reference YAML.
These cannot go in the initializer file and must be tested directly in
config/application.rb.
During the iterative walkthrough, when you reach these configs:
config/application.rb (after the existing
load_defaults line) so they can be tested in isolationconfig.load_defaults 6.1
# TESTING load_defaults 7.0 — remove during consolidation if using new default
config.active_support.cache_format_version = 7.0
Keep track of which configs have been processed by reading the initializer file. Commented lines = pending. Uncommented lines = done.
For application_rb_only configs, track them by looking for the
# TESTING load_defaults comments in config/application.rb.
When all configs in the initializer have been uncommented and tested:
Delete the config/initializers/new_framework_defaults_X_Y.rb file
Update config.load_defaults in config/application.rb to the new version
CRITICAL: For any configs where you kept the OLD behavior/value (i.e., did
not adopt the new default), you MUST add explicit overrides in
config/application.rb after the load_defaults line. If you skip this,
setting load_defaults to the new version will silently switch those configs
to their new default values — undoing your deliberate decision to keep the
old behavior.
Each config entry in the version reference YAML includes an old_default
field. Use that value for the override.
config.load_defaults 7.0
# Override: kept old behavior because CSS targets input[type=submit] from button_to
config.action_view.button_to_generates_button_tag = false
# Override: kept old behavior because app uses namespaced UUIDs as stored identifiers
config.active_support.use_rfc4122_namespaced_uuids = false
Remove application_rb_only configs that use the NEW default. During
testing (Step 4e), these were added explicitly in config/application.rb
with # TESTING load_defaults comments. Now that load_defaults is set
to the new version, the new defaults are already implied — keeping them
is redundant. Remove them.
Only keep application_rb_only configs if you chose the OLD value:
config.load_defaults 7.0
# load_defaults 7.0 already sets cache_format_version = 7.0,
# so do NOT explicitly set it here. Just remove the testing line.
# Override: kept old behavior because [reason]
config.active_support.disable_to_s_conversion = false
If more version transitions are needed, start again at Step 2 with the next version.
config/application.rb (not
the initializer). Flag these clearly and handle them during consolidation.npx claudepluginhub ombulabs/claude-skills --plugin rails-load-defaultsAnalyzes Rails apps for upgrades: verifies structure via Gemfile and config files, extracts current version, fetches latest release, summarizes official guides and railsdiff.org file diffs.
Analyzes Rails apps and generates upgrade reports from 2.3 to 8.1 with breaking changes, deprecations, and step-by-step migration guides. Use for upgrades, multi-hop plans, or version queries.
Supplies internal references for Rails upgrades (5→6, 6→7, 7→8) with breaking changes, fix patterns, compatibility matrices, risky migrations, and Turbo/Stimulus guides. Loaded by audit/fix skills.