agentleFS
matthullmatthull/my-skills/skills/technical/ruby-rails/SKILL.md

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
  1. Distinctive:

    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 …

    line 25
  2. Very specific:

    Create .yml files in spec/fixtures/ or test/fixtures/

    line 40
  3. Very specific:

    Use File.write to generate fixture files

    line 42
  4. Distinctive:

    Test at the layer where defined:

    line 53
  5. Distinctive:

    ONE spec file per class: No method-specific spec files.

    line 64
  6. Very specific:

    Use describe and context blocks to organize within the file.

    line 66
  7. Distinctive:

    If you find multiple spec files for one class: consolidate into single file, delete redundant files.

    line 68
  8. Distinctive:

    Before completing any Rails work:

    line 84
  9. Distinctive:

    Create multiple spec files for individual methods

    line 99
  10. Distinctive:

    Add public methods without tests

    line 100
  11. Distinctive:

    Create or edit manual fixture .yml files

    line 101
  12. Very specific:

    Add boilerplate comments (# Arrange, # Act, # Assert)

    line 102
  13. Distinctive:

    Use raw SQL when ActiveRecord methods exist

    line 104

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 touchingLoad 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.rbresources/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.write to 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 where clauses
  • ActiveRecord callbacks only for model concerns

Download now (ZIP)

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.