Curated library of 28 public AI agent skills for Ruby on Rails development. Organized by category: testing, code-quality, engines, infrastructure, api, and context. Covers code review, architecture, security, testing (RSpec), engines, Hotwire, and TDD automation. Shared Ruby skills (YARD docs, DDD, service objects) have moved to ruby-core-skills. Repository agents remain documented in GitHub but are intentionally excluded from the Tessl tile.
93
95%
Does it follow best practices?
Impact
93%
1.78xAverage score across 28 eval scenarios
Passed
No known issues
Core principle: Every claimed Rails/Ruby version must be in the CI matrix. Prefer explicit support targets over accidental compatibility.
| Compatibility Aspect | Check |
|---|---|
| Zeitwerk | File paths match constant names; no anonymous or root-level constants |
| Gemspec bounds | add_dependency and required_ruby_version match tested versions |
| Feature detection | Use respond_to?, defined?, or adapter seams instead of Rails.version |
| Test matrix | CI runs against each claimed Rails/Ruby combination |
| Optional integrations | Jobs, mailers, assets, routes, and generators are checked on each version |
Before claiming support for a Rails/Ruby version:
1. bundle exec rake zeitwerk:check # verify autoloading on each version
2. bundle exec rspec # full suite per matrix version
3. CI matrix must pass — not just main Rails version
DO NOT ship compatibility changes without verifying both autoloading and full suite.bundle exec rake zeitwerk:check — file paths must match constant names exactly.config.to_prepare for reload-sensitive hooks.spec.add_dependency "rails", ">= 7.0", "< 8.0" — bounds must match what CI actually tests.strategy:
matrix:
include:
- { ruby: "3.2", rails: "7.1" }
- { ruby: "3.3", rails: "7.2" }Pitfalls
| Problem | Correct approach |
|---|---|
Rails.version branching | Use respond_to?, defined?, or adapter seams — version checks are brittle |
| Zeitwerk file/constant mismatch | File path must mirror constant name exactly — my_engine/widget_policy.rb → MyEngine::WidgetPolicy |
| Broad gemspec constraints without CI | Claiming >= 5.2 without testing 5.2/6.x is silent incompatibility |
| No version bounds in gemspec | Unbounded constraints allow breaking upgrades into the engine |
| Reload-unsafe hooks at load time | Move to config.to_prepare — it runs on each reload in development |
| Tests only on one Rails version | CI matrix required before claiming multi-version support |
Key Example: Feature Detection
# ❌ Bad — brittle, wrong for patch versions
if Rails.version >= "7.0"
config.active_support.cache_format_version = 7.0
end
# ✅ Good — detect the capability directly
if ActiveSupport::Cache.respond_to?(:format_version=)
config.active_support.cache_format_version = 7.0
endpresent/absent, the file path checked, and the per-version verification command.| Skill | When to chain |
|---|---|
| test-engine | Test matrix setup, CI configuration, multi-version tests |
| create-engine | Engine structure, host contract, namespace design |
| release-engine | Versioning, changelog, upgrade notes for compatibility changes |
agents
docs
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10
scenario-11
scenario-12
scenario-13
scenario-14
scenario-15
scenario-16
scenario-17
scenario-18
scenario-19
scenario-20
scenario-21
scenario-22
scenario-23
scenario-24
scenario-25
scenario-26
scenario-27
scenario-28
skills
api
generate-api-collection
implement-graphql
code-quality
apply-code-conventions
apply-stack-conventions
assets
snippets
code-review
refactor-code
review-architecture
security-check
context
load-context
setup-environment
engines
create-engine
create-engine-installer
document-engine
extract-engine
release-engine
review-engine
test-engine
upgrade-engine
infrastructure
implement-background-job
implement-hotwire
optimize-performance
review-migration
seed-database
version-api
testing
plan-tests
test-service
write-tests