Curated library of 28 atomic skills and 9 personas for Ruby on Rails development. Organized by category: testing, code-quality, engines, infrastructure, api, context, and personas. 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.
93
95%
Does it follow best practices?
Impact
93%
1.16xAverage score across 28 eval scenarios
Advisory
Suggest reviewing before use
Use this skill when the task is to write, review, or clean up RSpec tests.
| Aspect | Rule |
|---|---|
| Spec types | Model: domain logic / pure domain → start here; Request: HTTP endpoints; Job: background processing; Service/PORO: clean Ruby; System: E2E cross-layer journey (sparingly) |
| Assertions | Test behavior, not implementation |
| Factories | Minimal attributes; traits for options; prefer build/build_stubbed over create |
| Mocking | Stub external boundaries at class level (e.g. allow(Client).to receive); no Active Record mocking |
| Service specs | Required: describe '.call' and subject(:result) (see assets/output_checklist.md) |
let vs let! | Default to let; use let! only when object must exist before action |
| Example names | Present tense; no should; no and (see assets/output_checklist.md) |
HARD GATE: DO NOT write implementation code before a failing test exists.
When driving new behaviour with RSpec, follow this sequence:
e.g. failure examples in the final artifact.For output format and RED/GREEN proof requirements, see assets/tdd_proof_checklist.md.
RSpec.describe Invoices::MarkOverdue do
describe '.call' do
subject(:result) { described_class.call(invoice: invoice) }
context 'when the invoice is overdue and unpaid' do
let(:invoice) { create(:invoice, due_date: 2.days.ago, paid_at: nil) }
it 'marks the invoice overdue' do
expect { result }.to change { invoice.reload.overdue? }.from(false).to(true)
end
end
end
endSplit and in it/specify descriptions every time — no exceptions.
# BAD — two assertions; if the first fails, the second never runs
it 'returns 201 and creates the record' do; end
# GOOD — one observable outcome per example
it 'returns 201' do; end
it 'creates the record' do; end| Cause | Fix |
|---|---|
| Time-dependent logic | freeze_time / travel_to; never set past dates as shortcut |
| State leakage | Each example sets up own state; avoid before(:all) |
| Async jobs | queue_adapter = :test + have_enqueued_job; never assert side-effects imperatively |
| External HTTP | WebMock / VCR; never allow real network in CI |
| DB state bleed | Transactional fixtures or DatabaseCleaner; never share let! across contexts |
| Race conditions | Explicit Capybara waits; avoid sleep |
| Imprecise assertions | change.from().to() over final state; exact values over be_truthy/be_falsey; see rule 16 |
Load these files only when their specific content is needed:
answer.md showing plan, spec, realistic Observed RED/GREEN outputs, and verification tables.frozen_string_literal, subject(:result), and TDD proof format)..tessl-plugin
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
personas
testing
plan-tests
test-service