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
| Aspect | Rule |
|---|---|
| File location | spec/services/module_name/service_spec.rb |
| Subject | subject(:service_call) { described_class.call(params) } |
| Unit isolation | instance_double for collaborators |
| Integration | create for DB-backed tests |
| Multi-assertion | aggregate_failures |
| State verification | change matchers |
| Time-dependent | travel_to |
| API responses | FactoryBot hash factories (class: Hash) |
DO NOT implement the service before step 1 is written and failing for the right reason.
1. WRITE: Write the spec (happy path + error cases + edge cases)
2. RUN: bundle exec rspec spec/services/your_service_spec.rb
3. VERIFY: Confirm failures are for the right reason (not a typo or missing factory)
4. FIX: Implement or fix until the spec passes
5. SUITE: bundle exec rspec spec/services/ — verify no regressionsUse this skill when writing tests for service classes under spec/services/.
Core principle: Test the public contract (.call, .find, .search), not internal implementation. Use instance_double for isolation, create for integration.
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe ModuleName::MainService do
describe '.call' do
subject(:service_call) { described_class.call(params) }
let(:shelter) { create(:shelter, :with_animals) }
let(:params) do
{ shelter: { shelter_id: shelter.id }, items: %w[TAG001 TAG002] }
end
context 'when input is valid' do
before { create(:animal, tag_number: 'TAG001', shelter:) }
it 'returns success' do
expect(service_call[:success]).to be true
end
end
context 'when shelter is not found' do
let(:params) { super().merge(shelter: { shelter_id: 999_999 }) }
it 'returns error response' do
expect(service_call[:success]).to be false
end
end
context 'when input is blank' do
let(:params) { { shelter: { shelter_id: nil }, items: [] } }
it 'returns error response with meaningful message' do
aggregate_failures do
expect(service_call[:success]).to be false
expect(service_call[:errors]).not_to be_empty
end
end
end
end
endUse instance_double for unit isolation:
let(:client) { instance_double(Api::Client) }
before { allow(client).to receive(:execute_query).and_return(api_response) }Use create for integration tests:
let(:source_shelter) { create(:shelter, :with_animals) }When testing API clients, use class: Hash with initialize_with to build hash-shaped response fixtures. A minimal example:
FactoryBot.define do
factory :api_animal_response, class: Hash do
tag_number { 'TAG001' }
status { 'active' }
initialize_with { attributes.stringify_keys }
end
end
# In the spec:
let(:api_response) { build(:api_animal_response, tag_number: 'TAG002') }subject defined for the main actioninstance_double for unit / create for integrationshared_examples for repeated patternsaggregate_failures for multi-assertion testschange matchers for state verification| Mistake | Correct approach |
|---|---|
| No error scenario tests | Happy path only = false confidence — always test failures |
let! everywhere | Use let (lazy) unless the value is needed unconditionally for setup |
| Huge factory setup | Keep factories minimal — only attributes required for the test |
| Spec breaks when implementation changes but behavior is unchanged | Tests that break on refactoring are testing internals, not contracts |
describe and context blocks..call, .find, .search) and avoid assertions against private implementation.spec/services/ command when available.instance_double is used for injected collaborators and where create is used for DB-backed integration.| Skill | When to chain |
|---|---|
| write-tests | For general RSpec style and TDD discipline |
| create-service-object | For the service conventions being tested |
| integrate-api-client | For API client layer testing patterns |
| test-engine | When testing engine-specific services |
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