ruby-rails
Skill0 starsChanged 55 days agoMITView on GitHub
Ruby/Rails patterns — fixture builder, RSpec organization, migrations, console verification. Load this skill for Ruby on Rails development tasks. Use during coding phases like IMPLEMENT
- Reads credentials
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 9 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Re-check as you go: If you discover during work that you're touching a new area (e.g., fixing a jbuilder N+1 leads you into the …
- Very specific: line 40
Create .yml files in spec/fixtures/ or test/fixtures/
- Very specific: line 42
Use File.write to generate fixture files
- Distinctive: line 53
Test at the layer where defined:
- Distinctive: line 64
ONE spec file per class: No method-specific spec files.
- Very specific: line 66
Use describe and context blocks to organize within the file.
- Distinctive: line 68
If you find multiple spec files for one class: consolidate into single file, delete redundant files.
- Distinctive: line 84
Before completing any Rails work:
- Distinctive: line 99
Create multiple spec files for individual methods
- Distinctive: line 100
Add public methods without tests
- Distinctive: line 101
Create or edit manual fixture .yml files
- Very specific: line 102
Add boilerplate comments (# Arrange, # Act, # Assert)
- Distinctive: line 104
Use raw SQL when ActiveRecord methods exist
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Ruby/Rails Practice
Load this skill for any Ruby on Rails work. Core mandates below apply universally. Then load resource files based on what you're touching.
Progressive Disclosure — Resource Loading
Match the files you're working with against this table. Load every matching resource using the Read tool before starting work.
| Files you're touching | Load resource |
app/models/ | resources/models.md |
app/controllers/, spec/requests/ | resources/controllers.md |
app/services/, app/jobs/, app/workers/ | resources/services.md |
app/views/**/*.jbuilder, *_serializer.rb | resources/serialization.md |
db/migrate/ | resources/migrations.md |
Multiple matches are expected. A jbuilder change that adds eager loading touches both serialization and controllers — load both.
Re-check as you go. If you discover during work that you're touching a new area (e.g., fixing a jbuilder N+1 leads you into the controller), come back to this table and load the newly relevant resource before continuing.
For PR reviews: map the diff's file list against this table.
Resource paths are relative to this skill's directory: ~/.claude/skills/ruby-rails/
CRITICAL: Fixture Builder Constraint (ABSOLUTE)
You MUST NEVER create or edit manual fixture .yml files.
This project uses fixture_builder gem which regenerates ALL fixtures — manual .yml files WILL BE DELETED on next regeneration.
You MUST NEVER:
- Create .yml files in spec/fixtures/ or test/fixtures/
- Edit existing .yml fixture files
- Use
File.writeto generate fixture files
You MUST ALWAYS:
- Define fixtures ONLY in
spec/support/test_data_factory.rb - Use FixtureBuilder.configure block
- Regenerate:
rake spec:fixture_builder_rebuild
CRITICAL: Test Every New Public Method (ABSOLUTE)
Test at the layer where defined:
- Controller action: Request spec (NOT controller spec)
- Client method: Client spec
- Service method: Service spec
- Model method: Model spec
- Helper method: Helper spec
CRITICAL: Spec File Organization (ABSOLUTE)
ONE spec file per class. No method-specific spec files.
Use describe and context blocks to organize within the file.
If you find multiple spec files for one class: consolidate into single file, delete redundant files.
Verification Loops
Loop 1 (TDD): bundle exec rspec spec/{path}/{filename}_spec.rb
Loop 2 (Scoped): ./specs/{PROJECT_NAME}/verify-specs.sh or bundle exec rspec spec/services/
Loop 3 (Console): docker compose exec web bundle exec rails console — verify data, exercise services
Loop 3 is REQUIRED unless ALL code paths are 100% exercised by unit tests.
Universal Checklist
Before completing any Rails work:
- ONE spec file per class
- Every new public method has its own test
- No manual fixture .yml files created or edited
- No
Rails.env.production?usage (use positive environment checks) - No caching without documented justification
- RuboCop passes on modified files
- No debug statements (
binding.pry,puts) - Loaded and followed all matching resource files from routing table above
Universal Anti-patterns
You MUST NEVER:
- Create multiple spec files for individual methods
- Add public methods without tests
- Create or edit manual fixture .yml files
- Add boilerplate comments (
# Arrange,# Act,# Assert) - Skip writing tests first (TDD red phase)
- Use raw SQL when ActiveRecord methods exist
Prefer:
- Service objects for complex business logic
- Integration tests over unit tests for critical flows
- Fixtures over factories (factories only for request specs or edge cases)
- Named scopes over repeated
whereclauses - ActiveRecord callbacks only for model concerns
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- Mindrally/skills★ 275same name
- muxammadmamajonov/dot-claude★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository43 other files it gives its agents.
- skills/technical/supabase-postgres-best-practices/AGENTS.mdAGENTS.md
- skills/technical/supabase-postgres-best-practices/CLAUDE.mdCLAUDE.md
- direct-handoffSkill
- handoffSkill
- nt-commsSkill
- threadsSkill
- meal-planningSkill
- resume-workflowSkill
- bash-scriptsSkill
- code-reviewSkill
- davinci-resolveSkill
- disk-cleanupSkill
- fastmcp-pythonSkill
- go-cliSkill
- markdown-to-pdfSkill
- pr-createSkill
- qa-planSkill
- rcaSkill
- react-native-best-practicesSkill
- skill-creatorSkill
- spec-checkSkill
- supabase-migrationsSkill
- supabase-postgres-best-practicesSkill
- supabase-sqlSkill
- testingSkill
- ui-state-managementSkill
- waydroid-adbSkill
- calcinatioSkill
- citationsSkill
- exploreSkill
- manual-qaSkill
- nvim-copilotSkill
- orchestrateSkill
- orthogonal-emanationSkill
- product-intent-signal-extractionSkill
- project-management-signal-extractionSkill
- request-researchSkill
- researchSkill
- skill-discoverySkill
- slack-thread-triageSkill
- specSkill
- tmux-sidecarSkill
- youtube-transcribeSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

